Jump to content
Калькуляторы

Linux под нагрузкой лыжи не едут

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

Share this post


Link to post
Share on other sites

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

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

Edited by Lynx10

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Edited by vladd

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

офтоп.

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

нашел здесь:

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?

 

#

Share this post


Link to post
Share on other sites

vladd

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

 

Megas

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

Share this post


Link to post
Share on other sites

vladd

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

vladd

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

 

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

Edited by lllsergeyv

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

у меня еще 2.6.32 debian

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Edited by lllsergeyv

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this