загрузка проца

[Небесный]

Та, шо вы там понимаете, бсд, линуксы - о чем вы?

ОКНА рулят.

[nightfly]

Да. Из натурального дерева в особенности. Они полезней для здоровья

[AoW]

[AoW]

ну что сказать:

после перехода на нас + айписет радость была не долгой.

Радовались до тех пор, пока не заметили что шейпер не работает корректно (как же проверить, у самих та нет лимита ). Нашли ошибку, бутнулись. дождались вечера и поняли что ничего это не помогло.

Тормоза по вечерам вернулись, опять вылазит ksoftirqd (грузит процентов на 50), а также появился процесс events, про который внятного ответа нет в нете, ясно только то, что это все та же сеть. Сетевая e1000e, двухпортовая, РТ. В логах начало проскакивать

[256042.406475] HTB: quantum of class 14240 is big. Consider r2q change.

[256168.710623] HTB: quantum of class 10240 is big. Consider r2q change.

[256168.716280] HTB: quantum of class 14240 is big. Consider r2q change.

 

От других слышал, что у htb есть лимит в 200 Мбит и в 500 хомячков, что мол дальше ему тяжело живется.

Что дальше делать не знаю, планирую переход на FreeBSD + транк сетевух.

Кто что скажет из знающих и более опытных?

[madf]

Я скажу что на бывшей работе была ситуация 1-в-1. Решили переходом на фрю. Но я подозреваю что все дело в админе. У нас админ, который за насы отвечал, во фре разбирался хорошо, а в линуксе не очень.

[SpiderX]

Я скажу что на бывшей работе была ситуация 1-в-1. Решили переходом на фрю.

Лукавите

Ситуация такая была на натах. На натах она решилась, отказом от натов, и использованием белых айпи.

Ситуация такая была и на НАСах, но там вопрос решился в конечном итоге отказом от шейпинга, и переходом на полисинг, вашими же стараниями

[AoW]

Я скажу что на бывшей работе была ситуация 1-в-1. Решили переходом на фрю.

Лукавите

Ситуация такая была на натах. На натах она решилась, отказом от натов, и использованием белых айпи.

Ситуация такая была и на НАСах, но там вопрос решился в конечном итоге отказом от шейпинга, и переходом на полисинг, вашими же стараниями

На белые айпи перейти на данный момент нет возможности, так что отпадает.

Про полисинг еще не слышал, попробую погуглить, если кто че знает конкретное поделитесь коль не жалко! ))

[madf]

Я скажу что на бывшей работе была ситуация 1-в-1. Решили переходом на фрю.

Лукавите

Ситуация такая была на натах. На натах она решилась, отказом от натов, и использованием белых айпи.

Ситуация такая была и на НАСах, но там вопрос решился в конечном итоге отказом от шейпинга, и переходом на полисинг, вашими же стараниями

Не совсем так. От ната не сразу отказались и Сергеевы сервера справлялись с нагрузкой намного лучше чем Женины. Это я хорошо помню, т.к. сам тогда ковырял проблему с softirq пока Сергей серваки не позахватывал.

[KaYot]

ну что сказать:

после перехода на нас + айписет радость была не долгой.

Радовались до тех пор, пока не заметили что шейпер не работает корректно (как же проверить, у самих та нет лимита ). Нашли ошибку, бутнулись. дождались вечера и поняли что ничего это не помогло.

Тормоза по вечерам вернулись, опять вылазит ksoftirqd (грузит процентов на 50), а также появился процесс events, про который внятного ответа нет в нете, ясно только то, что это все та же сеть. Сетевая e1000e, двухпортовая, РТ. В логах начало проскакивать

[256042.406475] HTB: quantum of class 14240 is big. Consider r2q change.

[256168.710623] HTB: quantum of class 10240 is big. Consider r2q change.

[256168.716280] HTB: quantum of class 14240 is big. Consider r2q change.

 

От других слышал, что у htb есть лимит в 200 Мбит и в 500 хомячков, что мол дальше ему тяжело живется.

Что дальше делать не знаю, планирую переход на FreeBSD + транк сетевух.

Кто что скажет из знающих и более опытных?

"TB: quantum of class 14240 is big. Consider r2q change." стандартное сообщение, в документации про это есть. Это всего лишь сообщение системы о том, что дефолтный r2q(делитель rate/quantum) при заданных вами параметрах не катит и HTB принял решение об автоматической его подстройке. Мессага ни чего плохого не говорит, что б ее не видеть выставьте r2q(а лучше - quantum) вручную.

 

Про 200мбит и 500 юзеров ерунда, у нас до гига трафика с 1к юзеров на сервер в час пик бывает и ничего, загрузка близка к нулевой.

[AoW]

вчера отключил шейпинг исходящего трафика - жить стало значительно веселее (:

 

Про 200мбит и 500 юзеров ерунда, у нас до гига трафика с 1к юзеров на сервер в час пик бывает и ничего, загрузка близка к нулевой.

 

можно вопрос: какие-то особенные секреты есть? Можно в двух словах про конфигурацию?

[DarkSpider]

Вопрос на самом деле актуальный и для меня.

По softirq - проблема решилась с переходом на ipset и плюс тюнинг сетевух и ядра.

AoW - в аську тебе описывал и то и другое.

После увеличения тарифов начало вылезать

[256168.716280] HTB: quantum of class 14240 is big. Consider r2q change.

Решения в нете не нашел, но :

1. Я думаю это из-за разницы в скоростях шейпа - у нас от 512 до 50М.

Стандартное значение r2q - 10. Если вручную выставить 107( для нас примерно так вычислил) то ругаться не будет при скоростях от 2М до 50М.

по lartc:

tc qdisc add dev eth0 root handle 1: htb default 10 r2q 1
Smallest rate : 16kbit = 2kilobyte / r2k = 2000. And this is > 1500. So no warnings.
Biggest rate : 100mbit = 12.5 mbyte / r2q = 12.5 Mbyte > 60.000. So you get warnings. But you can overrule the quantum :
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 128kbit burst 2k quantum 60000

т.е. 512kbit = 64kilobyte / 10 (наш r2q) = 6400 и это > 1500 - ошибок нет

50 Мбит будет больше 60000 - есть ошибки.

т.е. надо уложиться в число от 1500 до 60000.

Так как изменение r2q влияет на точность шейпа - я его не трогал, а просто как советовали выше при шейпах вручную указал quantum 60000

tc class add dev eth0 parent 1:1 classid 1:11 htb rate 50М burst 15k quantum 60000

Ошибки в логах пропали.

Вот только какой квантум лучше выставить - я пока не определился.

 

2. По сетевым:

ethtool -G ethX rx 1024 tx 1024

или посмотрите какие максимум можно выставить по

ethtool -g ethX

Дальше рекомендую поиграться с параметрами :

ethtool -k ethX

Вообще рекомендуют выключать offload

ethtool -K ethX gro off tso off rx off tx off (вообще поиграйтесь с этими параметрами у меня ВМ - поэтому все в офф)

 

3. Ядро :

Пришел к таким параметрам :

 

#!/bin/sh
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh1=1024
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh2=4096
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh3=8192
/sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_max=1548576
/sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=82800
/sbin/sysctl -w net.ipv4.inet_peer_threshold=262144
/sbin/sysctl -w net.ipv4.conf.eth0.proxy_arp=1
/sbin/sysctl -w net.core.netdev_max_backlog=10000
echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_checksum
echo "524288" > /sys/module/nf_conntrack/parameters/hashsize

Скрипт должен запускаться ПОСЛЕ инициализации коннтрак иначе некоторые параметры не могут быть применены.

[DarkSpider]

вчера отключил шейпинг исходящего трафика - жить стало значительно веселее (:

 

Надолго ? Мне было веселее только до вечера. Днем с отключенными шейпами на исход все вроде бы было путем - вечером полез softirq и скорость была близка к нулю. Все вернулось после перезапуска с обычными ограничениями. Впрочем пока не решил проблему с исходом (смотрите соседний топит про пережевывание 80м) просто поставил х1.5 на исход.

[madf]

...

 

3. Ядро :

Пришел к таким параметрам :

 

#!/bin/sh
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh1=1024
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh2=4096
/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh3=8192
/sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_max=1548576
/sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=82800
/sbin/sysctl -w net.ipv4.inet_peer_threshold=262144
/sbin/sysctl -w net.ipv4.conf.eth0.proxy_arp=1
/sbin/sysctl -w net.core.netdev_max_backlog=10000
echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_checksum
echo "524288" > /sys/module/nf_conntrack/parameters/hashsize

Скрипт должен запускаться ПОСЛЕ инициализации коннтрак иначе некоторые параметры не могут быть применены.

Все эти параметры (кроме тех что в /proc и /sys) нужно указать в /etc/sysctl.conf а не задавать скриптом.

[AoW]

вчера отключил шейпинг исходящего трафика - жить стало значительно веселее (:

 

Надолго ? Мне было веселее только до вечера. Днем с отключенными шейпами на исход все вроде бы было путем - вечером полез softirq и скорость была близка к нулю. Все вернулось после перезапуска с обычными ограничениями. Впрочем пока не решил проблему с исходом (смотрите соседний топит про пережевывание 80м) просто поставил х1.5 на исход.

 

у меня днем при двухстороннем шейпинге все ок, а вот вечером проблема. После отключения исходящего шейпинга вечером все стало норм

[KaYot]

Тюнинг sysctl для роутера неэффективен, большинство параметров для транзитного трафика просто не работает.

 

net.ipv4.neigh.default.gc_thresh1=1024
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=8192

Увеличивают размер таблицы маков, если в dmesg нет сообщений про neighbor table overflow - менять их смысла нет.

 

net.ipv4.netfilter.ip_conntrack_max=1548576

Размер трассировщика, опять же, если в dmesg нет ругани на кончившийся conntrack - крутить до миллионов нет смысла, только загрузка вырастет.

 

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=82800

Слишком много! Из-за этого и растет размер таблицы и впустую едятся ресурсы.. У меня стоит 1800 секунд, совершенно никаких аномалий. На нагруженных NAT-серверах народ ставит вплоть до 10 сек, работает..

Нет смысла хранить каждую tcp-сессию 23 часа или вообще неделю в дефолте)

 

Скриптом задавать эти параметры смысла не много, проще прописать все жестко в sysctl.conf

 

Мой рассчет значения quantum в скрипте:

if( $ceil > 2000000 ){

$quantum = 65535; // maximum

}else{

$quantum = $ceil / 100;

}

Отлично работает для скоростей от 512к до 100м.

[DarkSpider]

Все эти параметры (кроме тех что в /proc и /sys) нужно указать в /etc/sysctl.conf а не задавать скриптом.

Верно, это когда экспериментировал скриптом - осталось.

Увеличивают размер таблицы маков, если в dmesg нет сообщений про neighbor table overflow - менять их смысла нет.

Были - поэтому и увеличивал.

Размер трассировщика, опять же, если в dmesg нет ругани на кончившийся conntrack - крутить до миллионов нет смысла, только загрузка вырастет.

Опять же ругалось - поэтому и увеличил - насколько много - нужен совет спеца - увеличил просто по мануалам с инета.

Слишком много! Из-за этого и растет размер таблицы и впустую едятся ресурсы.. У меня стоит 1800 секунд, совершенно никаких аномалий. На нагруженных NAT-серверах народ ставит вплоть до 10 сек, работает..

Нет смысла хранить каждую tcp-сессию 23 часа или вообще неделю в де...

Про неделю - абсолютно согласен. Про оптимальное время - много споров было и на этом форуме. Ну пришли к такому - хотя согласен - я бы и меньше поставил. Сошлись на сутках.

[DarkSpider]

 

Мой рассчет значения quantum в скрипте:

if( $ceil > 2000000 ){

$quantum = 65535; // maximum

}else{

$quantum = $ceil / 100;

}

Отлично работает для скоростей от 512к до 100м.

А вот за это спасибо - со скриптом согласен - поставлю и у себя так. Я так понял - для больших скоростей - квантум побольше, для маленьких поменьше. Так ?

[KaYot]

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

[DarkSpider]

Ок. Спасибо за совет.

Еще вопрос - у кого есть канал выше 200 мб/с - почему может быть урезан аплоад ?

А - комп в локальной сети (Win7)
B - комп в локальной сети (Win XP)
VM1 - виртуальная машина - ОС Linux (eth2)
VM2 - виртуальная машина - ОС Linux (eth2)
VM3 - виртуальная машина - ОС Linux (eth1)
SW1 - гигабитный свитч Planet SGSW-24240
SW2 - гигабитный свитч Planet SGSW-28040

Итак схема :

A --->  SW1 ---> SW2 ---> B  (~300 Mbit/s)
B --->  SW2 ---> SW1 ---> A  (~300 Mbit/s)
VM1 ---> SW1 ---> A (~650 Mbit/s)
VM1 ---> SW1 ---> SW2---> B (~650 Mbit/s)
B ---> SW2 ---> SW1 ---> VM1 (~300 Mbit/s)
A ---> SW1 ---> VM1 (~300 Mbit/s)
VM1 ---> VM2 (~2.4 Gbit/s)
VM2 ---> VM1 (~2.4 Gbit/s)
VM1 ---> VM3 (~2.4 Gbit/s)
VM3 ---> VM1 (~300 Mbit/s)

Во всех случаях если идет загрузка(Download) - скорость на максимум, а если с него загружать(Upload) - то около 22 Мбайта/с (около 250-300 мбит/с)

[Небесный]

Ребята, попоробуйте шнягу, что вот советуют в этой статье.

http://habrahabr.ru/.../sysadm/110616/

 

А, теперь более подробно, на что я особо обратил внимание:

 

 

 

 

С хешами и без хешей

 

 

 

Как любое дерево, дерево фильтров становится слишком ресурсо-затратным при достижении определенного порога.

 

Когда пакет от какого-то IP-адреса попадает на дерево фильтров, он начинает сравниваться с критериями каждого фильтра. При совпадении, пакет отправляется в соответствующий класс. Т.е. для каждого пришедшего пакета производится последовательно проверка на предмет соответствия критерию каждого фильтра в дереве до тех пор, пока не произойдет совпадение.

 

Например, для сети по 24-й маске у нас будет в среднем 128 шагов для каждого пакета при поиске нужного для него класса.

 

Это несущественно при небольших объемах трафика и при небольшом кол-ве абонентов. Когда же абонентов десятки тысяч, а в интернет уходят гигабиты, такой подход становится просто невозможным – сервер шейпинга банально не будет справляться с нагрузкой.

 

Если все дерево – это последовательность проверок на IP-адрес, то гораздо эффективнее будет задействовать хеши. Хеш — это таблица соответствий неких “значений” неким “ключам”. В нашем случае ключеом выступает IP-адрес, а значением – фильтр, направляющий пакет в свой класс.

 

Таким образом, по ключу (IP-адресу) мы быстро находим нужный фильтр для пакета, – в 1 шаг.

 

Собственно, про использование хешей статей уже написано немало – это не является “чем-то военным”. Можно обратиться к первоисточнику.

 

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

Сам такой проблемой не страдаю, может просто потому что хомячков маловато и траф мизерный. При 350 хомяках и 35 мегабит внешнего канала, нат, биллинг, шейпер, роуты, веб-сервер и еще всякой шняги висит на одной тачке - нагрузка 6-7-8%.

Вот график тому доказательство.

 

[DarkSpider]

Отключил захват трафика в СТГ cap_ether - трафико-зависимых тарифов - нет.

Снял ifb и перевел на 2 интерфейса и метки на форвард.

Как результат :

Дневная загрузка :

Трафика до 400М

Юзеров 1,5к в ЧНН - 700-750 онлайн.

[Небесный]

DarkSpider, параметры сервера можешь описать? Ради интереса, сравнить нагрузку по железу.

[DarkSpider]

Да. Без проблем.

Сервер работает на виртуалке Xen Sever.

 

4 (ядра) х Intel(R) Xeon(R) CPU E5520  @ 2.27GHz
4Gb RAM

uname -a
Linux stg 2.6.32-36-generic #79-Ubuntu SMP Tue Nov 8 22:29:53 UTC 2011 x86_64 GNU/Linux

Хост машина - вот такая : http://www.fujitsu.c...rgy/rack/rx300/

Аптайм сервака - 6 дней (обновляли ядро)

Аптайм хоста :

[root@xenserver-main ~]# uptime
20:12:00 up 362 days, 4:09, 2 users, load average: 0.64, 0.70, 0.71

[Небесный]

А, показать первые 10 строк из топа (открываеш топ, потом нажимаешь "1" дабы открыть информацию по отдельным ядрам).

Ну, типа такого должно выйти.

 

top - 20:23:43 up 3 days,  3:17,  1 user,  load average: 0.16, 0.06, 0.02
Tasks:  94 total,   1 running,  93 sleeping,   0 stopped,   0 zombie
Cpu0  :  1.3%us,  2.3%sy,  0.0%ni, 88.1%id,  0.0%wa,  2.3%hi,  6.0%si,  0.0%st
Cpu1  :  1.0%us,  1.3%sy,  0.0%ni, 89.4%id,  0.0%wa,  0.0%hi,  8.3%si,  0.0%st
Mem:   4057208k total,   954756k used,  3102452k free,   174748k buffers
Swap: 11888060k total,        0k used, 11888060k free,   365552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1397 root      20   0 61128  10m 2836 S    5  0.3 122:47.26 fprobe
1065 bind      20   0  169m  51m 2260 S    1  1.3   9:44.49 named
1440 root       1 -19  308m  28m 3464 S    1  0.7  55:39.16 stargazer
   1 root      20   0 19324 1636 1188 S    0  0.0   0:00.60 init
   2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
   3 root      RT  -5     0    0    0 S    0  0.0   0:00.03 migration/0
   4 root      15  -5     0    0    0 S    0  0.0   0:00.36 ksoftirqd/0
   5 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/0
   6 root      RT  -5     0    0    0 S    0  0.0   0:00.03 migration/1
   7 root      15  -5     0    0    0 S    0  0.0   0:18.51 ksoftirqd/1
   8 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/1
   9 root      15  -5     0    0    0 S    0  0.0   0:00.48 events/0
  10 root      15  -5     0    0    0 S    0  0.0   0:00.29 events/1
  11 root      15  -5     0    0    0 S    0  0.0   0:00.00 cpuset
  12 root      15  -5     0    0    0 S    0  0.0   0:00.00 khelper
  13 root      15  -5     0    0    0 S    0  0.0   0:00.00 netns

[DarkSpider]

ага :

 

top - 20:33:48 up 6 days,  2:11,  2 users,  load average: 0.30, 0.29, 0.32
Tasks: 114 total,   1 running, 113 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.4%us,  0.3%sy,  0.0%ni, 95.8%id,  0.0%wa,  0.0%hi,  3.2%si,  0.3%st
Cpu1  :  0.4%us,  0.4%sy,  0.0%ni, 81.3%id,  0.4%wa,  0.1%hi, 15.8%si,  1.7%st
Cpu2  :  0.3%us,  0.3%sy,  0.0%ni, 75.0%id,  0.1%wa,  0.2%hi, 22.1%si,  2.0%st
Cpu3  :  0.4%us,  0.3%sy,  0.0%ni, 98.9%id,  0.2%wa,  0.0%hi,  0.0%si,  0.1%st
Mem:   4951524k total,  2435720k used,  2515804k free,   230700k buffers
Swap:   897016k total,		0k used,   897016k free,  1424236k cached
 PID USER	  PR  NI  VIRT  RES  SHR S %CPU %MEM	TIME+  COMMAND
3498 root	   1 -19  219m  29m 2936 S	5  0.6  45:17.09 stargazer
 806 bind	  20   0  366m 178m 2328 S	5  3.7 253:50.85 named
8680 spider	20   0 19224 1408 1064 R	4  0.0   0:00.12 top
  10 root	  20   0	 0	0	0 S	1  0.0  79:49.25 ksoftirqd/2
 376 syslog	20   0  187m 1968 1072 S	1  0.0   2:24.63 rsyslogd
1 root	  20   0 23700 1888 1272 S	0  0.0   0:00.87 init
2 root	  20   0	 0	0	0 S	0  0.0   0:00.01 kthreadd
3 root	  RT   0	 0	0	0 S	0  0.0   0:03.42 migration/0
4 root	  20   0	 0	0	0 S	0  0.0 208:08.35 ksoftirqd/0
5 root	  RT   0	 0	0	0 S	0  0.0   0:00.01 watchdog/0
6 root	  RT   0	 0	0	0 S	0  0.0   0:07.30 migration/1
7 root	  20   0	 0	0	0 S	0  0.0   8:55.77 ksoftirqd/1
8 root	  RT   0	 0	0	0 S	0  0.0   0:00.00 watchdog/1
9 root	  RT   0	 0	0	0 S	0  0.0   0:14.63 migration/2
  11 root	  RT   0	 0	0	0 S	0  0.0   0:00.00 watchdog/2
  12 root	  RT   0	 0	0	0 S	0  0.0   0:03.59 migration/3
  13 root	  20   0	 0	0	0 S	0  0.0   3:17.79 ksoftirqd/3
  14 root	  RT   0	 0	0	0 S	0  0.0   0:00.00 watchdog/3
  15 root	  20   0	 0	0	0 S	0  0.0   0:31.55 events/0
  16 root	  20   0	 0	0	0 S	0  0.0   0:16.48 events/1
  17 root	  20   0	 0	0	0 S	0  0.0   1:01.11 events/2
  18 root	  20   0	 0	0	0 S	0  0.0   2:45.84 events/3
  19 root	  20   0	 0	0	0 S	0  0.0   0:00.00 cpuset
  20 root	  20   0	 0	0	0 S	0  0.0   0:00.00 khelper
  21 root	  20   0	 0	0	0 S	0  0.0   0:00.00 async/mgr
  22 root	  20   0	 0	0	0 S	0  0.0   0:00.00 pm
  24 root	  20   0	 0	0	0 S	0  0.0   0:00.22 xenwatch
  25 root	  20   0	 0	0	0 S	0  0.0   0:00.48 xenbus