Перейти к содержимому
Калькуляторы

Загрузка только одного ядра CPU tc тормозит сервер

Есть проблема:

Сервер Core2Quad 3Ггц, 2 Гб, Debian 2.6.18-6-686 #1 SMP

 

При вечерних нагрузках, когда в инете сидит 2000 пользователей, назрузка всего доходит до 80-90Мбит из 150Мбит возможных, и на сервере наблюдается аномальное поведение... При этом начинают появляться задержки у пользователей, не выдает всю полосу

 

top - 17:42:25 up 2 days, 4:29, 6 users, load average: 0.92, 0.78, 0.67

Tasks: 151 total, 3 running, 147 sleeping, 0 stopped, 1 zombie

Cpu0 : 19.5%us, 1.1%sy, 0.0%ni, 78.1%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st

Cpu1 : 17.8%us, 2.3%sy, 0.0%ni, 79.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu2 : 11.3%us, 2.3%sy, 0.0%ni, 86.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu3 : 0.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 99.8%si, 0.0%st

Mem: 2066676k total, 1081680k used, 984996k free, 291220k buffers

Swap: 1951888k total, 0k used, 1951888k free, 393764k cached

 

Тоесть загрузка одного ядра всего лишь...

 

При отключении шейперов tc (просто удаляю tc qdisc del dev eth0 root ), все сразу нормализуется, ну и нагрузка возрастает до 150Мбит, при этом ядра практически не нагружены ...

 

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

Как можно заставить систему что бы с очередью работали все ядра в системе?

Есть ли альтернатива под Linux tc шейперу, для многоядерных систем, rshaper не предлагать, так как он стабильно не работает с много ядерными системами...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой процесс ест больше всего процессорного времени?

Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой процесс ест больше всего процессорного времени?

Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш?

top - 18:43:22 up 2 days, 5:30, 7 users, load average: 2.65, 2.10, 1.75

Tasks: 196 total, 2 running, 192 sleeping, 0 stopped, 2 zombie

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi,100.0%si, 0.0%st

Cpu1 : 0.0%us, 4.5%sy, 0.0%ni, 95.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 2066676k total, 1116460k used, 950216k free, 291952k buffers

Swap: 1951888k total, 0k used, 1951888k free, 399544k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

3 root 35 19 0 0 0 R 65 0.0 27:21.39 ksoftirqd/0

2 root RT 0 0 0 0 S 32 0.0 1:27.06 migration/0

1 root 15 0 1944 644 552 S 0 0.0 0:03.75 init

4 root RT 0 0 0 0 S 0 0.0 1:04.40 migration/1

5 root 34 19 0 0 0 S 0 0.0 18:47.71 ksoftirqd/1

6 root RT 0 0 0 0 S 0 0.0 1:34.26 migration/2

7 root 34 19 0 0 0 S 0 0.0 30:00.97 ksoftirqd/2

8 root RT 0 0 0 0 S 0 0.0 1:12.45 migration/3

9 root 34 19 0 0 0 S 0 0.0 20:59.07 ksoftirqd/3

10 root 10 -5 0 0 0 S 0 0.0 0:23.48 events/0

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой процесс ест больше всего процессорного времени?

Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш?

фильтров примерно по 2 на пользователя, и пользователей 2000, итого 4000

 

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

/sbin/tc class add dev eth0 parent 1: classid 1:65ed htb rate 1024Kibit

/sbin/tc filter add dev eth0 protocol ip parent 1: prio 26093 u32 match ip src 0.0.0.0/0 match ip dst 10.0.0.1 flowid 1:65ed

/sbin/tc filter add dev eth0 protocol ip parent ffff: prio 26092 u32 match ip src 10.0.0.1 match ip dst 0.0.0.0/0 police rate 512Kibit burst 12k drop flowid 1:

 

А что за хеш фильтр?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поглядите в /proc/interrupts что больше всего генерит прерываний. Если это сетевухи - раскидайте по разным ядрам вручную.

 

Да, сетевухи, надеюсь, не встроенные?

Изменено пользователем inxs

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поглядите в /proc/interrupts что больше всего генерит прерываний. Если это сетевухи - раскидайте по разным ядрам вручную.

 

Да, сетевухи, надеюсь, не встроенные?

CPU0 CPU1 CPU2 CPU3

0: 20779996 27799651 8805 75 IO-APIC-edge timer

1: 5526 1 3 3 IO-APIC-edge i8042

7: 0 0 0 0 IO-APIC-edge parport0

8: 0 0 0 0 IO-APIC-edge rtc

9: 0 1 0 0 IO-APIC-level acpi

169: 378392742 363282590 306118461 301253285 IO-APIC-level eth0

177: 130867 766693 179492 1545 IO-APIC-level libata, libata, libata

217: 424720568 393430161 254107445 230558034 IO-APIC-level eth1

225: 448712 1 0 0 IO-APIC-level eth2

NMI: 0 0 0 0

LOC: 47919402 47919387 47750485 47750467

ERR: 0

MIS: 0

 

 

eth0 и eth1 самые нагруженые интерфейсы, хотя и етх2 раньше тоже симетрично обрабатывался ядрами

 

Сетевухи Intel 1000 PT Server... e1000

 

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

 

Вот и бывает временами и попускает

 

top - 19:16:56 up 2 days, 6:03, 6 users, load average: 1.60, 2.00, 2.13

Tasks: 198 total, 4 running, 190 sleeping, 0 stopped, 4 zombie

Cpu0 : 4.7%us, 0.3%sy, 0.0%ni, 43.2%id, 0.0%wa, 0.7%hi, 51.2%si, 0.0%st

Cpu1 : 14.2%us, 1.7%sy, 0.0%ni, 73.9%id, 0.0%wa, 0.0%hi, 10.2%si, 0.0%st

Cpu2 : 4.3%us, 0.3%sy, 0.0%ni, 49.5%id, 0.0%wa, 0.3%hi, 45.5%si, 0.0%st

Cpu3 : 7.7%us, 1.3%sy, 0.0%ni, 67.0%id, 0.0%wa, 0.0%hi, 24.0%si, 0.0%st

Mem: 2066676k total, 1139464k used, 927212k free, 292496k buffers

Swap: 1951888k total, 0k used, 1951888k free, 403488k cached

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

27203 www-data 17 0 0 0 0 Z 9 0.0 0:00.28 index.cgi <defunct>

7 root 34 19 0 0 0 S 8 0.0 33:09.44 ksoftirqd/2

18653 mysql 15 0 2420m 219m 5120 S 4 10.9 24:00.93 mysqld

25075 www-data 16 0 24320 5784 1568 S 4 0.3 0:00.12 apache2

3 root 34 19 0 0 0 S 3 0.0 32:31.54 ksoftirqd/0

2 root RT 0 0 0 0 S 3 0.0 1:45.08 migration/0

27205 www-data 17 0 0 0 0 Z 3 0.0 0:00.08 index.cgi <defunct>

27204 www-data 17 0 0 0 0 Z 2 0.0 0:00.07 index.cgi <defunct>

22981 www-data 15 0 24320 5776 1568 S 2 0.3 0:01.48 apache2

25399 www-data 15 0 24320 5784 1568 S 2 0.3 0:00.09 apache2

19895 www-data 15 0 24452 5832 1588 S 1 0.3 0:00.41 apache2

6 root RT 0 0 0 0 S 0 0.0 1:46.13 migration/2

10 root 10 -5 0 0 0 S 0 0.0 0:35.29 events/0

22525 www-data 18 0 24320 5788 1568 R 0 0.3 0:00.73 apache2

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если это сетевухи - раскидайте по разным ядрам вручную.
Разбросал по процесорам сетевые. поглядим что это даст...

eth0 - CPU0, CPU1

eth1 - CPU3, CPU4

eth2 - CPU4

 

надеюсь все же нагрузки как то это сбавит...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой процесс ест больше всего процессорного времени?

Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш?

А что за хеш фильтр?

http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING

 

PS 1000 PT может работать через MSI, а у вас IO-APIC-edge

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой процесс ест больше всего процессорного времени?

Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш?

А что за хеш фильтр?

http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING

 

PS 1000 PT может работать через MSI, а у вас IO-APIC-edge

гмм, спасибо сейчас постараюсь разобраться...

ЗЫ пока не читал, но хочется спросить сразу для включения MSI без перезборки ядра можно обойтись? Простите за мою лень :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2.6.18 MSI поддерживает, но вот поддерживает ли чипсет....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какой процесс ест больше всего процессорного времени?

Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш?

А что за хеш фильтр?

http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING

 

PS 1000 PT может работать через MSI, а у вас IO-APIC-edge

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 800:: \

match ip src 1.2.0.0/16 \

hashkey mask 0x000000ff at 12 \

link 2:

 

к сожалению данная схема как раз нужна для QoS, тоесть с системой выделения приоритетов... да это ускорит работу, но в моем случае это не применимо, я же tc использую только для ограничения скорости и каждому пользователю создается свой индивидуальный класс, а фильтра всего два в каждом классе:

>/sbin/tc class add dev eth0 parent 1: classid 1:65ed htb rate 1024Kibit

>/sbin/tc filter add dev eth0 protocol ip parent 1: prio 26093 u32 match ip src 0.0.0.0/0 match ip dst 10.0.0.1 flowid 1:65ed

>/sbin/tc filter add dev eth0 protocol ip parent ffff: prio 26092 u32 match ip src 10.0.0.1 match ip dst 0.0.0.0/0 police rate 512Kibit burst 12k drop flowid 1:

 

 

необходим производительный шейпер без поддержки QoS, который бы дружил с SMP.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 800:: \

match ip src 1.2.0.0/16 \

hashkey mask 0x000000ff at 12 \

link 2:

 

к сожалению данная схема как раз нужна для QoS, тоесть с системой выделения приоритетов... да это ускорит работу, но в моем случае это не применимо, я же tc использую только для ограничения скорости и каждому пользователю создается свой индивидуальный класс, а фильтра всего два в каждом классе:

>/sbin/tc class add dev eth0 parent 1: classid 1:65ed htb rate 1024Kibit

>/sbin/tc filter add dev eth0 protocol ip parent 1: prio 26093 u32 match ip src 0.0.0.0/0 match ip dst 10.0.0.1 flowid 1:65ed

>/sbin/tc filter add dev eth0 protocol ip parent ffff: prio 26092 u32 match ip src 10.0.0.1 match ip dst 0.0.0.0/0 police rate 512Kibit burst 12k drop flowid 1:

 

 

необходим производительный шейпер без поддержки QoS, который бы дружил с SMP.

1. другой шейпер только на другой ОС

2. не вижу никаких проблем с применение хеш-фильтров у вас, просто стоит получше вникнуть как это работает

---------

пример:

 

qdisc add dev ifb1 root handle ff0b htb default 1

class add dev ifb1 root htb rate 95000000 ceil 95000000 quantum 6056

 

filter add dev ifb1 parent ff0b:0000 prio 3 handle 2: protocol ip u32 divisor 256

filter add dev ifb1 parent ff0b:0000 protocol pref 3 ip u32 ht 800:: match ip dst 10.0.0.0/8 hashkey mask 0x000000ff at 16 link 2:

 

class add dev ifb1 parent ff0b:0000 classid ff0b:7 htb rate 37065 ceil 201600 prio 1 cburst 2520.0 quantum 1500

filter add dev ifb1 parent ff0b:0000 protocol ip pref 3 u32 ht 2:b: match ip dst 10.3.93.11 flowid ff0b:7

qdisc add dev ifb1 parent ff0b:7 handle 7 sfq perturb 10

class add dev ifb1 parent ff0b:0000 classid ff0b:8 htb rate 37065 ceil 201600 prio 1 cburst 2520.0 quantum 1500

filter add dev ifb1 parent ff0b:0000 protocol ip pref 3 u32 ht 2:14: match ip dst 10.1.53.20 flowid ff0b:8

qdisc add dev ifb1 parent ff0b:8 handle 8 sfq perturb 10

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если это сетевухи - раскидайте по разным ядрам вручную.
Разбросал по процесорам сетевые. поглядим что это даст...

eth0 - CPU0, CPU1

eth1 - CPU3, CPU4

eth2 - CPU4

 

надеюсь все же нагрузки как то это сбавит...

Рекомендую привязывать по принципу "один интерфейс - одно ядро". Прерывания не будут гулять туда-сюда. И да, MSI - ооочень полезная вещь.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что плохого что прерывания прыгают на разные ядра?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если это сетевухи - раскидайте по разным ядрам вручную.
Разбросал по процесорам сетевые. поглядим что это даст...

eth0 - CPU0, CPU1

eth1 - CPU3, CPU4

eth2 - CPU4

 

надеюсь все же нагрузки как то это сбавит...

Рекомендую привязывать по принципу "один интерфейс - одно ядро". Прерывания не будут гулять туда-сюда. И да, MSI - ооочень полезная вещь.

 

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

Спасибо за совет, действительно разница очень заметна... после привязки интерфейса к одному ядру, нагрузка на ядра упала на 20-30 %...

Сейчас пытаюсь MSI поднять, пока разбираюсь почему не включается... Но с привязкой к интерфейсам сразу шустрее стало работать....

Хочу еще попробовать применить хеш фильтры, по пока не соображу как можно их преобразовать к такому виду...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2. не вижу никаких проблем с применение хеш-фильтров у вас, просто стоит получше вникнуть как это работает

---------

пример:

...

class add dev ifb1 parent ff0b:0000 classid ff0b:7 htb rate 37065 ceil 201600 prio 1 cburst 2520.0 quantum 1500

filter add dev ifb1 parent ff0b:0000 protocol ip pref 3 u32 ht 2:b: match ip dst 10.3.93.11 flowid ff0b:7

qdisc add dev ifb1 parent ff0b:7 handle 7 sfq perturb 10

class add dev ifb1 parent ff0b:0000 classid ff0b:8 htb rate 37065 ceil 201600 prio 1 cburst 2520.0 quantum 1500

filter add dev ifb1 parent ff0b:0000 protocol ip pref 3 u32 ht 2:14: match ip dst 10.1.53.20 flowid ff0b:8

qdisc add dev ifb1 parent ff0b:8 handle 8 sfq perturb 10

я так понимаю ht 2:b: и ht 2:14: - здесь b и 14 это последний октет айпи-адреса?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я так понимаю ht 2:b: и ht 2:14: - здесь b и 14 это последний октет айпи-адреса?

да

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

всё, кажись дошло, бакет делается по последнему октету, и даже если последний октет совпадет у двоих (скажем 10.0.1.20 и 10.1.3.20) то flowid всё равно раскидает по классам как будет указано, так получается?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Вот результат сегодняшнего колупания в сервере c сетевой Intel PRO 1000 PT

 

Core2Quad, MB: Gigabyte G33, Debian 2.6.18,

 

ethtool -i eth6

driver: e1000

version: 7.1.9-k4-NAPI

firmware-version: 5.11-5

bus-info: 0000:01:00.0

 

PCI-MSI поднялась каким то чудом.

 

 

Core2Duo, MB: Intel G33, ASP LINUX 11, 2.6.20

ethtool -i eth2

driver: e1000

version: 7.3.15-k2-NAPI

firmware-version: 5.11-8

bus-info: 0000:05:00.0

 

Никак не заставлю подняться PCI-MSI, только включено IO-APIC-fasteoi как и на обычных сетевых... Куда копать?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно нужен драйвер e1000e, кажется он появился в 2.6.26

Что говорят:

 

cat /boot/config-`uname -r` |grep CONFIG_PCI_MSI

 

dmesg | grep -i msi

 

lspci -vv -s 00:05:00

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно нужен драйвер e1000e, кажется он появился в 2.6.26

Что говорят:

 

cat /boot/config-`uname -r` |grep CONFIG_PCI_MSI

 

dmesg | grep -i msi

 

lspci -vv -s 00:05:00

Да драйвер уже и для e1000e установил, после чего поднялась даже сетевая на борту, оказалась бортовая интеловая e1000e :)

но для сетевых все равно поднимает e1000....

Но где на сервере подняла PCI-MSI режим, все равно нагрузка на машину не уменьшилась, все также шейпера убивают машину, правда теперь два ядра нагружены на 100%, только все равно система начинает подтормаживать все... :(

Ума не приложу как можно хеширование применить, все ж айпишни уникальные, из подсети 10.0.0.0/8 и на каждого же поднимается свой класс с шейпером.. можно чуть побольше для примера конфига положить? если не в напряг....

Изменено пользователем V@No

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Cpu0 : 19.5%us, 1.1%sy, 0.0%ni, 78.1%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st

Cpu1 : 17.8%us, 2.3%sy, 0.0%ni, 79.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu2 : 11.3%us, 2.3%sy, 0.0%ni, 86.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu3 : 0.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 99.8%si, 0.0%st

 

Cpu0 : 4.7%us, 0.3%sy, 0.0%ni, 43.2%id, 0.0%wa, 0.7%hi, 51.2%si, 0.0%st

Cpu1 : 14.2%us, 1.7%sy, 0.0%ni, 73.9%id, 0.0%wa, 0.0%hi, 10.2%si, 0.0%st

Cpu2 : 4.3%us, 0.3%sy, 0.0%ni, 49.5%id, 0.0%wa, 0.3%hi, 45.5%si, 0.0%st

Cpu3 : 7.7%us, 1.3%sy, 0.0%ni, 67.0%id, 0.0%wa, 0.0%hi, 24.0%si, 0.0%st

При сравнении можно предположить, что irqbalance глючит.

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

 

 

Разбросал по процесорам сетевые. поглядим что это даст...

eth0 - CPU0, CPU1

eth1 - CPU3, CPU4

eth2 - CPU4

... после привязки интерфейса к одному ядру, нагрузка на ядра упала на 20-30 %...

 

Но где на сервере подняла PCI-MSI режим, все равно нагрузка на машину не уменьшилась, все также шейпера убивают машину, правда теперь два ядра нагружены на 100%, только все равно система начинает подтормаживать все... :(

Если softirq (51.2%si), бодаться с MSI, которое я предполагаю облегчает только hardirq(0.7%hi), бессмысленно.

 

Покажите на данный момент proc/interrupts и top

 

только два пути:

- либо облегчать softirq

- либо продолжать разводить irq, на худой конец APIC round-robin

Изменено пользователем cant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Cpu0 : 19.5%us, 1.1%sy, 0.0%ni, 78.1%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st

Cpu1 : 17.8%us, 2.3%sy, 0.0%ni, 79.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu2 : 11.3%us, 2.3%sy, 0.0%ni, 86.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu3 : 0.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 99.8%si, 0.0%st

 

Cpu0 : 4.7%us, 0.3%sy, 0.0%ni, 43.2%id, 0.0%wa, 0.7%hi, 51.2%si, 0.0%st

Cpu1 : 14.2%us, 1.7%sy, 0.0%ni, 73.9%id, 0.0%wa, 0.0%hi, 10.2%si, 0.0%st

Cpu2 : 4.3%us, 0.3%sy, 0.0%ni, 49.5%id, 0.0%wa, 0.3%hi, 45.5%si, 0.0%st

Cpu3 : 7.7%us, 1.3%sy, 0.0%ni, 67.0%id, 0.0%wa, 0.0%hi, 24.0%si, 0.0%st

При сравнении можно предположить, что irqbalance глючит.

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

 

 

Разбросал по процесорам сетевые. поглядим что это даст...

eth0 - CPU0, CPU1

eth1 - CPU3, CPU4

eth2 - CPU4

... после привязки интерфейса к одному ядру, нагрузка на ядра упала на 20-30 %...

 

Но где на сервере подняла PCI-MSI режим, все равно нагрузка на машину не уменьшилась, все также шейпера убивают машину, правда теперь два ядра нагружены на 100%, только все равно система начинает подтормаживать все... :(

Если softirq (51.2%si), бодаться с MSI, которое я предполагаю облегчает только hardirq(0.7%hi), бессмысленно.

 

Покажите на данный момент proc/interrupts и top

 

только два пути:

- либо облегчать softirq

- либо продолжать разводить irq, на худой конец APIC round-robin

-----------------------------------------------------------------------------------------------------------------

top - 20:53:10 up 1 day, 17:02, 5 users, load average: 0.97, 1.15, 0.94

Tasks: 166 total, 3 running, 162 sleeping, 0 stopped, 1 zombie

Cpu0 : 5.7%us, 0.7%sy, 0.0%ni, 93.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st

Cpu1 : 3.1%us, 0.3%sy, 0.0%ni, 27.5%id, 0.0%wa, 0.0%hi, 69.2%si, 0.0%st

Cpu2 : 1.7%us, 0.7%sy, 0.0%ni, 57.7%id, 0.0%wa, 0.0%hi, 35.0%si, 0.0%st

Cpu3 : 15.4%us, 1.0%sy, 0.0%ni, 10.7%id, 0.0%wa, 0.3%hi, 72.5%si, 0.0%st

Mem: 2066676k total, 1136232k used, 930444k free, 313868k buffers

Swap: 1951888k total, 0k used, 1951888k free, 297228k cached

 

-----------------------------------------------------------------------------------------------------------------

 

BillingGate1:~# cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

0: 17917864 16806884 1911200 313695 IO-APIC-edge timer

1: 4418 2 2 2 IO-APIC-edge i8042

7: 0 0 0 0 IO-APIC-edge parport0

8: 0 0 0 0 IO-APIC-edge rtc

9: 0 1 0 0 IO-APIC-level acpi

50: 0 0 0 0 IO-APIC-level eth4

58: 117371790 90933300 91663649 69468905 PCI-MSI eth0

66: 137759727 101608929 115125261 92038031 PCI-MSI eth1

169: 0 0 0 0 IO-APIC-level eth3

177: 398725 325325 15816 75906 IO-APIC-level libata, libata, libata

233: 1012728 604841 356690 216351 IO-APIC-level eth2

NMI: 0 0 0 0

LOC: 36554621 36554565 36497850 36497857

ERR: 0

MIS: 0

--------------------------------------------------------------------------------------------------------------

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.