On Sun, Jul 14, 2013 at 07:55:46PM +0300, Hleb Valoshka wrote: > Нет, дело не в айпишниках, я проверял. > > >> В результате, после изменения tcp_rmem на 4096 87380 1033696, всё > >> работает > > Значение tcp_rmem относится к размеру буферов для сокетов и не должно > > иметь отношения к маршрутизации. Но оно может неявно влиять на размер > > различных таблиц и значений хэшей, и потому вызывать спорадические > > проявления багов. > > Не-а, вы не поняли, кажется, я изменил tcp_rmem на _клиенте_. Шлюз > остался нетронутый. В том-то и прикол.
Прикол приколом, конечно, но... непонятно, что именно Вы пытались изменить. Кроме размера окна клиента в заголовках пакетов ничего меняться не должно. Коннекция находится в стадии разгона на максимальном MTU, ограничение на размер буфера нигде не достигается (да и нет шлюзу дела до него), поэтому у всех пакетов в последовательности должны в точности повторяться размеры и данные. Но если подозревать баги в контраке, где-то в области сопоставления пакетов коннекции, то "хорошая" и "плохая" коннекции из присланных дампов далеко не идентичны: различаются ip-шники и порты клиентов, а это значит, что хэши для этих коннекций тоже будут отличаться. Если подозревается ещё и порча памяти, то нельзя считать поведение шлюза детерминированным и нужно набирать статистику отказов. Думаю, что утверждение о корреляции бага с клиентским tcp_rmem может быть ошибочным, а "прикол" -- случайным выбросом на малой статистике. > Если симитировать на виртуалках удастся, то можно и покопать. А если > нет, то гори оно гаром, обошёл, задокументировал, и ладно. Не сидеть > же по ночам на работе? Всё зависит от того, чего хочется достичь. :) Если понимания ситуации и выработки правильной модели мира в голове -- это одно, если побыстрее отбиться от проблемы любой ценой, даже через нелепое, непонятно каким образом работающее "решение" -- это совсем другое. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
