[vladd]

Имеется 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% каждого, не в проце по идее дело. Что же может быть?

[Lynx10]

с нат всё в порядке ?

если быть точнее то с conntrack

Изменено 12 марта, 2012 пользователем Lynx10

[MMM]

perf top смотрите, скорее всего conntrack

[vladd]

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 правил могут вызывать такой перегруз? И почему тогда ни одно ядро процессора не затыкается, а роутится плохо?

[bos9]

ну можно же на пять минуток iptables -F и повторить тест =)

[taf_321]

Получается затык в iptables. Посмотрю еще вечером. Неужели 30 правил могут вызывать такой перегруз? И почему тогда ни одно ядро процессора не затыкается, а роутится плохо?

 

А загнать все в ipset и 1-3 правила никак не получится? Все-таки обход 30 правил при 10М и при 800М это немного разные вещи.

[vladd]

А загнать все в ipset и 1-3 правила никак не получится? Все-таки обход 30 правил при 10М и при 800М это немного разные вещи.

Был бы рад, но вижу как это сделать. Для каждого юзера требуется сопоставить "уникальный серый ip" <-> "уникальный реальник".

 

И кажется врядли в iptables тут дело - тормоза в часы пик на любых ip - и на серых (которые прогоняются через iptbles), и на реальных (которые в первых 1-2 правилах отсекаются и не идут через все дерево).

 

Когда экспериментировал с iptables и средним размером цепочки - проверял, при слишком большом количестве обрабатываемых правил (более 100) резко растет загрузка ядер. Тут же загрузки нет. Т.е. вред от iptables под большим сомнением.

Изменено 13 марта, 2012 пользователем vladd

[random7]

И почему тогда ни одно ядро процессора не затыкается, а роутится плохо?

 

Из-за блокировок, может быть?

[vladd]

Из-за блокировок, может быть?

 

Блокировки не к этому случайно относятся?:

 

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 остается без изменений. Есть ли идеи, как с этим можно бороться?

[Megas]

офтоп.

какой прогой получили

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

[voron]

perf, например из /usr/src/linux/tools

[Megas]

нашел здесь:

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?

 

#

[NiTr0]

vladd

Попробуйте обновить ядро на более свежее.

 

Megas

Английским по белому же пишет: ядро не сконфигурено для профайлинга.

[vladd]

vladd

Попробуйте обновить ядро на более свежее.

Т.е. уже на 3.2 переходить?

 

Под нагрузкой да, только до 800 мбит дошло, и на первое место вылез _raw_spin_lock_bh - 14-16%, опередив iptables. Попробую обновить ядро, там что-то серьезное фиксили разве?

[telecom]

Думаю, и на 3.2.10 у Вас будет _raw_spin_lock на первом месте...

Надо искать, откуда эти блокировки идут!

[Alex/AT]

Неплохо бы полный набор правил iptables видеть еще.

Чтобы снизить число блокировок в igb (если это конечно igb в данном случае) - увеличьте для начала очереди rx/tx на карточках через ethtool до максимально возможных значений, и ifconfig'ом софтовую tx очередь (txqueuelen) выставите также в размер аппаратной.

Изменено 14 марта, 2012 пользователем Alex/AT

[lllsergeyv]

vladd

Попробуйте обновить ядро на более свежее.

 

Какое ядро посоветуете? стоит с 2.6 уже слазить?

Изменено 14 марта, 2012 пользователем lllsergeyv

[NiTr0]

Попробую обновить ядро, там что-то серьезное фиксили разве?

Локи вычищали в частности. На ядра 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, соответственно стоит остановиться на нем пока.

[lllsergeyv]

Какое ядро посоветуете? стоит с 2.6 уже слазить?

Объявление 3-й ветки не связано с гигантскими изменениями по сравнению с 2.6. Различия между 2.6.39 и 3.0 не больше, чем к примеру между 2.6.34 и 2.6.35.

3.2 позиционируется как long-term, соответственно стоит остановиться на нем пока.

у меня еще 2.6.32 debian

[NiTr0]

Первая заповедь инженера - "работает - не трогай". О смене ядра стоит задумываться только в том случае, когда текущее чем-то не устраивает.

[lllsergeyv]

Первая заповедь инженера - "работает - не трогай". О смене ядра стоит задумываться только в том случае, когда текущее чем-то не устраивает.

 

По производительности пока устраивает. смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe). ping latency по всем направлениям через роутер в это время тоже немного увеличивается.

Изменено 14 марта, 2012 пользователем lllsergeyv

[NiTr0]

смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe)

Может энергосбережение работает, частота ядер снижается? ;) Тогда будет сходный эффект (рост нагрузки при снижении траффика ступенькой, небольшой рост пингов).

[telecom]

смущает только то, что при малом трафике(меньше 200мбит) возростает загрузка проца(сетевушки ixgbe)

Может энергосбережение работает, частота ядер снижается? ;) Тогда будет сходный эффект (рост нагрузки при снижении траффика ступенькой, небольшой рост пингов).

Это только я всегда думал, что на маршрутизаторах надо отключать энергосберегающие плюшки типа cpu_idle cpu_freq ибо от них больше вреда, чем пользы?

[NiTr0]

А какой вред-то, по большому счету? Рост пинга на 0.5 мс при малой нагрузке? Или некрасивые графики? :)

А вот если стойка юзает в качестве резервного источника энергии батареи - то энергосбережение тут вполне пригодится. Ибо каждый ватт на счету при отключении основного источника.

[Alex/AT]

Стоп. Я заметил i686 в названии пакета. У Вас действительно - x86-ядро, не x86-64? Сколько памяти на машине? PAE включено?