GFORGX Опубликовано 18 января, 2010 (изменено) · Жалоба Имеется PPPoE-сервер, по которому ходит трафик внутрисетевого торрента и пользовательских игровых серваков. Работает всё это на linux-2.6.28.7, pppd-2.4.4, rp-pppoe-3.10. Сервер - 2 двухъядерных Intel P4 Xeon, 4 гигабитных интерфейса Broadcom NetXtreme, 4 гигабайта памяти. 4 интерфейса объединены в round-robin бондинг, на свитче настроен link aggregation для нужных портов. Прерывания сетевушек перекинуты на первый физический процессор (чтобы не было прыжков между процессорами во время обработки пакетов), процессы pppd перекидываются на второй физический процессор. Трафик шейпится, но по вечерам этих 4 гигабитов иногда начинает не хватать, ибо физически они не дают больше ~1.5 Gbps вместе взятые. Максимальный достижимый packet rate - не более 120 kpkt/s. Пробовали менять настройки TCP в net.core и net.ipv4 по http://www.opennet.ru/docs/RUS/GigabitEthernet/, включать Jumbo Frames и на сервере, и на свитче, - ничуть не изменило ситуацию. Это первая проблема. Вторая - иногда на нулевых loadavg этот сервер банально зависает по ночам, когда всего-то около 100 PPPoE-сессий. Пробовали менять память, отключать ACPI. Иногда перед зависанием в dmesg плюётся: INFO: task pppd:30267 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. pppd D 00000000 2528 30267 3418 e5461100 00000086 001280d2 00000000 00000003 f1072030 f1072288 c4c26600 00000000 4a0c5065 00000001 c046055b ffffffff f4592200 00000000 00000000 00000000 faff5c8c faff5ca0 faff5c90 f1072030 c0632819 dfdcfe80 f3c12f34 Call Trace: [<c046055b>] handle_mm_fault+0x755/0x7eb [<c0632819>] __mutex_lock_slowpath+0x50/0x7e [<c06326cb>] mutex_lock+0x21/0x24 [<faff11de>] ppp_shutdown_interface+0xf/0xa1 [ppp_generic] [<faff1408>] ppp_release+0x20/0x4d [ppp_generic] [<c0474fb1>] __fput+0xc8/0x17a [<c04729d8>] filp_close+0x4d/0x53 [<c0472a49>] sys_close+0x6b/0xa2 [<c0403851>] sysenter_do_call+0x12/0x21 Но к зависанию это приводит не всегда, так что списываю просто на совпадение. Сейчас аптайм уже 11 суток, но иногда зависает по несколько ночей подряд. Буду благодарен идеям. Изменено 18 января, 2010 пользователем GFORGX Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 18 января, 2010 · Жалоба Jumbo Frames вообще ни в какую не относится к вашей ситуации. Я бы для начала посмотрел опции модулей броадкома на предмет napi или ограничения кол-ва прерываний + увеличения буферов на сетевую карту. Зависания - наверно в ядре дебаг придется включать, хз правда как это у вас скажется на производительности, но точно не лучшую сторону. Можно у народа поспрашать начет версий стабильных связок kernel, pppd, rp-pppoe и попробовать себе поставить такие версии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...