[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Непонятные RST



On Fri, Jul 12, 2013 at 05:33:42PM +0300, Hleb Valoshka wrote:
> Итак, -j TRACE особенно не помог, т.е. он только паказал, что 6 и 7 пакеты
> уходят почемуто в INPUT вместо FORWARD, но не дал ответа на вопрос почему
> это происходит.

 Если все цепочки, которые проходятся пакетами перед INPUT/FORWARD,
 дают идентичные части трассы, то это великолепный результат, который
 другими способами вряд ли было бы возможно получить... Видно, что
 бага скорее всего в трэкере коннекций, в том месте, где принимается
 решение о маршрутизации.

> Коллеги были убеждены, что во всём виновата esx, и нужно перенести
> виртуалку на другой узел. Перенесли, ситуация чуть-чуть изменилась, т.е.
> если вначале проблема возникала в 98%, то после переноса, наверное, в 75%.
> Для проверки развернули ещё один squeeze, там RST летели чуть реже (может в
> 50% случаев).
> 
> Поставил ядро из squeeze-backports на проверочной виртуалке -- всё работает
> отлично.

 Видно, что проблема "плавающая". Изменение поведения при переносе в другую
 среду виртуализации, или при изменении нагрузки -- картина, характерная
 для проблем управления памятью (неинициализированные переменные и т.п.).
 Дублирование виртуалки связано, наверное, с применением других ip-адресов
 на клоне, что наверняка приводит к изменению значений хэшей.

 Думаю, бага где-то в области вычисления хэшей контрака. Со времён 2.6.32
 Эрик несколько раз что-то там лопатил, но я не вникал и деталей не помню.
 В 2.6.32 был какой-то неприяный баг в tcp_output(), из-за которого
 нельзя было держать это ядро на нагруженных серверах. Для роутинга оно
 вроде было пригодно...

> В результате, после изменения tcp_rmem на 4096 87380 1033696, всё работает
> (или, по крайней мере, частота обрывов уменьшилась до единиц %).
...
> По-дефолту у 2.6.32 net.ipv4.tcp_rmem = 4096 87380 4194304. "The third and
> last value specified in this variable specifies the maximum receive buffer
> that can be allocated for a TCP socket." Т.е. чем больше, тем должно быть
> лучше, а тут наоборот.

 Значение tcp_rmem относится к размеру буферов для сокетов и не должно
 иметь отношения к маршрутизации. Но оно может неявно влиять на размер
 различных таблиц и значений хэшей, и потому вызывать спорадические
 проявления багов.

> А ещё более непонятно, почему пакету уходили в INPUT на шлюзе, при этом
> только 6-й и 7-й, после них все проходили нормально, и даже их копии,
> посланные из-за ретрансмита.
> 
> Я ничего не понимаю.

 Чтобы понять, нужно копать глубже. Обработка копии пакета иным образом
 может быть вызвана спорадической порчей памяти, неинициализированными
 переменными и прочим. Если есть время, желание и навыки для ковыряния
 в коде ядра -- всё можно выяснить... Если нет, ставьте ядро поновее и
 работайте дальше. Для содержательного общения с netdev'ом лучше всего
 иметь горячую версию ядра из git'a.
-- 
 Eugene Berdnikov


Reply to: