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

Linux NAS+shaping тормозит на 500+ клиентах 50Kpps кушает почти 100% одной головы E2180

Упорно и долго ползал по всему интернету, включая nag.ru, но ответа не нашёл.

 

Итак:

1. PPPoE NAS - Gentoo 2.6.19 (кое-где 23, но сути к сожалению не меняет) на совершенно различных аппаратных конфигурациях, в основном Dell R200 на Intel® Pentium® Dual CPU E2180 @ 2.00GHz, 1Gb RAM.

2. Сетевые карты соответственно где какие - модификации Broadcom, Intel 1000, но все гигабитные. В разной степени подвержены тюнингу с помощью ethtool, но опять же на проблему тюнинг даже самой крутой интеловской карточки никак не влияет.

3. На NAS клиенты шейпятся по направлениям (городской трафик быстрее раз в 10 нежели по основному тарифному плану).

4. Шейпинг исходящего трафика сделан на интерфейсе аплинка, впрочем его отключение так же картину не меняет.

 

Собственно картина такова: при количестве ppp интерфейсов примерно так от 500 (зависит от процессора) у клиентов (у всех, вне зависимости от шейпера - хоть 100Мбит) начинаются потери пакетов. 500 клиентов соответствуют примерно 50Kpps (при 300Mbit), думаю для таких аппаратов это совсем не предел, а по факту - загрузка CPU 50% (тобишь один CPU занимается чисто сетью), всё в softirq, userspace ~ 0%.

 

tts-2 ~ # cat /proc/interrupts 
          CPU0       CPU1       
 0:   84547943        451   IO-APIC-edge      timer
 1:          2          0   IO-APIC-edge      i8042
 8:          4          1   IO-APIC-edge      rtc
 9:          0          0   IO-APIC-fasteoi   acpi
12:          0          4   IO-APIC-edge      i8042
18:         71         11   IO-APIC-fasteoi   libata
19:      10441         21   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
20:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
219: 2008095683 2050353622   PCI-MSI-edge      eth0
NMI:   84548339   84548306 
LOC:        451   84547856 
ERR:          0
MIS:          0

 

Типичный шейпер на одном из клиентов:

 

tts-2 ~ # tc qdisc ls dev ppp609
qdisc htb 1: root r2q 10 default 1 direct_packets_stat 13
qdisc sfq b85b: parent 1:1 limit 127p quantum 1492b perturb 10sec 
qdisc sfq b85c: parent 1:2 limit 127p quantum 1492b perturb 10sec 
tts-2 ~ # tc class ls dev ppp609
class htb 1: root rate 100000Kbit ceil 100000Kbit burst 51787b cburst 51787b 
class htb 1:1 parent 1: leaf b85b: prio 0 rate 880000bit ceil 880000bit burst 2Kb cburst 2Kb 
class htb 1:2 parent 1: leaf b85c: prio 0 rate 880000bit ceil 880000bit burst 2Kb cburst 2Kb 
tts-2 ~ # tc filter ls dev ppp609
filter parent 1: protocol ip pref 5 u32 
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 
 match d594a200/fffffe00 at 12
filter parent 1: protocol ip pref 5 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:2 
 match d594a000/ffffff80 at 12

 

Если что не упомянул - извините, уточню, голова уже пухнет - это только одна из нескольких висящих проблем.

Edited by RushOnline

Share this post


Link to post
Share on other sites
по факту - загрузка CPU 50% (тобишь один CPU занимается чисто сетью), всё в softirq, userspace ~ 0%.

что-то у меня ощущение что это ответ на ваш вопрос

Share this post


Link to post
Share on other sites
по факту - загрузка CPU 50% (тобишь один CPU занимается чисто сетью), всё в softirq, userspace ~ 0%.

что-то у меня ощущение что это ответ на ваш вопрос

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

 

Впрочем заглянул я сюда не зря - только что выяснил интересный факт, при одной и той же нагрузке сраненький Pentium D 3.4GHz с включеным гипертредингом усирается чуть больше, чем навороченный двухголовый двухядерный Xeon L5420 2.50GHz. Единственное в них отличие - в D стоит Intel 82573V, а в Xeon - Broadcom BCM5708. Что кагбэ намекает. Но полностью уверенности пока нет.

Share this post


Link to post
Share on other sites
К сожалению нет, ибо из первого блока, который я привёл в первом сообщении хорошо видно, что прерывания обрабатываются обоими процессорами примерно поровну. То есть задел по мощности ещё есть.
Нет. Они обрататываются по очереди, но не одновременно двумя. Т.е. потолок - 50%.

 

Попробуйте "прибить" прерывания сетевой насильно к одному любому ядру.

 

Share this post


Link to post
Share on other sites
загрузка CPU 50% (тобишь один CPU занимается чисто сетью)
219: 2008095683 2050353622 PCI-MSI-edge eth0
echo 1 >/proc/irq/219/smp_affinity

После чего убедиться, что сетевая сожрала 100% ядра. Если так (а оно скорее всего так, исходя из 50%), начать думать над заменой сетевой на интеловую с multiqueue.

pppoed ядерный? Хотя на 50kpps наверное да.

Share this post


Link to post
Share on other sites
Нет. Они обрататываются по очереди, но не одновременно двумя. Т.е. потолок - 50%.
Да, конечно я это знаю. Наверно я не правильно понял предыдущего оратора.

 

Попробуйте "прибить" прерывания сетевой насильно к одному любому ядру.
Не знаю... Что это даст ? На первый взгляд то же самое, вид сбоку, ибо переключений контекста столько же.

 

echo 1 >/proc/irq/219/smp_affinity

После чего убедиться, что сетевая сожрала 100% ядра. Если так (а оно скорее всего так, исходя из 50%), начать думать над заменой сетевой на интеловую с multiqueue.

pppoed ядерный? Хотя на 50kpps наверное да.

Спасибо за хинт про аффинити, часто тут встречал сообщения про привязку прерываний к одному CPU, но ни разу что то не видел _как_ это сделать. Причём как ни странно там уже единички:

 

at64 ~ # cat /proc/irq/220/smp_affinity 
1

 

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

 

П.С.: Почитал код шедулера пакетов - нечему там тормозить. По крайней мере на современном процессоре. Где же тот код, что его ест ?!

Edited by RushOnline

Share this post


Link to post
Share on other sites
Не знаю... Что это даст ? На первый взгляд то же самое, вид сбоку, ибо переключений контекста столько же.
Это даст более эффективное использование кеша процессора, разница может оказаться очень существенна. Если кеша много, конечно.

 

Причём как ни странно там уже единички:
Вероятно косяк драйвера, попробуйте выключить MSI.

 

Share this post


Link to post
Share on other sites

RushOnline, а если вообще отключить шейпер вход/исход нагрузка падает? Может нужно сделать оптимизацию шейперов (hashing filters) ?

Из твоего первого поста видно что все фильтры подключены к одному корневому, что не есть хорошо.

Допустим у тебя 500 правил, т.е каждый пакет в среднем проходит 250 проверок - а при большой нагрузке это много.

Edited by hub00

Share this post


Link to post
Share on other sites
Может нужно сделать оптимизацию шейперов (hashing filters)
коллега, если есть развернутая тема ссылочку на ветку можете кинуть? есть аналогичная проблема.
а если вообще отключить шейпер вход/исход нагрузка падает?
в моем случае при снятии шейпера, канал выходит на максимум. тормозов нет.

процесс ksoftirqd в топе опускается вниз на 0% по cpu.

 

надо шейпер переделать, хочется сделать все правильно. оптимизировано.

Edited by militar katze

Share this post


Link to post
Share on other sites
Может нужно сделать оптимизацию шейперов (hashing filters) ?

Кстати да, не ясно как у автора реализован шейпинг исходящего от клиентов трафика, полисера на ppp интерфейсе не видно, если всё сплошняком на eth0 - надо переделывать.

 

Share this post


Link to post
Share on other sites

Я пользовался этим материалам в последствии и выложил его у себя. Я думаю должно хватить этого для понимания.

 

Оптимізація шейпера (HTB) — hashing filters

12.4. Хеш-фильтры

Edited by hub00

Share this post


Link to post
Share on other sites
Спасибо за хинт про аффинити, часто тут встречал сообщения про привязку прерываний к одному CPU, но ни разу что то не видел _как_ это сделать.

В догонку Linux SMP-affinity

Share this post


Link to post
Share on other sites

Причём как ни странно там уже единички:

А, 19-е ядро :) Надо отключить CONFIG_IRQBALANCE в конфиге ядра. Чтоб оно само не перекидывало сетевуху с ядра на ядро. И после этого уже самому привязать к нужному процессору. Ну и самом собой оптимизировать фильтры, как подсказывают коллеги.

Share this post


Link to post
Share on other sites
Я пользовался этим материалам в последствии и выложил его у себя. Я думаю должно хватить этого для понимания.

 

Оптимізація шейпера (HTB) — hashing filters

12.4. Хеш-фильтры

эммм... почитал, вроде статьи одинаковые практически? только та, которая на украинском приложена к конкретной вашей ситуации?

Share this post


Link to post
Share on other sites
Я пользовался этим материалам в последствии и выложил его у себя. Я думаю должно хватить этого для понимания.

 

Оптимізація шейпера (HTB) — hashing filters

12.4. Хеш-фильтры

эммм... почитал, вроде статьи одинаковые практически? только та, которая на украинском приложена к конкретной вашей ситуации?

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

Edited by hub00

Share this post


Link to post
Share on other sites
Вероятно косяк драйвера, попробуйте выключить MSI.
Странно, но я наоборот, много раз видел на nag.ru что MSI надо включать. Что даст смена MSI на ACPI или что-там ?

 

А, 19-е ядро :) Надо отключить CONFIG_IRQBALANCE в конфиге ядра. Чтоб оно само не перекидывало сетевуху с ядра на ядро. И после этого уже самому привязать к нужному процессору. Ну и самом собой оптимизировать фильтры, как подсказывают коллеги.
Ага, вот это уже дело, ибо как говорит
Это даст более эффективное использование кеша процессора, разница может оказаться очень существенна. Если кеша много, конечно.
Придётся перекомпилировать ведро, теперь осталось выяснить, как скомпилить то самое ведро с теми самыми патчами той самой gentoo, дабы не поломать ps, top etc. Может осталось у кого, ибо с нуля это два дня компиляций (конфиг ведра слава богу есть) ? Ибо прародитель этой прошивки давно канул в лету, а на свежем дистрибе пока сделать ниасилили, хотя давно пора перебираться на x64 (кроме этих 20-ти NAS у нас больше x32 и нету, даже на десктопах...).

 

Напоследок отвечаю ниасилившим моё первое сообщение (как я вас понимаю, ребята, сам не люблю такие портянки читать без человеческих комментариев, но писать комментарии уже не было сил), осилившие же могут скипнуть остаток мессаги:

 

1. Шейперы вешаются на абонентский ppp интерфейс, так как шейпить мы можем только исходящий трафик. А входящий для абонента трафик это и есть исходящий с ppp-интерфейса NAS.

2. Корневая дисциплина - HTB, её класс по-умолчанию - максимальная пропускная способность интерфейса, у нас она 100Mbit.

3. В эти 100Мбит входят два класса - шейпер, заданный по умолчанию в корневой дисциплине и шейпер на локальные ресурсы.

4. И главный пункт - в класс, определяющий скорость на локальные ресурсы, пакеты отправляют всего два u32 фильтра - ХЕШИ ИСПОЛЬЗОВАТЬ НЕ ТОЛЬКО БЕССМЫСЛЕННО, НО И ВРЕДНО ДЛЯ ПРОИЗВОДИТЕЛЬНОСТИ :)

 

Хешированные фильтры у нас применяются, но, как я уже упоминал, на интерфейсе аплинка, ибо тут мы уже шейпим исходящий трафик абонента, и уже не можем это сделать на его ppp-интерфейсе (на входящий трафик можно только policer ставить). Там - да, там применяются, но, как опять же я уже писал в первом сообщении их отключение заметного прироста производительности не даёт.

Share this post


Link to post
Share on other sites
Странно, но я наоборот, много раз видел на nag.ru что MSI надо включать. Что даст смена MSI на ACPI или что-там ?
Да, но если MSI глючит, его лучше выключить, я только это имел ввиду :)

 

Еще вариант - повесить аплинк на отдельный сетевой интерфейс, это позволит использовать 2 ядра.

 

Share this post


Link to post
Share on other sites

за то что если перед глазами больше примеров так лучше понять и если они помогут я буду только рад.

несомненно. штудирую внимательно. снес пример отдельно от текста - разбираю. спасибо.

Share this post


Link to post
Share on other sites

Я на всякий случай еще раз спрошу: pppoed ядерный или в юзерспейсе?

Share this post


Link to post
Share on other sites
Я на всякий случай еще раз спрошу: pppoed ядерный или в юзерспейсе?

Конечно ядерный, если бы он был в юзерспейс, думаю дело до 50Кп/с бы не дошло. И процессор кушал бы не software irq, а pppoe. Сегодня начали работу над новой прошивкой, закидывайте меня помидорами, но это ubuntu server. Пока 9.10, но с расчётом - когда прошивка будет готова к злому тестированию, уже наверняка выйдет 10.04, а это LTS на 5 лет. Позже и дебиан свежий стабилизируется (думаю к осени). У нас есть свой комп - сборщик пакетов (типа ланчпада, но попроще), так что за оптимизацию и перекомпиляцию самых ответственных вещей можно не беспокоиться, будет и то и другое + патчи под чисто наши нужды. Впрочем это уже другой вопрос, и надо открывать тему (если нету такой) - "Выбор дистрибутива для PPPoE NAS с шейпером" :)

 

Если есть желающие почитать, как будет создаваться NAS - отпишитесь тут, и я постараюсь все основные шаги опубликовать в блоге. Все мы когда то с чего то начинали, и лет пять назад я бы с удовольствием почитал что-нибудь такое, да ещё и на русском. А просто так писать, в надежде что когдаааа нибудь комуууу нибудь понадобится (ещё и найдётся в поисковике) - времени нет, да и ленииииво :)

Edited by RushOnline

Share this post


Link to post
Share on other sites

Если вы это мне - абсолютно не наш вариант. Мы раздаём фиксированные, но разные полосы и ничего между ними не делим. Не хватает аплинка - подключаем второй. Смысл использования imq/ifb появляется только тогда, когда исходящий трафик идёт на разных логических линках (не бондится). Если аплинк один - исходящий интерфейс и есть тот самый ifb/imq, и без всяких извращений типа патча в и так дырявое ведро.

Share this post


Link to post
Share on other sites
Если вы это мне - абсолютно не наш вариант. Мы раздаём фиксированные, но разные полосы и ничего между ними не делим. Не хватает аплинка - подключаем второй. Смысл использования imq/ifb появляется только тогда, когда исходящий трафик идёт на разных логических линках (не бондится). Если аплинк один - исходящий интерфейс и есть тот самый ifb/imq, и без всяких извращений типа патча в и так дырявое ведро.

весь мой пост сводился к тому, что нужно чаще использовать склассификатор flow как более удобную замену хешам, пост ^^^ не асилил.

Share this post


Link to post
Share on other sites
Цепочки iptables есть ?
Я ждал этого впроса :) Да. Есть. Количество правил ~ количеству ppppoe-интерфейсов (антиспуф) + пара правил для маркировки локального трафика + пара правил в таблице nat для прокидывания клиентов с серыми адресами (завирусованные, деньги кончились и т.д.) к личному кабинету.

 

В таблице маршрутизации ничего лишнего, таблица тоже ~ кол-во pppoe-интерфейсов + несколько служебных.

 

Итого, тормозня начинается примерно от 700 зашейпленных pppoe-интерфейсов, 700 правил антиспуфа и 700 маршрутов. Из за тех двух правил в таблице nat используется ip/nf_conntrack, hashsize которому задан 200000.

 

Кстати после установки ethtool -G eth0 rx <max_rx> tx <max_tx> и echo 200000 > /sys/modules/ip_conntrack/parameters/hashsize клиентам полегчало, пакеты почти перестали дропаться.

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