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: