Jump to content
Калькуляторы

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

Роутер/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 и готовить второй рутер, или все же есть что еще покрутить?

Edited by AlKov

Share this post


Link to post
Share on other sites

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

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

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

Edited by AlKov

Share this post


Link to post
Share on other sites

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

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

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

 

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

У Вас входящий трафик на 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

Share this post


Link to post
Share on other sites

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

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.. Ну никак не укладывается, мозг вскипел. :)

Share this post


Link to post
Share on other sites

Я так понимаю, у вас 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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

Вряд ли.

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

16_45.jpg

Share this post


Link to post
Share on other sites

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

16_45.jpg

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

Share this post


Link to post
Share on other sites

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

Например, увеличить кол-во очередей до 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)?

Edited by AlKov

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Машинка, относительно старенькая двухкотловая, процы 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 шейпера

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this