vladd Posted March 12, 2012 Имеется PC-роутер, с ядром 2.6.39 и 4-портовой сетевухой Intel 82576. Есть входящий линк от провайдера на интерфейс bond0, скорость на котором 1 гбит/c, и исходящий eth2 на локалку - пока без бондинга. Бондинг на провайдерском линке сделан заранее под расширение в будущем, суть не в этом. Также имеется суммарно около 30-40 правил в iptables (таблицы nat, raw и rawpost). Все качается и роутится замечательно. Так вот, стоит только юзерам загрузить канал свыше 800 мбит/c - так начинаются тормоза при роутинге. Но при этом есть странности: 1. Ни одно ядро не загружается больше 50% (прерывания каждого порта сетевухи жестко назначены на свое ядро). 2. Если качать из инета на сам сервер (wget-ом) - то скорость в один поток превышает 7-10 мбайт/c - что говорит о хорошем запасе у провайдера. 3. Если качать с сервера (там стоит тестовый апач) в локалку, то скорость в один поток - тоже около 10 мбайт/c, т.е. запас на внутреннем линке есть (!). Но, если качать тот же файл что и в п.2 из инета через роутер с любого хоста в локалке, скорость не превышает 500-1000 кбайт/c, иногда и ниже. Учитывая п.2 и 3, ничего не понимаю. Как может локально качаться нормально на обоих интерфейсах, а транзитом тоже самое - тормозить. Уже всю голову сломал. Тюнил что только можно. Помогите, хоть какой-нибудь совет.. Шейперов нет, tc qdisc пусто. Проц Core i5-2500 @ 3.30GHz. Еще раз - загрузка ядер меньше 50% каждого, не в проце по идее дело. Что же может быть? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Lynx10 Posted March 12, 2012 (edited) с нат всё в порядке ? если быть точнее то с conntrack Edited March 12, 2012 by Lynx10 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
MMM Posted March 13, 2012 perf top смотрите, скорее всего conntrack Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vladd Posted March 13, 2012 conntrack точно не причем, т.к. одинаково плохо качается и с ната, и с реальников. Более того, недавно заменил conntrack на 1:1 нат через правила RAWSNAT/RAWDNAT - качается все также плохо в часы пик, как и с обычным натом. Каждому абоненту при авторизации динамически создается 2 правила (по типу licg), а чтобы не было перегрузки iptables, используются древовидные цепочки в iptables. Этих цепочек порядка 2000, зато получается что пакет по пути проходит не более чем через 20-40 правил. Вот что показывает perf top днем: 3128.00 13.8% ipt_do_table /lib/modules/2.6.39.4/kernel/net/ipv4/netfilter/ip_tables.ko 1514.00 6.7% igb_poll /lib/modules/2.6.39.4/kernel/drivers/net/igb/igb.ko 1010.00 4.5% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux 758.00 3.3% ip_route_input_common /lib/modules/2.6.39.4/build/vmlinux 593.00 2.6% nf_iterate /lib/modules/2.6.39.4/build/vmlinux 541.00 2.4% kfree /lib/modules/2.6.39.4/build/vmlinux Получается затык в iptables. Посмотрю еще вечером. Неужели 30 правил могут вызывать такой перегруз? И почему тогда ни одно ядро процессора не затыкается, а роутится плохо? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bos9 Posted March 13, 2012 ну можно же на пять минуток iptables -F и повторить тест =) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
taf_321 Posted March 13, 2012 Получается затык в iptables. Посмотрю еще вечером. Неужели 30 правил могут вызывать такой перегруз? И почему тогда ни одно ядро процессора не затыкается, а роутится плохо? А загнать все в ipset и 1-3 правила никак не получится? Все-таки обход 30 правил при 10М и при 800М это немного разные вещи. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vladd Posted March 13, 2012 (edited) А загнать все в ipset и 1-3 правила никак не получится? Все-таки обход 30 правил при 10М и при 800М это немного разные вещи. Был бы рад, но вижу как это сделать. Для каждого юзера требуется сопоставить "уникальный серый ip" <-> "уникальный реальник". И кажется врядли в iptables тут дело - тормоза в часы пик на любых ip - и на серых (которые прогоняются через iptbles), и на реальных (которые в первых 1-2 правилах отсекаются и не идут через все дерево). Когда экспериментировал с iptables и средним размером цепочки - проверял, при слишком большом количестве обрабатываемых правил (более 100) резко растет загрузка ядер. Тут же загрузки нет. Т.е. вред от iptables под большим сомнением. Edited March 13, 2012 by vladd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
random7 Posted March 13, 2012 И почему тогда ни одно ядро процессора не затыкается, а роутится плохо? Из-за блокировок, может быть? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vladd Posted March 13, 2012 Из-за блокировок, может быть? Блокировки не к этому случайно относятся?: 2232.00 13.7% ipt_do_table /lib/modules/2.6.39.4/kernel/net/ipv4/netfilter/ip_tables.ko 1030.00 6.3% igb_poll /lib/modules/2.6.39.4/kernel/drivers/net/igb/igb.ko 951.00 5.8% _raw_spin_lock_bh /lib/modules/2.6.39.4/build/vmlinux 676.00 4.2% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux Нагрузка возрастает, и появляется _raw_spin_lock, при том что ipt_do_table остается без изменений. Есть ли идеи, как с этим можно бороться? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Megas Posted March 13, 2012 офтоп. какой прогой получили 2232.00 13.7% ipt_do_table /lib/modules/2.6.39.4/kernel/net/ipv4/netfilter/ip_tables.ko 1030.00 6.3% igb_poll /lib/modules/2.6.39.4/kernel/drivers/net/igb/igb.ko 951.00 5.8% _raw_spin_lock_bh /lib/modules/2.6.39.4/build/vmlinux 676.00 4.2% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
voron Posted March 13, 2012 perf, например из /usr/src/linux/tools Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Megas Posted March 13, 2012 нашел здесь: http://www.mmnt.net/db/0/0/ftp.spline.de/pub/dhozac/centos/5/vserver/i386 perf-2.6.32-131.12.1.el5.vs2.3.0.36.29.6.18.i686.rpm но при запуске свистит: # perf top Error: sys_perf_event_open() syscall returned with -1 (Function not implemented). /bin/dmesg may provide additional information. Fatal: No CONFIG_PERF_EVENTS=y kernel support configured? # Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted March 13, 2012 vladd Попробуйте обновить ядро на более свежее. Megas Английским по белому же пишет: ядро не сконфигурено для профайлинга. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vladd Posted March 13, 2012 vladd Попробуйте обновить ядро на более свежее. Т.е. уже на 3.2 переходить? Под нагрузкой да, только до 800 мбит дошло, и на первое место вылез _raw_spin_lock_bh - 14-16%, опередив iptables. Попробую обновить ядро, там что-то серьезное фиксили разве? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
telecom Posted March 13, 2012 Думаю, и на 3.2.10 у Вас будет _raw_spin_lock на первом месте... Надо искать, откуда эти блокировки идут! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Alex/AT Posted March 14, 2012 (edited) Неплохо бы полный набор правил iptables видеть еще. Чтобы снизить число блокировок в igb (если это конечно igb в данном случае) - увеличьте для начала очереди rx/tx на карточках через ethtool до максимально возможных значений, и ifconfig'ом софтовую tx очередь (txqueuelen) выставите также в размер аппаратной. Edited March 14, 2012 by Alex/AT Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
lllsergeyv Posted March 14, 2012 (edited) vladd Попробуйте обновить ядро на более свежее. Какое ядро посоветуете? стоит с 2.6 уже слазить? Edited March 14, 2012 by lllsergeyv Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted March 14, 2012 Попробую обновить ядро, там что-то серьезное фиксили разве? Локи вычищали в частности. На ядра 2.6.36-37...2.6.39 вроде как тут жаловались, странности с шейперами и т.п. Второй вариант - попытаться откатиться на 2.6.35. С ним вроде как я особых странностей не наблюдал. Какое ядро посоветуете? стоит с 2.6 уже слазить? Объявление 3-й ветки не связано с гигантскими изменениями по сравнению с 2.6. Различия между 2.6.39 и 3.0 не больше, чем к примеру между 2.6.34 и 2.6.35. 3.2 позиционируется как long-term, соответственно стоит остановиться на нем пока. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
lllsergeyv Posted March 14, 2012 Какое ядро посоветуете? стоит с 2.6 уже слазить? Объявление 3-й ветки не связано с гигантскими изменениями по сравнению с 2.6. Различия между 2.6.39 и 3.0 не больше, чем к примеру между 2.6.34 и 2.6.35. 3.2 позиционируется как long-term, соответственно стоит остановиться на нем пока. у меня еще 2.6.32 debian Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted March 14, 2012 Первая заповедь инженера - "работает - не трогай". О смене ядра стоит задумываться только в том случае, когда текущее чем-то не устраивает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
lllsergeyv Posted March 14, 2012 (edited) Первая заповедь инженера - "работает - не трогай". О смене ядра стоит задумываться только в том случае, когда текущее чем-то не устраивает. По производительности пока устраивает. смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe). ping latency по всем направлениям через роутер в это время тоже немного увеличивается. Edited March 14, 2012 by lllsergeyv Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted March 14, 2012 смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe) Может энергосбережение работает, частота ядер снижается? ;) Тогда будет сходный эффект (рост нагрузки при снижении траффика ступенькой, небольшой рост пингов). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
telecom Posted March 15, 2012 смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe) Может энергосбережение работает, частота ядер снижается? ;) Тогда будет сходный эффект (рост нагрузки при снижении траффика ступенькой, небольшой рост пингов). Это только я всегда думал, что на маршрутизаторах надо отключать энергосберегающие плюшки типа cpu_idle cpu_freq ибо от них больше вреда, чем пользы? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted March 15, 2012 А какой вред-то, по большому счету? Рост пинга на 0.5 мс при малой нагрузке? Или некрасивые графики? :) А вот если стойка юзает в качестве резервного источника энергии батареи - то энергосбережение тут вполне пригодится. Ибо каждый ватт на счету при отключении основного источника. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Alex/AT Posted March 19, 2012 Стоп. Я заметил i686 в названии пакета. У Вас действительно - x86-ядро, не x86-64? Сколько памяти на машине? PAE включено? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
