[kamd]

Столкнулся с такой проблемой:

Приобрёл тут гигабитные pci-e4х сетевухи (до этого были/есть pci сетевухи, но предполагаю, что скоро упрусь там в потолок pci-шины), под это дело решил организовать 4х ядерные серваки, до этого шейпера работали на athlon 64 x2 5200+ (стоит фря 6.2-stable/amd64, до 6.3-stable как-то не нашёл время обновиться).

Туда решил поставить 7.0, прокачал её до stable, всё настроил, протестил, пустил в работу и при реальной нагрузке.... получил грабли.

Грешу на новый шедулер SCHED-ULE, который в 7.0-STABLE используется.

На 6.X используется SCHED-4BSD

 

Так вот на новых серверах при той же загрузке, что и на старых, начал расти пинг, вплоть до сотен мс, обычно он -1 или 1, и не больше 2-5 мс. И вообще трасировка через новые серваки какая-то неадекватная, не видно былой стабильности.

 

Вот собственно вопрос, кто в этом виноват? SCHED-ULE?

Если собрать 7.0-STABLE/amd64 c SCHED-4BSD, то быстродействие вернётся хотя бы на уровень 6.3? Или всё равно будет меньше? Или станет больше? И не вылезет ли ещё каких-либо интересных граблей при сочетании 7.0 и SCHED-4BSD?

Или стоит поставить на 4х процы 6.3-stable/amd64 и не париться?

 

Кто-нибудь сталкивался? Как решили проблему?

Изменено 28 июля, 2008 пользователем kamd

[jab]

 

"Уважаемые товарищи ученые, у мине в подполе вот уже который год происходит подземный стук, расскажите пожалуйста, отчего и почему он происходит." (С) АБС

[kapa]

пока не сталкивался - сейчас тоже использую то, чот и Вы, и тоже тестирую на новом серваке с новыми сетевухами 7.0

 

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

 

[kamd]

Если бы некоторые граждане с татуина были бы более разумными, чем, например, неразумные kamdяне, то конкретно бы написали чего нужно более подробно расписать. На данный же момент, впрочем как и всегда, татуяне занимаются банальным флеймом.

 

 

ядро у меня такое:

include GENERIC

 

options IPFIREWALL

options IPFIREWALL_FORWARD

options IPFIREWALL_VERBOSE

options DUMMYNET

options IPFILTER

options IPDIVERT

options DEVICE_POLLING

options HZ=1000

 

options SMP

 

options NETGRAPH

options NETGRAPH_ETHER

options NETGRAPH_SOCKET

options NETGRAPH_TEE

Изменено 28 июля, 2008 пользователем kamd

[kamd]

Вот трасировки через новый сервак на 7.0-stable c SCHED-ULE, 4x проц, сетевуха интел 9402

172.18.18.23 это как раз этот новый сервак.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 1 ms 1 ms <1 мс 10.10.116.1

2 <1 мс 1 ms <1 мс 172.17.17.76

3 1 ms 1 ms 2 ms 172.18.18.23

4 15 ms 10 ms 7 ms 77.246.x.y

5 12 ms 7 ms 6 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 5 ms 4 ms 3 ms ix1-m10.yandex.net [193.232.246.93]

7 27 ms 28 ms 22 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 <1 мс <1 мс 1 ms 10.10.116.1

2 <1 мс <1 мс <1 мс 172.17.17.76

3 2 ms 1 ms 1 ms 172.18.18.23

4 30 ms 17 ms 4 ms 77.246.x.y

5 19 ms 35 ms 36 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 23 ms 18 ms 48 ms ix1-m10.yandex.net [193.232.246.93]

7 55 ms 29 ms 27 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 1 ms <1 мс <1 мс 10.10.116.1

2 <1 мс <1 мс <1 мс 172.17.17.76

3 7 ms 2 ms 2 ms 172.18.18.23

4 28 ms 24 ms 19 ms 77.246.x.y

5 29 ms 34 ms 28 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 19 ms 19 ms 19 ms ix1-m10.yandex.net [193.232.246.93]

7 15 ms 36 ms 28 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 3 ms 1 ms <1 мс 10.10.116.1

2 <1 мс <1 мс 1 ms 172.17.17.76

3 20 ms 3 ms 4 ms 172.18.18.23

4 44 ms 25 ms 6 ms 77.246.x.y

5 11 ms 9 ms 17 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 6 ms 10 ms 5 ms ix1-m10.yandex.net [193.232.246.93]

7 8 ms 7 ms 7 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 1 ms <1 мс 2 ms 10.10.116.1

2 <1 мс <1 мс <1 мс 172.17.17.76

3 3 ms 2 ms 2 ms 172.18.18.23

4 37 ms 16 ms 12 ms 77.246.x.y

5 4 ms 2 ms 2 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 11 ms 3 ms 2 ms ix1-m10.yandex.net [193.232.246.93]

7 60 ms 14 ms 5 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

=====================

 

А вот трасировка через старый сервак на 6.2-stable, SCHED_4BSD и обычную intel гигабитную pci-сетевуху.

18.6 это как раз этот сервер.

 

Комментарии как говорится излишни

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 <1 мс 1 ms 4 ms 10.10.116.1

2 <1 мс <1 мс <1 мс 172.17.17.76

3 <1 мс <1 мс <1 мс 172.18.18.6

4 1 ms 1 ms 1 ms 77.246.x.y

5 1 ms 1 ms 1 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 1 ms 1 ms 1 ms ix1-m10.yandex.net [193.232.246.93]

7 1 ms 1 ms 1 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 1 ms <1 мс <1 мс 10.10.116.1

2 <1 мс <1 мс <1 мс 172.17.17.76

3 <1 мс <1 мс 1 ms 172.18.18.6

4 1 ms 1 ms 1 ms 77.246.x.y

5 1 ms 2 ms 1 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 4 ms 2 ms 1 ms ix1-m10.yandex.net [193.232.246.93]

7 2 ms 3 ms 2 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

 

C:\>tracert ya.ru

 

Трассировка маршрута к ya.ru [213.180.204.8]

с максимальным числом прыжков 30:

 

1 <1 мс <1 мс <1 мс 10.10.116.1

2 <1 мс <1 мс <1 мс 172.17.17.76

3 <1 мс <1 мс <1 мс 172.18.18.6

4 1 ms 1 ms 1 ms 77.246.x.y

5 1 ms 1 ms 1 ms yaol-uni-lgw.cen.medi-a.ru [77.246.97.9]

6 1 ms 2 ms 1 ms ix1-m10.yandex.net [193.232.246.93]

7 2 ms 1 ms 1 ms ya.ru [213.180.204.8]

 

Трассировка завершена.

Изменено 28 июля, 2008 пользователем kamd

[kamd]

уууууууу. японский бог, да там ещё и потери

на 18.23

ph23# netstat -w1d

input (Total) output

packets errs bytes packets errs bytes colls

11688 93 6594409 11691 0 6703130 0

12395 77 6884965 12294 0 6837494 0

13281 0 7606106 13204 0 7564631 0

12978 125 7470436 12853 0 7414926 0

12985 0 7423232 12853 0 7326047 0

11488 248 6313780 11472 0 6373532 0

12283 8 6921220 12094 0 6784097 0

13248 0 7933206 13109 0 7849810 0

12659 0 7546944 12584 0 7504513 0

10963 513 6013676 10928 0 6059609 0

11808 24 6573821 11728 0 6531786 0

12586 237 6730994 12419 0 6628138 0

12005 222 6499401 11928 0 6503764 0

13188 0 7814003 12985 0 7595651 0

13448 0 8149092 13267 0 7958515 0

13478 0 8126227 13454 0 8192621 0

13032 0 7822935 12932 0 7762155 0

12959 109 7542381 12896 0 7539812 0

11990 9 6867580 11933 0 6875807 0

11842 198 6671391 11687 0 6546975 0

 

на 18.23 всё отлично

input (Total) output

packets errs bytes packets errs bytes colls

16948 0 11584064 16614 0 11396092 0

16402 0 11443956 16166 0 11305375 0

16945 0 11749437 16684 0 11662726 0

17193 0 12326822 16878 0 12060733 0

16542 0 11763075 16367 0 11661302 0

16233 0 11391876 15957 0 11301515 0

16908 0 11525040 16661 0 11343808 0

16618 0 11591970 16428 0 11486749 0

16790 0 12022513 16495 0 11823020 0

16204 0 11752932 15972 0 11626471 0

17006 0 12440988 16716 0 12214340 0

15967 0 11101435 15687 0 11020102 0

16161 0 11644735 15933 0 11503895 0

16086 0 11018437 15718 0 10799456 0

16002 0 11526077 15813 0 11465016 0

17182 0 12091865 16837 0 11739725 0

17573 0 12281784 17339 0 12141434 0

16925 0 11847338 16675 0 11749539 0

17686 0 12296968 17458 0 12183482 0

17705 0 12899477 17329 0 12625959 0

18074 0 12259570 17851 0 12127838 0

 

[kapa]

ядро у меня такое:

include GENERIC

 

options IPFIREWALL

options IPFIREWALL_FORWARD

options IPFIREWALL_VERBOSE

options DUMMYNET

options IPFILTER

options IPDIVERT

options DEVICE_POLLING

options HZ=1000

 

options SMP

 

options NETGRAPH

options NETGRAPH_ETHER

options NETGRAPH_SOCKET

options NETGRAPH_TEE

Есть мнение, что SMP на нагруженных роутерах - зло.

Плюс HZ, думаю, можно до 2000 поднять, это если без фанатизма.

 

Драйвер на сетевую попробовать яндексовский.

Параметры sysctl на старом и новом серверах сравните. Если что нестандартное вносили - покажите?

Плюс нагрузку в PPS и KBPS примерную, если можно.

 

upd: Ах, да - только не пинайте, но поллинг я бы из ядра тоже выкинул.

Изменено 28 июля, 2008 пользователем kapa

[jab]

Есть мнение, что SMP на нагруженных роутерах - зло.

Бред.

[kapa]

Есть мнение, что SMP на нагруженных роутерах - зло.

Бред.

Возможно, у меня на рабочем SMP, и тестов сравнительных пока не проводил, но тут: https://calomel.org/network_performance.html

и где-то ещё читал.

[kamd]

По моему опыту поллинг - это зло на серверах, где у меня используется ipnat, где его нет - поллинг великая весчь. Архитектуру этого процесса/зависимости не знаю.

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

 

Из изменённых на обоих серверах sysctl параметров:

kern.ipc.maxsockbuf=262144

net.inet.tcp.sendspace=65536

net.inet.tcp.recvspace=65536

net.inet.tcp.rfc1323=1

kern.ipc.nmbclusters=32768

Всё остальное если менялось между 6.2 и 7.0, то я даже не знаю что.

 

 

kern.polling.enable стало быть 0, коли он отключен.

 

Что за яндексовский драйвер? Что-то я сильно стремаюсь подобных экспериментов, ибо обновляюсь по cvsup и там всё замечательно приходит обновлённое, по мере готовности оного.

 

Нагрузка в сообщении номер 6.

[DVM-Avgoor]

Есть мнение, что kern.polling.enable вообще deprecated. Так же есть мнение, что EXPI9402, как в прочем и EXPI9300, умеют MSI. Что круто.

Вы бы для интереса таки с 4BSD шедуллером пересобрались, дабы наглядно подтвердить зло ULE.

 

На 6.3 + EXPI9300 6 + Core2 1.8 ГГц, Ваш диагноз не подтвержден, ни с 4BSD ни с ULE. Более того, машина не затыкалась при нагрузке ~700Мбит/с а точнее ~70 kpps, что для нее удовлетворительно.

[kamd]

Я как раз в процессе сборки 7.0 с 4BSD.

Есть мнение, что в Вашем случае ключевое слово это 6.3

Насколько я знаю, в 7.0 они там чего-то сильно поменяли в плане оптимизации многозадачности на многоядерниках. Какие-то там семафоры задержек или как-то так, я просто в системном программировании вообще никак.

Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду. Выдаётся на других (не обсуждаемых здесь, построенных на вообще одноядерных процах и 6.x-stable) серваках, где нет ipnat'а и там тупо форвардинг идёт. На них, кстати, поллинг меняет картину загрузки системы между interrupt и system/user. Кстати, возможно это (поллинг) будет уже не актуален на 7.0, потому что насколько я помню, что читал в рассылке, что они усиленно работают над оптимизацией дров для работы "быстро и красиво" без поллинга.

Изменено 29 июля, 2008 пользователем kamd

[jab]

Возможно, у меня на рабочем SMP, и тестов сравнительных пока не проводил, но тут: https://calomel.org/network_performance.html

и где-то ещё читал.

Во-первых, статья устарела года на три. Во-вторых, про FreeBSD там всего один абзац, не имеющий никакого отношения к реальности.

[kapa]

По моему опыту поллинг - это зло на серверах, где у меня используется ipnat, где его нет - поллинг великая весчь.

У меня ipnat вообще не используется, но поллинг убрал из ядра.

Плюс он, кажется, мешался при сборке с драйверами от яндекса.

Что за яндексовский драйвер? Что-то я сильно стремаюсь подобных экспериментов, ибо обновляюсь по cvsup и там всё замечательно приходит обновлённое, по мере готовности оного.

http://people.yandex-team.ru/~wawa/

Не надо стрематься - попробуйте ;)

 

Из изменённых на обоих серверах sysctl параметров:

kern.ipc.maxsockbuf=262144

net.inet.tcp.sendspace=65536

net.inet.tcp.recvspace=65536

net.inet.tcp.rfc1323=1

kern.ipc.nmbclusters=32768

Всё остальное если менялось между 6.2 и 7.0, то я даже не знаю что.

у меня на 6.2:

net.inet.tcp.recvspace=1048576 
net.inet.tcp.sendspace=1048576 
kern.ipc.maxsockbuf=4194304 
kern.ipc.nmbclusters=65536 
net.inet.ip.portrange.first=5700
kern.ipc.somaxconn=65535
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.icmplim=30
net.inet.ip.intr_queue_maxlen=4096
net.inet.tcp.delayed_ack=0
net.inet.tcp.delacktime=10
net.inet.tcp.newreno=0
net.inet.tcp.msl=2500
net.inet.ip.rtmaxcache=1024
net.inet.raw.recvspace=65536
net.inet.ip.dummynet.hash_size=8192
net.inet.ip.fw.dyn_ack_lifetime=60
net.inet.ip.fw.dyn_syn_lifetime=10
net.inet.ip.fw.dyn_fin_lifetime=10
net.inet.ip.fw.dyn_max=16192 
net.inet.ip.fastforwarding=1
net.isr.direct=1

Что-то, наверняка, чрезмерно задрано, но оперативки более чем достаточно, поэтому не мешает.

 

Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду.

14.8 на все pci сетевухи? т.е. на 2-ух по 7.4?

Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН.

Изменено 29 июля, 2008 пользователем kapa

[kapa]

Возможно, у меня на рабочем SMP, и тестов сравнительных пока не проводил, но тут: https://calomel.org/network_performance.html

и где-то ещё читал.

Во-первых, статья устарела года на три. Во-вторых, про FreeBSD там всего один абзац, не имеющий никакого отношения к реальности.

Я на абзац с FreeBSD и не показывал.

 

Давайте полезем в теорию - просто интересно, как оно на самом деле. Мне кажется, что всё логично. Если при SMP в единицу времени только 1 процессор может работать с памятью, то особого прироста в производительности мы не получим. Возможно, система будет стараться равномерно распределить нагрузку по процессорам, но оно нам на роутере надо? А без SMP нас это не заботит, зато свободный процессор может обработать прерывание, когда занят другой. Так?

Изменено 29 июля, 2008 пользователем kapa

[kamd]

Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду.

14.8 на все pci сетевухи? т.е. на 2 уе по 7.4?

Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН.

2 уе?! при чём тут уе?!

14.8 мегабайт/с на одной сетевухе в одну сторону.

[nuclearcat]

Не так, "схожие" данные должны обрабатываться на соответствующем им процессоре, иначе получим проблему "непопадания" в кеш процессора. Если данные будут прыгать по процессорам - производительность упадет в разы. Если у вас еще и AMD x86_64 NUMA - вообще жопа будет (там память прикреплена к каждому процессору).

 

В Линуксе это учтено, во Фре - не знаю.

[kamd]

Давайте полезем в теорию - просто интересно, как оно на самом деле. Мне кажется, что всё логично. Если при SMP в единицу времени только 1 процессор может работать с памятью, то особого прироста в производительности мы не получим. Возможно, система будет стараться равномерно распределить нагрузку по процессорам, но оно нам на роутере надо? А без SMP нас это не заботит, зато свободный процессор может обработать прерывание, когда занят другой. Так?

Однако есть мнение, что на современных многоядерных процах таки немного толще и быстрее шина обмена данными с памятью, тот же hyperTransport, через него же проц и с памятью тоже общается или я не прав?! А вообще было бы чуднО, если бы 4хядерник phenom 9750 мог работать с памятью в единицу времени в таком же объёме как скажем одноядерник athlon 64 3200+ или двух ядерник x2 64 5200+. Очень чуднО, но к счастью это не так.

Изменено 29 июля, 2008 пользователем kamd

[kapa]

Такие скорости на 9402 мне пока не удавалось наблюдать, но по некоторым сведениям потолок гигабитных сетевух в pci разъём это 14.8 мегабайт в секунду.

14.8 на все pci сетевухи? т.е. на 2 уе по 7.4?

Не слушайте их - у меня такая нагрузка, которую Вы показали, ночью. И сетевухи pci. И ни одного пакета не теряется, даже в ЧНН.

2 уе?! при чём тут уе?!

14.8 мегабайт/с на одной сетевухе в одну сторону.

Опечатался. Читать "на 2-ух".

Ок. Если 14.8 на одной в одну сторону, то сколько на 2ух в две стороны?

Короче, глупости это всё - пакеты при этом какого размера, для начала?

 

Не так, "схожие" данные должны обрабатываться на соответствующем им процессоре, иначе получим проблему "непопадания" в кеш процессора. Если данные будут прыгать по процессорам - производительность упадет в разы. Если у вас еще и AMD x86_64 NUMA - вообще жопа будет (там память прикреплена к каждому процессору).

 

В Линуксе это учтено, во Фре - не знаю.

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

[jab]

Давайте полезем в теорию - просто интересно, как оно на самом деле.

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

[kamd]

Опечатался. Читать "на 2-ух".

Ок. Если 14.8 на одной в одну сторону, то сколько на 2ух в две стороны?

Короче, глупости это всё - пакеты при этом какого размера, для начала?

В другую сторону на графиках вижу 3.7 мегабайта в секунду.

На 2х стало быть надо умножить на 2.

Размер пакета - это вопрос на красный диплом. Предполагаю, что их дохера разных.

 

Кстати, типа "прикол" про поллинг. Один из обсуждаемых мной серверов на 7.0 (железо: мать gigabyte GA-MA78GM-S2H, проц phenom 9750). Поллинг включен в sysctl.ctl. Выключаем поллинг через sysctl, то бишь в онлайне. Машина пропадает из онлайна и больше не загружается. Мать сдохла и на экран ничего не выдаёт, в спикер не пищит, линки на вставленной в pcie4x сетевухе не горят. Сетевуха жива уже проверил. Проц врядли умер. Остаётся мать по идее. Этот аспект ещё не проверял.

[jab]

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

Да ну ? Это сколько же Mpps Вы там гоняете, что Вас начали на 7.0 прерывания заботить ? Я предполагаю, sysctl dev.em у Вас правильно выставлены ? ;-)

[kapa]

Давайте полезем в теорию - просто интересно, как оно на самом деле.

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

Тогда не вылазьте, пожалуйста, из своего рабочего роутера в форум, где люди пытаются разобраться и прийти к истине, со своим флеймом?

Изменено 29 июля, 2008 пользователем kapa

[jab]

Тогда не вылазьте, пожалуйста, из своего рабочего роутера в форум, где люди пытаются разобраться и прийти к истине со своим флеймом?

Ухожу, ухожу, ухожу. Нечего было связываться с детским садом. :-)

[kamd]

jab, почему всё-таки Ваш ник так похож на Ваше поведение или наоборот, я ещё не разобрался толком?!?! Разве нельзя взять и открыться душой к человечеству, научать несмышлёнышей как надо, а то Вы таким поведением только карму себе портите!?! Мне конечно всё равно, это Ваша карма, но всё же.....

Изменено 29 июля, 2008 пользователем kamd