[Max P]

поставил rx-usecs 125, один фиг:

 

PerfTop: 303142 irqs/sec kernel:99.3% exact: 0.0% [1000Hz cpu-clock-msecs], (all, 8 CPUs)

[Max P]

воткнул 1000, vmstat стал показывать

 

nat0 perf # vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
1  0      0 822216 337732 1957464    0    0     0     0    0    0  0 11 89  0
0  0      0 821968 337732 1957464    0    0     0     0 51497 1575  0  7 93  0
0  0      0 822092 337732 1957464    0    0     0    32 50128 1411  0  7 93  0
0  0      0 822092 337732 1957464    0    0     0     0 48953 1371  0  7 93  0
0  0      0 822216 337732 1957464    0    0     0    44 50463 1507  0  8 92  0
0  0      0 822224 337732 1957464    0    0     0     0 49571 1366  0 11 90  0

но при этом если смотреть top - то нагрузка стала сильно неравномерной и скачет от 4 до 40% по разным ядрам

[Dark_Angel]

Возьмите драйвер посвежее. Интел там не только новые фичи вкручивает, но и оптимизирует. Он уже как минимум 3.2.х

 

Не уверен, что rx-usecs - это именно режим работы драйвера. Вот мой:

 

ethtool -c eth0

Coalesce parameters for eth0:

Adaptive RX: off TX: off

stats-block-usecs: 0

sample-interval: 0

pkt-rate-low: 0

pkt-rate-high: 0

 

rx-usecs: 3

rx-frames: 0

rx-usecs-irq: 0

rx-frames-irq: 0

 

tx-usecs: 0

tx-frames: 0

tx-usecs-irq: 0

tx-frames-irq: 0

 

rx-usecs-low: 0

rx-frame-low: 0

tx-usecs-low: 0

tx-frame-low: 0

 

rx-usecs-high: 0

rx-frame-high: 0

tx-usecs-high: 0

tx-frame-high: 0

 

При этом:

vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

0 0 8120 205972 213116 160728 0 0 0 0 0 0 2 19 78 0

0 0 8120 205972 213116 160752 0 0 0 88 11929 7418 0 12 88 0

0 0 8120 205848 213116 160760 0 0 0 540 12041 8714 1 11 88 1

0 0 8120 205972 213116 160756 0 0 0 0 11935 6061 0 10 90 0

0 0 8120 205972 213116 160756 0 0 0 64 11955 7685 0 10 90 0

1 0 8120 205848 213116 160756 0 0 0 512 11878 4866 18 12 70 0

 

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

 

Ну и еще. Плавающая нагрузка вас не должна волновать. Когда ядра пригрузят - она плавать не будет. При общей нагрузке системы ~10% она может плавать - не обращал внимание. Тем не менее нагрузка у вас снизилась вдвое, если количество пакетов не изменилось, но 50К прерываний - это всеравно много.

Изменено 1 ноября, 2011 пользователем Dark_Angel

[Max P]

да везде, даже в интеловской доке именно rx-usecs за это и отвечает, поставил пока у себя rx-usecs 325 - проц поменьше кушает и задержек много не добавляет

 

ЗЫ. а интеловский igb у меня не завелся - тупо система падала в кернел паник в момент подъема интерфейсов

[Dark_Angel]

Раз уже дергаете интерфейс, то поставьте по-нормальному через параметры драйвера. Может этот rx-usecs и то что надо, но у меня нет объяснения почему он у меня в таком случае равен 3, хотя настройки совсем другие. Поэтому чтобы наверняка - ставьте параметрами при загрузке драйвера.

 

Насчет драйверов, то рекомендую проапдейтить ядро, если у вас до сих пор r4. Ну или поставьте уже последний драйвер из ветки 2.х.

 

Кстати гугл говорит, что rx-usecs - это все же настройки сетевого кольца, а не политики модерации прерываний. То есть на количество прерываний эти настройки влияют, конечно, но мы же говорим о других параметрах? Поэтому лучше верните его как было, т.е. 3.

Изменено 1 ноября, 2011 пользователем Dark_Angel

[Max P]

там есть описка да, если ставить через параметры модуля - то они имеют приоритет над rx-usecs

 

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

 

The sequence below sets the InterruptThrottleRate (which is rx-usecs to Ethtool) to 1 (dynamic)

 

как то так

[NiTr0]

Скажем так, я считаю, что абон без торрентов больше 20-30 соединений держать не может. С торрентами, ну пусть будет 100-200.

600-700 соединений для активного торрентовода - норма. О UDP "сессиях" (DHT, снюхивание с uTP пирами и т.п.) - вообще помолчу, они "устанавливаются" по каждому UDP чиху, и "завершаются" лишь по тайм-ауту (ибо какой может быть анализ неведомого протокола?).

 

А вообще - uTP фильтры не болжны сильно грузить систему, у меня до 5% загрузка ts_kmp была, ts_bm к слову меньшую нагрузку дает. А без него - будут плодиться сессии коннтрака как кролики...

 

P.S. hashsize коннтраку выставлен эдак на 100-200к, или дефолтный?

[Dark_Angel]

2NiTr0: Может и так, но активных слава Богу не много. Могу судить по просмотреному flow - 10-20К сессий для активного за час видел. Это топовые.

 

По hashsize пишут, что CONNTRACK / 8 формула. У меня раньше тоже был 512К на 128К соединений. Сделал 16К. К сожалению, тогда машина загружена не была, поэтому оценить еффект не смог. Сейчас работает по той же формуле.

[Max P]

Ну вот ts_kmp убрал - системе сильно полегчало на трафике 700-800мбит, да и покрутив таймауты коннтрака - у меня их число упало в два раза, даже с убитым ts_kmp. А hashsize это где смотреть? чот в sysctl -a не вижу такого

[Dark_Angel]

/sys/module/nf_conntrack/parameters/hashsize

 

Он же net.ipv4.netfilter.ip_conntrack_buckets = 16384

Изменено 1 ноября, 2011 пользователем Dark_Angel

[Justas]

Идея с бондингом прокатила :) Объединил интерфейсы в бонд, бонд развел на виланы, экспериментально подобраны параметры

 

options bond0 miimon=100 mode=4 xmit_hash_policy=layer3+4

 

В этом случае приходящий на NIC пакет в моем случае всегда будет отправлен через этот же NIC.

 

Нагрузка на процессоры снизилась в 2-2,3 раза. Живем.

а со стороны коммутатора как bond настроен?

 

 

Циска. Вот так:

 

port-channel load-balance src-dst-ip
!
interface Port-channel2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,100
switchport mode trunk
!
interface GigabitEthernet0/23
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,100
switchport mode trunk
channel-group 2 mode active
!
interface GigabitEthernet0/24
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,100
switchport mode trunk
channel-group 2 mode active

Изменено 1 ноября, 2011 пользователем Justas

[Max P]

а, buckets, 16384 пока стоит, пытался сделатб по формуле 32768 - не дает, говорит permission denied :(

[Max P]

ах да, там же через /sys ставить надо, поставил 32768 ща

[Max P]

Rate: 477808148 bits/sec, 70948 packets/sec; Avg 1 min: 476859003 bps, 69629 pps; 5 min: 479542135 bps, 70175 pps

 

нагрузка по ядрам 10-15%

[Dark_Angel]

Я думаю, что если уберете прерывания, то будет еще в 2 раза меньше.

[Max P]

кстати, эти прерывания только от пересылки пакетов зависят или от шейпера/ната тоже?

[Dark_Angel]

Только прием/отправка. Ну туда еще другие устройства, кроме сетевой входят, очевидно. Скажем каждое ядро имеет локальный таймер ( LOC ) который делает 1К прерываний на каждом ядре.

 

Есть полезный top для прерываний, называется itop. Но по факту, выставляете на карте жестко прерывания, проверяете, что настройки применились и потом только смотрите, чтобы буфера у карты не переполнялись. Потому как малое количество прерываний может приводить к такому эффекту при большом трафике.

 

Еще из тюнинга, можете поиграться с буфером кольца. Рекомендуется уменьшать его пока не начнутся ошибки на интерфейсе, затем сделать x2 и оставить. Когда кольцо вырастите до максимума, начинаете увеличивать количество прерываний. Ну это если забегать вперед. На трафике порядка гигабита на порт, я думаю вы разок настроите и забудете, как это в свое время сделал я.

[Max P]

кольцо стоит 3092 еще давно ставил, впринципе и 2048 хватало, вот до 800мбит тоже не вспоминал)

 

хм, а где взять itop? чет он фигово гуглится

[Dark_Angel]

У меня на гигабитном интерфейсе стоит 512 байт, только что проверил. Правда модерация прерываний осталась на автомате.

[Max P]

на дефолтовых 256 были дропы, потому сразу крутанул 2048 и не парился)

[Dark_Angel]

Посмотрите тут http://et.redhat.com/~jmh/tools/xen/itop

[Max P]

сенкс, только у меня почему то всего 3 проца показывает

[Dark_Angel]

Ну, я думаю, что понадобится обработка напильником.

Изменено 1 ноября, 2011 пользователем Dark_Angel

[NiTr0]

По hashsize пишут, что CONNTRACK / 8 формула.

Писать много что можно. От слишком большого хеша никто не умер (или у вас на бордюре очень мало памяти?), а чем больше хеш - тем быстрее идет по нему поиск сессий. А формула - это скорее всего имелось ввиду как вычисляется размер хеша самим модулем.

Основной критерий - размер хеша равный степени 2.

 

Ну вот ts_kmp убрал - системе сильно полегчало на трафике 700-800мбит

У вас что, преимущественно UDP траффик? Или вы матчили все пакеты, а не только UDP? У нас UDP - от силы % 5-10 от общего траффика... Ессно, с задушеным ютп.

Изменено 1 ноября, 2011 пользователем NiTr0

[Max P]

только udp, кстати его дофига да, у нас очень любят торренты :(