V@No Опубликовано 4 марта, 2009 · Жалоба Есть проблема: Сервер 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 не предлагать, так как он стабильно не работает с много ядерными системами... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 4 марта, 2009 · Жалоба Какой процесс ест больше всего процессорного времени? Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 4 марта, 2009 · Жалоба Какой процесс ест больше всего процессорного времени?Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш? 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 4 марта, 2009 · Жалоба Какой процесс ест больше всего процессорного времени?Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш? фильтров примерно по 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: А что за хеш фильтр? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
inxs Опубликовано 4 марта, 2009 (изменено) · Жалоба Поглядите в /proc/interrupts что больше всего генерит прерываний. Если это сетевухи - раскидайте по разным ядрам вручную. Да, сетевухи, надеюсь, не встроенные? Изменено 4 марта, 2009 пользователем inxs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 4 марта, 2009 · Жалоба Поглядите в /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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 4 марта, 2009 · Жалоба Если это сетевухи - раскидайте по разным ядрам вручную.Разбросал по процесорам сетевые. поглядим что это даст...eth0 - CPU0, CPU1 eth1 - CPU3, CPU4 eth2 - CPU4 надеюсь все же нагрузки как то это сбавит... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 4 марта, 2009 · Жалоба Какой процесс ест больше всего процессорного времени?Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш? А что за хеш фильтр? http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING PS 1000 PT может работать через MSI, а у вас IO-APIC-edge Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 4 марта, 2009 · Жалоба Какой процесс ест больше всего процессорного времени?Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш? А что за хеш фильтр? http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING PS 1000 PT может работать через MSI, а у вас IO-APIC-edge гмм, спасибо сейчас постараюсь разобраться... ЗЫ пока не читал, но хочется спросить сразу для включения MSI без перезборки ядра можно обойтись? Простите за мою лень :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 4 марта, 2009 · Жалоба 2.6.18 MSI поддерживает, но вот поддерживает ли чипсет.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 4 марта, 2009 · Жалоба Какой процесс ест больше всего процессорного времени?Сколько у вас фильтров на интерфейсе? Фильтры линейные или хеш? А что за хеш фильтр? 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 5 марта, 2009 · Жалоба # 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
inxs Опубликовано 5 марта, 2009 · Жалоба Если это сетевухи - раскидайте по разным ядрам вручную.Разбросал по процесорам сетевые. поглядим что это даст...eth0 - CPU0, CPU1 eth1 - CPU3, CPU4 eth2 - CPU4 надеюсь все же нагрузки как то это сбавит... Рекомендую привязывать по принципу "один интерфейс - одно ядро". Прерывания не будут гулять туда-сюда. И да, MSI - ооочень полезная вещь. Если будете пересобирать ядро - включите поддержку oprofile, полезная вещь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_ruslan_ Опубликовано 5 марта, 2009 · Жалоба Что плохого что прерывания прыгают на разные ядра? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 5 марта, 2009 · Жалоба Если это сетевухи - раскидайте по разным ядрам вручную.Разбросал по процесорам сетевые. поглядим что это даст...eth0 - CPU0, CPU1 eth1 - CPU3, CPU4 eth2 - CPU4 надеюсь все же нагрузки как то это сбавит... Рекомендую привязывать по принципу "один интерфейс - одно ядро". Прерывания не будут гулять туда-сюда. И да, MSI - ооочень полезная вещь. Если будете пересобирать ядро - включите поддержку oprofile, полезная вещь. Спасибо за совет, действительно разница очень заметна... после привязки интерфейса к одному ядру, нагрузка на ядра упала на 20-30 %...Сейчас пытаюсь MSI поднять, пока разбираюсь почему не включается... Но с привязкой к интерфейсам сразу шустрее стало работать.... Хочу еще попробовать применить хеш фильтры, по пока не соображу как можно их преобразовать к такому виду... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 5 марта, 2009 · Жалоба Сейчас пытаюсь MSI поднять, пока разбираюсь почему не включается...Если не сложно - отпишись по результатам, пожалуйста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 5 марта, 2009 · Жалоба 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 это последний октет айпи-адреса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 5 марта, 2009 · Жалоба я так понимаю ht 2:b: и ht 2:14: - здесь b и 14 это последний октет айпи-адреса? да Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 5 марта, 2009 · Жалоба хм... интересно, получается хэшкей таблицы распихивает по первым трем октетам, а в bucket попадает только последний октет, а если адресов больше чем 256? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 5 марта, 2009 · Жалоба всё, кажись дошло, бакет делается по последнему октету, и даже если последний октет совпадет у двоих (скажем 10.0.1.20 и 10.1.3.20) то flowid всё равно раскидает по классам как будет указано, так получается? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 5 марта, 2009 · Жалоба Сейчас пытаюсь 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 как и на обычных сетевых... Куда копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 5 марта, 2009 · Жалоба Возможно нужен драйвер e1000e, кажется он появился в 2.6.26 Что говорят: cat /boot/config-`uname -r` |grep CONFIG_PCI_MSI dmesg | grep -i msi lspci -vv -s 00:05:00 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 5 марта, 2009 (изменено) · Жалоба Возможно нужен драйвер 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 и на каждого же поднимается свой класс с шейпером.. можно чуть побольше для примера конфига положить? если не в напряг.... Изменено 5 марта, 2009 пользователем V@No Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cant Опубликовано 5 марта, 2009 (изменено) · Жалоба Cpu0 : 19.5%us, 1.1%sy, 0.0%ni, 78.1%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%stCpu1 : 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 Изменено 5 марта, 2009 пользователем cant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
V@No Опубликовано 7 марта, 2009 · Жалоба Cpu0 : 19.5%us, 1.1%sy, 0.0%ni, 78.1%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%stCpu1 : 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 -------------------------------------------------------------------------------------------------------------- Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...