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

Непонятки с прерываниями Два ядра в полку, два курят..

Роутер/NAT на Centos 5, amd64, ядро - 2.6.34, два Intel Xeon CPU E5503 2.00GHz, сетевая Intel 82576 (двухголовая).

Машина обрабатывает (NAT и фаервол) в максимуме порядка 550Мбит/60Kpps.

Собственно тему создал в продолжение "Отловить процесс".

Обратил внимание на то, что во время проблемы одно из ядер CPU загружено в 100%. Решил прибить прерывания к ядрам, стало еще хуже. Как только не манипулировал очередями, результат одинаков - два ядра, к которым прибиты eth2 - в полку, два прохлаждаются.

eth2 (VLAN9) смотрит "наружу", eth3 - соотв. к NAS-ам.

Вот например сейчас

cpu | sys       0% | user      0% | irq      99%  | idle      1% | cpu002 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      0% | irq      96%  | idle      4% | cpu000 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      0% | irq      46%  | idle     54% | cpu001 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      0% | irq      42%  | idle     58% | cpu003 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
CPL | avg1    1.29 | avg5    1.33 |               | avg15   1.30 |              | csw     2815 | intr   69497 |               |              | numcpu     4 |
MEM | tot     5.8G | free    5.3G | cache 123.4M  | dirty   0.0M | buff   17.2M | slab  206.6M |              |               |              |              |
SWP | tot    11.7G | free   11.7G |               |              |              |              |              |               | vmcom 237.6M | vmlim  14.6G |
DSK |          sda | busy      0% | read       0  | write      1 | KiB/r      0 | KiB/w      4 | MBr/s   0.00 | MBw/s   0.00  | avq     1.00 | avio 4.00 ms |
NET | transport    | tcpi       7 | tcpo       8  | udpi     198 | udpo     176 | tcpao      0 | tcppo      0 | tcprs      0  | tcpie      0 | udpip      0 |
NET | network      | ipi  1193362 | ipo  1101038  | ipfrw 1101e3 | deliv    207 |              |              |               | icmpi      2 | icmpo     16 |
NET | eth2     47% | pcki  634330 | pcko  501791  | si  476 Mbps | so  144 Mbps | coll       0 | erri       0 | erro       0  | drpi       0 | drpo       0 |
NET | eth3     47% | pcki  558293 | pcko  599276  | si  146 Mbps | so  474 Mbps | coll       0 | erri       0 | erro       0  | drpi       0 | drpo       0 |
NET | vlan10   47% | pcki  557192 | pcko  598463  | si  140 Mbps | so  474 Mbps | coll       0 | erri       0 | erro       0  | drpi       0 | drpo       0 |
NET | vlan9    47% | pcki  636163 | pcko  502576  | si  470 Mbps | so  145 Mbps | coll       0 | erri       0 | erro       0  | drpi       0 | drpo       0 |
NET | vlan7     0% | pcki       1 | pcko       2  | si    0 Kbps | so    1 Kbps | coll       0 | erri       0 | erro       0  | drpi       0 | drpo       0 |
NET | lo      ---- | pcki       6 | pcko       6  | si    0 Kbps | so    0 Kbps | coll       0 | erri       0 | erro       0  | drpi       0 | drpo       0 |

Еще больше загнало в ступор то, что на загруженных ядрах прерываний почти в три раза меньше, чем на незагруженных!!

         CPU0            CPU1       CPU2       CPU3
70:          6          0          0          0   PCI-MSI-edge      eth2
71:   10726249          0          0          0   PCI-MSI-edge      eth2-TxRx-0
72:      52868          0    7865424          0   PCI-MSI-edge      eth2-TxRx-1
73:          6          0          0          0   PCI-MSI-edge      eth3
74:      64699   44323644          0          0   PCI-MSI-edge      eth3-TxRx-0
75:      46723          0          0   43611817   PCI-MSI-edge      eth3-TxRx-1

Выпал в осадок....

Что посоветуете? Вернуть irqbalance и готовить второй рутер, или все же есть что еще покрутить?

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

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


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

У Вас входящий трафик на eth2 в 4 раза выше входящего трафика на eth3, соответственно, нагрузка на ядра под eth2 выше.

Увеличьте число очередей на платах, либо включайте RPS.

Кстати трафик у Вас относительно небольшой - фильтры построены неоптимально? Какой проц?

Изменено пользователем Alex/AT

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


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

У Вас входящий трафик на eth2 в 4 раза выше входящего трафика на eth3, соответственно, нагрузка на ядра под eth2 выше.

Увеличьте число очередей на платах, либо включайте RPS.

Ну так входящий на eth3 - это исходящий от клиентов, а входящий на eth2 - соотв. исходящий к клиентам. Вроде как нормально?

Кстати, а как увеличить число очередей и каким образом их потом раскидать на 4 ядра?

Кстати трафик у Вас относительно небольшой - фильтры построены неоптимально? Какой проц?

Какие фильтры Вы имеете ввиду? iptables? И в чем может заключаться неоптимальность - в порядке следования правил?

Проц - два Intel Xeon E5503 2.00GHz (в первом посту озвучивал).

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

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


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

В одной из веток тов. kayot (прошу прощения, если ник переврал) подсоветовал, что делать в случаях, когда igb отказывается создавать нужное число очередей автоматически:

в общем случае достаточно создать файлик etc/modprobe.d/igb.conf со строчкой options igb RSS=4,4,4,4

Можно глянуть на документацию по опции RSS в igb еще, там детали.

 

Что же до фильтров - посмотрите, может быть слишком много правил подряд идёт, и их можно как-то соптимизировать, разбив на "ветки исполнения". Конкретно Вашей ситуации не знаю, конечно, просто предположение.

Изменено пользователем Alex/AT

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


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

а можно хоть узнать сколько там правил ?? ато вдруг там тыща юзеров и для каждого создается запись НАТ и запись разрешения форварда ? ))

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


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

У Вас входящий трафик на eth2 в 4 раза выше входящего трафика на eth3, соответственно, нагрузка на ядра под eth2 выше.

Увеличьте число очередей на платах, либо включайте RPS.

Ну так входящий на eth3 - это исходящий от клиентов, а входящий на eth2 - соотв. исходящий к клиентам. Вроде как нормально?

Кстати, а как увеличить число очередей и каким образом их потом раскидать на 4 ядра?

Кстати трафик у Вас относительно небольшой - фильтры построены неоптимально? Какой проц?

Какие фильтры Вы имеете ввиду? iptables? И в чем может заключаться неоптимальность - в порядке следования правил?

Проц - два Intel Xeon E5503 2.00GHz (в первом посту озвучивал).

из собственного опыта, четырехядерный

Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz

с 82576 NAT-ит 1 Гбит сек, 300k conntrack на 80% нагрузке всех ядер.

 

подгружайте модуль так

options igb IntMode=2,2,2,2 RSS=8,8,8,8 InterruptThrottleRate=100000,100000,100000,100000 QueuePairs=0,0,0,0

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


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

из собственного опыта, четырехядерный

Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz

с 82576 NAT-ит 1 Гбит сек, 300k conntrack на 80% нагрузке всех ядер.

 

подгружайте модуль так

options igb IntMode=2,2,2,2 RSS=8,8,8,8 InterruptThrottleRate=100000,100000,100000,100000 QueuePairs=0,0,0,0

Я так понимаю, у вас 4 сетевые, по 8 раздельных очередей на каждую (4rx/4tx), а не как у меня - "совмещенные" Tx-Rx?

А можно взглянуть, как Вы раскидали 8 очередей на 4 ядра?

 

P.S. Источник проблемы вроде нашел. Думаю, что как обычно - кривой /dev/hands :) Похоже я перемудрил с NAT-ом - натил на 4 IP повешенных на один физ. интерфейс (eth2). Сделал весь NAT на один IP, полегчало существенно, сейчас макс. где-то до 50% не поднималось. Правда и траф еще до максимума не доходил. Но все равно - результат налицо.

Кстати, до сих пор не могу осмыслить "обратное" соотношение загрузки CPU и прерываний.

           CPU0       CPU1       CPU2       CPU3
70:          8          0          0          0   PCI-MSI-edge      eth2
71:   85317443          0          0          0   PCI-MSI-edge      eth2-TxRx-0
72:      52868          0   81841969          0   PCI-MSI-edge      eth2-TxRx-1
73:          8          0          0          0   PCI-MSI-edge      eth3
74:      64699  218013805          0          0   PCI-MSI-edge      eth3-TxRx-0
75:      46723          0          0  198618931   PCI-MSI-edge      eth3-TxRx-1

Проц. грузят очереди с eth2, а прерываний больше на eth3.. Ну никак не укладывается, мозг вскипел. :)

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


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

Я так понимаю, у вас 4 сетевые, по 8 раздельных очередей на каждую (4rx/4tx), а не как у меня - "совмещенные" Tx-Rx?

А можно взглянуть, как Вы раскидали 8 очередей на 4 ядра?

 

Сетевуха четырехпортовая, используется только 2 порта

 

35:          1          0          0          1   PCI-MSI-edge      eth0
36:       2002       1904 4002760612       1991   PCI-MSI-edge      eth0-TxRx-0
37:       1936 4157100612       1871       1865   PCI-MSI-edge      eth0-TxRx-1
38: 4197197814       1896       1986       1956   PCI-MSI-edge      eth0-TxRx-2
39:       1940       2005       2020 4021462198   PCI-MSI-edge      eth0-TxRx-3
40:       2013       2018 4053162780       1986   PCI-MSI-edge      eth0-TxRx-4
41:       1990 3892384913       1950       1958   PCI-MSI-edge      eth0-TxRx-5
42: 3971787336       2052       2044       1964   PCI-MSI-edge      eth0-TxRx-6
43:       2029       1967       1948 4093030421   PCI-MSI-edge      eth0-TxRx-7
44:          0          0          1          1   PCI-MSI-edge      eth1
45:      14932 1512296528      14931      14920   PCI-MSI-edge      eth1-TxRx-0
46: 1710164365      16123      16086      16238   PCI-MSI-edge      eth1-TxRx-1
47:      16294      16293      16632 1821253265   PCI-MSI-edge      eth1-TxRx-2
48:      16677      17028 3490982320      17088   PCI-MSI-edge      eth1-TxRx-3
49:      15790 1726392359      15207      15460   PCI-MSI-edge      eth1-TxRx-4
50: 1864548276      15648      15898      15837   PCI-MSI-edge      eth1-TxRx-5
51:      15636      15427      15401 1822700487   PCI-MSI-edge      eth1-TxRx-6
52:      15634      15616 1813565486      15458   PCI-MSI-edge      eth1-TxRx-7

 

распихиваю таким скриптом

#!/bin/sh
#
#  irq2smp -- distribute hardware interrupts from Ethernet devices by CPU cores.
#
#  Should be called from /etc/rc.local.
#

ncpus=`grep -ciw ^processor /proc/cpuinfo`
test "$ncpus" -gt 1 || exit 1

n=0
for irq in `cat /proc/interrupts | grep eth | awk '{print $1}' | sed s/\://g`
do
   f="/proc/irq/$irq/smp_affinity"
   test -r "$f" || continue
   cpu=$[$ncpus - ($n % $ncpus) - 1]
   if [ $cpu -ge 0 ]
           then
               mask=`printf %x $[2 ** $cpu]`
               echo "Assign SMP affinity: eth$n, irq $irq, cpu $cpu, mask 0x$mask"
               echo "$mask" > "$f"
               let n+=1
   fi
done

 

автор данного скрипта присутствует на данном форуме

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


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

Учитывайте локализацию кеша. Т.е. у ядер может быть общий кеш, плюс локализация по процессору и т.п.

Я скоро постараюсь написать на эту тему небольшую статейку, если будет время.

Если не будет - выкину то, что нарыл и кто-то напишет :)

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


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

Учитывайте локализацию кеша. Т.е. у ядер может быть общий кеш, плюс локализация по процессору и т.п.

Тяжеловатая задачка для меня, если не сказать хуже. :)

Я скоро постараюсь написать на эту тему небольшую статейку, если будет время.

Если не будет - выкину то, что нарыл и кто-то напишет :)

А основные постулаты можно сейчас увидеть?

 

P.S. Кстати, а вообще, есть ли какой смысл увеличивать кол-во очередей до 8 при наличии 4-х ядер? Не пойму, что это может дать? Все равно одно ядро будет вместо одной очереди обслуживать две, т.е. соотв. увеличивается как загрузка ядра, так и время обработки прерывания.

Да, и еще - насчет "обратного" соотношение загрузки CPU и прерываний есть какие-либо соображения? Что-то беспокоит меня этот Гондурас. :-)

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


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

Учитывайте локализацию кеша. Т.е. у ядер может быть общий кеш, плюс локализация по процессору и т.п.

Я скоро постараюсь написать на эту тему небольшую статейку, если будет время.

Если не будет - выкину то, что нарыл и кто-то напишет :)

 

Здесь же один процессор :)

 

Если бы было два процессора, то имело бы смысл прерывания от eth0 кинуть на ядра первого процессора, прерывания от eth1 раскидать по ядрам второго. На данном форуме видел shell скрипт который делает подобное.

 

Кидайте что нарыли, можем совместно статью оформить.

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


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

Здесь же один процессор :)

Если бы было два процессора, то имело бы смысл прерывания от eth0 кинуть на ядра первого процессора, прерывания от eth1 раскидать по ядрам второго. На данном форуме видел shell скрипт который делает подобное.

 

Это у Вас один, а у меня два! ;)

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


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

Если бы было два процессора, то имело бы смысл прерывания от eth0 кинуть на ядра первого процессора, прерывания от eth1 раскидать по ядрам второго.

Вряд ли.

Обмен данными будет проходить через кэш L1 или даже через ОЗУ, из-за этого проигрыш скорости будет сильнее, чем ускорение из-за количества ядер.

 

На данном форуме видел shell скрипт который делает подобное.

http://forum.nag.ru/forum/index.php?showtopic=53404&view=findpost&p=459338

 

Это у Вас один, а у меня два! ;)

Такая же бесполезная imho вещь на роутере, как hyperthreading.

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


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

Это у Вас один, а у меня два! ;)

Такая же бесполезная imho вещь на роутере, как hyperthreading.

Не в первый раз вижу, как ht называют бесполезной вещью на этом форуме. Расскажите, в чем бесполезность?

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


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

Не в первый раз вижу, как ht называют бесполезной вещью на этом форуме. Расскажите, в чем бесполезность?

Конвейеры команд и блоки регистров разные, всё остальное общее.

Из-за этого один из конвейеров почти всегда заблокирован.

Плюс потери собственно на операциях блокировки.

HT полезен только для сложных вычислений, у которых промежуточные данные помещаются в регистры (MISD в таксономии Флинна).

Роутер - это скорее MIMD или даже SIMD.

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


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

Не в первый раз вижу, как ht называют бесполезной вещью на этом форуме. Расскажите, в чем бесполезность?

Конвейеры команд и блоки регистров разные, всё остальное общее.

Из-за этого один из конвейеров почти всегда заблокирован.

Плюс потери собственно на операциях блокировки.

HT полезен только для сложных вычислений, у которых промежуточные данные помещаются в регистры (MISD в таксономии Флинна).

Роутер - это скорее MIMD или даже SIMD.

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

Да и HT сейчас уже не тот, что прежде.

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


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

Открою секрет: аппаратное переключение контекстов на x86 уже давно не используется. Основная причина - сохраняет не всё состояние, регистров FPU в TSS никогда не было. Ну и в целом зачастую оно все-таки медленнее софтового переключения контекста - поскольку не всегда надо сохранять всё целиком, смотря что за вызов. А в x86_64 архитектуре аппаратный context switch вообще отменили, оставив от TSS минимально необходимый набор параметров.

Изменено пользователем Alex/AT

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


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

Открою секрет: аппаратное переключение контекстов на x86 уже давно не используется. Основная причина - сохраняет не всё состояние, регистров FPU в TSS никогда не было. Ну и в целом медленнее софтового переключения контекста - поскольку не всегда надо сохранять всё целиком, смотря что за вызов. А в x86_64 архитектуре аппаратный context switch вообще отменили, оставив от TSS минимально необходимый набор параметров.

В данном случае под контекстами я подразумеваю общую инфраструктуру, используемую тредами:

Другие ресурсы можно совместно использовать двумя потоками, сюда входит вся логика внеочередного выполнения (буфер изменения порядка инструкций/instruction reorder buffer, исполнительные блоки и кэш).

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


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

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

Ну Вы и загнули.

Вообще-то Карл Маркс и Фридрих Энгельс - это не муж и жена, а четыре совершенно разных человека.

 

Блокировки в планировщике ОС и в ядре процессора используются для разных вещей.

Переключение контекстов на маршрутизаторе не используется вообще - все выполняется в ядре (про minix и divert-сокеты в другой раз).

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


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

Переключение контекстов на маршрутизаторе не используется вообще - все выполняется в ядре (про minix и divert-сокеты в другой раз).

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

 

Заранее прошу прощения за сумбурность изложения, я с такими тонкими материями не работал. Меня интересуют именно возможные ограничения SMT в современных интелах. Во что упрется? И когда?

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


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

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

16_45.jpg

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


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

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

16_45.jpg

Во что упрется? И когда?

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


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

Господа! А можно что-нибудь по теме?

Например, увеличить кол-во очередей до 8 на интерфейс и использовать вот этот скрипт

#!/bin/sh
#
#  irq2smp -- distribute hardware interrupts from Ethernet devices by CPU cores.
#
#  Should be called from /etc/rc.local.
#

ncpus=`grep -ciw ^processor /proc/cpuinfo`
test "$ncpus" -gt 1 || exit 1

n=0
for irq in `cat /proc/interrupts | grep eth | awk '{print $1}' | sed s/\://g`
do
   f="/proc/irq/$irq/smp_affinity"
   test -r "$f" || continue
   cpu=$[$ncpus - ($n % $ncpus) - 1]
   if [ $cpu -ge 0 ]
           then
               mask=`printf %x $[2 ** $cpu]`
               echo "Assign SMP affinity: eth$n, irq $irq, cpu $cpu, mask 0x$mask"
               echo "$mask" > "$f"
               let n+=1
   fi
done

при двухпроцессорном варианте (учитывая комментарии от nuclearcat)?

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

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


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

Блин, вы бы уже быстрее сами попробовали бы и сравнили результаты.

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


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

Такс, подсказки, с примером:

Машинка, относительно старенькая двухкотловая, процы E5440, Quad Core (Harpertown). Итого 8 ядер, без SMT.

Визуально архитектуру смотрим здесь

Nehalem-1.gif

По сути два Duo с общим L2 кешем, в одном корпусе, никаких NUMA. С NUMA все кстати несколько сложнее. При такой архитектуре лучше всего раскидывать данные, которым может потребоваться общий кеш

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

Как увидеть архитектуру наглядно, выкушу самое интересное:

grep -r "" /sys/devices/system/cpu/

...

/sys/devices/system/cpu/cpu0/cache/index2/level:2

/sys/devices/system/cpu/cpu0/cache/index2/coherency_line_size:64

/sys/devices/system/cpu/cpu0/cache/index2/physical_line_partition:1

/sys/devices/system/cpu/cpu0/cache/index2/ways_of_associativity:24

/sys/devices/system/cpu/cpu0/cache/index2/number_of_sets:4096

/sys/devices/system/cpu/cpu0/cache/index2/size:6144K

/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:05

/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2

/sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count:0

/sys/devices/system/cpu/cpu0/topology/physical_package_id:0

/sys/devices/system/cpu/cpu0/topology/core_id:0

/sys/devices/system/cpu/cpu0/topology/thread_siblings:01

/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0

/sys/devices/system/cpu/cpu0/topology/core_siblings:55

/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0,2,4,6

А теперь самое интересное:

 

Физический проц, ядра нумеруются достаточно странно:

/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0,2,4,6

Т.е. если мы хотим остаться в пределах одного проца, то раскидываем нагрузку на 0,2,4,6!

В данном случае физическая упаковка несущественна, мы на самом деле имеем 4xCore Duo.

 

Общий кеш у них L2, и вот те, кто сидят в общем кеше.

/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2

 

Проверим на реальной нагрузке, вот правильно разбросанная нагрузка

GlobalNAT ~ # mpstat -P ALL 10

Linux 3.2.7-build-0060 (GlobalNAT) 03/02/12 _i686_ (8 CPU)

 

14:06:23 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:06:33 all 0.00 0.00 0.01 0.00 0.01 10.04 0.00 0.00 89.94

14:06:33 0 0.00 0.00 0.00 0.00 0.00 40.61 0.00 0.00 59.39

14:06:33 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

14:06:33 2 0.00 0.00 0.10 0.00 0.00 39.74 0.00 0.00 60.16

 

14:06:48 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:06:58 all 0.00 0.00 0.01 0.00 0.01 10.03 0.00 0.00 89.95

14:06:58 0 0.00 0.00 0.10 0.00 0.00 40.12 0.00 0.00 59.77

14:06:58 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

14:06:58 2 0.00 0.00 0.10 0.00 0.10 39.90 0.00 0.00 59.90

 

 

14:06:58 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:07:08 all 0.00 0.00 0.03 0.00 0.00 9.87 0.00 0.00 90.11

14:07:08 0 0.00 0.00 0.10 0.00 0.00 40.23 0.00 0.00 59.67

14:07:08 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

14:07:08 2 0.00 0.00 0.00 0.00 0.00 39.49 0.00 0.00 60.51

 

А вот неправильно:

14:07:59 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:08:09 all 0.00 0.00 0.01 0.00 0.00 13.69 0.00 0.00 86.30

14:08:09 0 0.00 0.00 0.10 0.00 0.00 56.03 0.00 0.00 43.87

14:08:09 1 0.00 0.00 0.10 0.00 0.00 54.38 0.00 0.00 45.52

 

14:08:09 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:08:19 all 0.01 0.00 0.03 0.00 0.01 13.69 0.00 0.00 86.26

14:08:19 0 0.00 0.00 0.00 0.00 0.00 56.18 0.00 0.00 43.82

14:08:19 1 0.00 0.00 0.10 0.00 0.00 53.82 0.00 0.00 46.08

 

А вот если мы все запихиваем на один проц, но тут мы упираемся в суммарную производительность одного ядра:

 

14:10:08 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:10:18 all 0.00 0.00 0.00 0.00 0.00 8.49 0.00 0.00 91.51

14:10:18 0 0.00 0.00 0.00 0.00 0.10 68.68 0.00 0.00 31.22

 

 

14:10:18 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:10:28 all 0.00 0.00 0.01 0.00 0.00 8.57 0.00 0.00 91.41

14:10:28 0 0.00 0.00 0.10 0.00 0.00 68.81 0.00 0.00 31.09

 

Ну и если скажем решим заюзать четыре первых ядра (неправильно)

GlobalNAT ~ # mpstat -P ALL 10

Linux 3.2.7-build-0060 (GlobalNAT) 03/02/12 _i686_ (8 CPU)

 

 

14:13:01 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle

14:13:11 all 0.00 0.00 0.05 0.00 0.01 15.23 0.00 0.00 84.70

14:13:11 0 0.00 0.00 0.00 0.00 0.00 30.17 0.00 0.00 69.83

14:13:11 1 0.00 0.00 0.00 0.00 0.00 31.20 0.00 0.00 68.80

14:13:11 2 0.00 0.00 0.00 0.00 0.10 31.24 0.00 0.00 68.65

14:13:11 3 0.00 0.00 0.10 0.00 0.00 30.52 0.00 0.00 69.38

 

Т.е. что мы получаем:

1 ядро - общая нагрузка на систему 9%

2 правильно сбалансированных ядра 10%

2 неправильно ... - 14%

4 неправильно ... - 16%

Падение производительности достаточно наглядно.

 

Правильная магическая строка в данном случае:

echo 5 >/proc/irq/65/smp_affinity

echo 5 >/sys/class/net/eth0/queues/rx-0/rps_cpus

 

Для академического интереса информация по нагрузке:

355Mbit 85Kpps транзитного траффика, 218K трансляций, 65K классов древовидного HTB шейпера

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


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

Join the conversation

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

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

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

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

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

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

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