Dark_Angel

Самое интересное в итоге, что профайлер явно не показывает на dhcpd, а указывает на функции ядра, чем окончательно сбивает с толку.

Указанные ошибки драйвера не являются драйверо или ядро зависимыми же. Поэтому от апдейта ядра и драйвера не уйдут. Если конечно драйвер не багованый. В вашем случае не похоже.

Значит он парсит список и настраивает фильтры на те порты, которые есть в списке. Других требований к фильтру по закону нет, и я не думаю что он фильтрует весь трафик.

Ну здесь сюрприза нет: стоковый centos стабилен и стар. Но стабилен. Но стар. За то и любим. Даже не смотря на бэкпорты. Поэтому можно не стеснятся и грейдить ядро с драйвером ( это вообще обязательно ). И лучше самосборное ( если знаете как оптимизировать ). А то прилетит вам апдейт из репозитория и всё поломается.

irqbalance может вам некисло потрепать нервы на роутере. Его нужно обязательно отключать.

А не мог драйвер быть раньше кастомным а сейчас тот что с ядром идет?

Типа каждый ВЛАН имеет свой мак? Врядли это причина. У вас же так и до проблемы было?

Он скорее всего это делает для списка портов ( 80, 21, 8080 может ) и per flow. Соответственно он не анализирует все 2 Гбита. Опустим тот факт, что если с этим тазиком что-то случится ( например поломается роутинг или приедет какой-то кривой список ), то весь трафик никуда не пойдет. Короче говоря, настоятельно рекомендуется, все виды анализа трафика ( netflow, dpi, investigation, etc. ) выносить на мирроры. Чтобы между клиентом и интернетом было только необходимое железо для работы и чтобы это железо не было занято левой работой. На заре становления, у нас, помню, в хозяйстве был целый каскад тазиков: нат, шейпинг, роутинг, может еще что-то. Оно работало, но это была шаткая конструкция, которая то и дело давала о себе знать. Короче говоря это хороший пример того как не надо делать.

В перф топе функции отправки пакета драйвером сетевой карты. Что они делают в топе и почему там только отправка да еще и с таким отрывом, совершенно не понятно. Кстати, не видно версию драйвера.

А количество принятых/отправленных пакетов примерно совпадает? Нет перекоса?

Частоту посмотрите. grep "Hz" /proc/cpuinfo Пару раз пустите для надежности. У меня, кстати, была один раз проблема: после регламентных работ роутер стал тупым. Совсем. Регламентные работы были по железу, поэтому гарантированно ничего не менялось. Выяснилось, что плохо был закреплен кулер и процессор перегреваясь тротлил. Проверьте температуру. Так, на всякий, чтобы этот вариант исключить. Но это вроде бы должен показать тест на частоту, т.к. современные процессоры не просто пропускают такты, но еще и частоту роняют.

+1 за решение на миррор портах и указания маршрутизаторам после анализа. Трафик через анализатор, пусть даже только HTTP, и пусть даже только по списку урлов - это не так просто как кажется. А завтра захотите парсить по регекспам надо будет всё перестраивать или ставить на фильтр железо мощнее чем ядро сети. У меня от "Для того, чтобы переложить ethernet-кадр с интерфейса на интерфейс, много ресурсов не нужно." тоже немного подгорело, но спешу уверить вас, alibek, что это не так, если пакет обрабатывается, а не просто копируется.

А правила в памяти совпадают с тем что в /etc/sysconfig/iptables? У вас случайно governor не слетел? Потому что это всё выглядит очень странно. Какая частота процессора по системе?

Как-то много у вас iptables. Сколько у вас сумарно правил по всем таблицам?

Тогда получается, что это та же статическая адресация, только без гемороя с правилами. Не круто же.

У таргета SAME есть ключ --nodst, который будет строить хеш только по сорцу. Это правда получится, как статическая адресация, т.к. человеку по хешу отдадут из пула реальник и он будет с ним сидеть до непонятно когда. Может кто-то попался в сорцах и знает когда происходит рехеш и происходит ли вообще? Ну или в составе хеша есть, например время?

В логах ничего не пишется, просто у вас в топе висят процессы ядра и новые соединения появляются со скоростью 1 подключение в секунду. Перф топ дает посмотреть на это одним глазком. Прямо скажу - приятного мало. Как будто работаешь в юзер-спейсе. А ну и листинг интерфейсов через тот же ifconfig идет, секунд 10-15, например.

Да. У старых ядер можно сказать: IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/17 -j SAME --to-source 93.157.x.1-93.157.x.126 Тут кто-то писал, что это дает сомнительный прирост, зато усложняет диагностику.

Нет, прерывания выполняются по таймеру, по очереди, поэтому понятия приоритета отсутствует. В вашем случае попробуйте вынести ide0 на кокретный процессор. Но в вашем примере мало данных чтобы утверждать однозначно, что это поможет. Еще как вариант, увеличьте ring buffer для сетевой, чтобы если пакеты не были забраны у карты, они оставались в буфере. Ну и queue length на интерфейсе подкрутите. Эти все манипуляции, однако, приведут к увеличению RTT во время дисковой активности, если причина в ней, конечно.

Ну и если уже говорить, про нарезку, то лучше резать /25, а то, говорят гугл /24 не любит. А вообще не вижу ниодной причины не юзать SAME с --persistent как описал это aabc.

У меня нет вариантов что это. Выглядит как будто неудачный апдейт ядра. Все процессы в топе перфа, кроме 5-ой позиции - это процессы внутри ядра. Надо смотреть исходники, чтобы понять что это. А сколько правил iptables и что они делают? 2Г трафика для такого тазика - это вообще на один зуб. Таким можно и 12-15Г обмолотить.

Для ip и tc вообще пофигу количество интерфейсов, если вы конечно не пытаетесь получить их полный список. Там были проблемы с ядрами 2.6.х и немного 3.х и когда интерфейсов было больше 500, начинался какой-то ад дедлоков. После 3.11 всё разрулили и система чувствовала себя ок на синтетике с 10К сессий. Я правда не звал tc, но ip и ifconfig работали очень быстро.

А какой трафик и какая машина? Ну и перф топ полностью покажите.

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

Правила и так обрабатываются на разных процессорах. Данная опция позволяет, судя по всему, прибить обработку на конкретный процессор. Не совсем понятно в каком сценарии такое может понадобится, но это явно не оптимизация.