|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 18 Mar 2005 17:08:21
To : Alex Korchmar
Subject : Re: RedHat 7.3 and IDE disks
--------------------------------------------------------------------------------
Alex Korchmar <hue-moe@so.yandex.ru> wrote:
AK> Eugene B. Berdnikov <berd@desert.ihep.su> wrote:
AK>
AK>>> rmmod ip_conntrack уже работает?
AK>>> я именно по этой причине не советую ни 20, ни более новых.
AK>
EBB>> Hе знаю, удалять модуль не пробовал. У меня нет такого количества
EBB>> коннекций в контраке, как у тебя, может быть поэтому проблема
AK> какого такого? у меня их меньше тыщи в пике! А откуда оно берет свои
Аналогично. Hо я погуглил архив эхи - у меня пик 2/3 от твоих 750. :)
AK> 64k (последнее, что я там поставил) - это ты у авторов спроси.
Авторам можно задать вопросы, но потом RR задаст мне ответы. :)
И как после этого выкручиваться, если у меня самого этой проблемы нет?
EBB>> с переполнением не возникает. Hа 2.4.20, 2.4.26 также не видно,
AK> не видно. Их там будет двести при лимите в 4k - а у тебя будет полный
AK> лог сообщений о потеряных из-за переполнения пакетах. Сделаешь 8 -
AK> на время заткнутся. Потом опять полезут. 16. 32. интересно, когда оно
AK> рухнет?
После беглого просмотра (зевая) ip_conntrack_core.c, приснилось мне сегодня,
что не рухнет никогда. Так и будет твои пакетики дропать. :)
Вообще, я там мало что там понял, но остался очень недоволен логикой вызова
early_drop(). Хотя туда попадаем уже при "утечках" слотов под коннекты.
AK> меня устраивает 17-18-19 + pom-не-ng "для сети", но оно не работает на
AK> современных машинах напрочь - ich6+свежие eepro="нисегонезнаю, какая-то
AK> 486 без сетевух, наверная!?"
Мысль такая: в http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
написано, что алгоритм хэширования менялся в районе 2.4.20-23,
и разные алгоритмы предпочитают разный hashsize. Этот hashsize можно
посмотреть и покрутить (параметром модуля, естественно).
Хотя мне кажется, что более вероятной является утечка слотов при
неправильном освобождении каких-нибудь unreplyed-коннектов под udp,
например, для dns'a в режиме forward only (там tuple получается
всегда один и тот же, и всегда даёт одно и то же значение хэша).
Собственно, предложение такое: попробовать перекрыть пакетным
фильтром всё, что не должно попадать в роутер, чтобы в контраке
было как можно меньше мусора из unreplyed-коннектов. Дополнительно
можно таймауты контрака закрутить.
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
