AlKov Опубликовано 29 февраля, 2012 (изменено) · Жалоба Роутер/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 и готовить второй рутер, или все же есть что еще покрутить? Изменено 29 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 29 февраля, 2012 (изменено) · Жалоба У Вас входящий трафик на eth2 в 4 раза выше входящего трафика на eth3, соответственно, нагрузка на ядра под eth2 выше. Увеличьте число очередей на платах, либо включайте RPS. Кстати трафик у Вас относительно небольшой - фильтры построены неоптимально? Какой проц? Изменено 29 февраля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 29 февраля, 2012 (изменено) · Жалоба У Вас входящий трафик на eth2 в 4 раза выше входящего трафика на eth3, соответственно, нагрузка на ядра под eth2 выше. Увеличьте число очередей на платах, либо включайте RPS. Ну так входящий на eth3 - это исходящий от клиентов, а входящий на eth2 - соотв. исходящий к клиентам. Вроде как нормально? Кстати, а как увеличить число очередей и каким образом их потом раскидать на 4 ядра? Кстати трафик у Вас относительно небольшой - фильтры построены неоптимально? Какой проц? Какие фильтры Вы имеете ввиду? iptables? И в чем может заключаться неоптимальность - в порядке следования правил? Проц - два Intel Xeon E5503 2.00GHz (в первом посту озвучивал). Изменено 29 февраля, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 29 февраля, 2012 (изменено) · Жалоба В одной из веток тов. kayot (прошу прощения, если ник переврал) подсоветовал, что делать в случаях, когда igb отказывается создавать нужное число очередей автоматически: в общем случае достаточно создать файлик etc/modprobe.d/igb.conf со строчкой options igb RSS=4,4,4,4 Можно глянуть на документацию по опции RSS в igb еще, там детали. Что же до фильтров - посмотрите, может быть слишком много правил подряд идёт, и их можно как-то соптимизировать, разбив на "ветки исполнения". Конкретно Вашей ситуации не знаю, конечно, просто предположение. Изменено 29 февраля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 29 февраля, 2012 · Жалоба а можно хоть узнать сколько там правил ?? ато вдруг там тыща юзеров и для каждого создается запись НАТ и запись разрешения форварда ? )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_INF_ Опубликовано 1 марта, 2012 · Жалоба У Вас входящий трафик на 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 1 марта, 2012 · Жалоба из собственного опыта, четырехядерный 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.. Ну никак не укладывается, мозг вскипел. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_INF_ Опубликовано 1 марта, 2012 · Жалоба Я так понимаю, у вас 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 автор данного скрипта присутствует на данном форуме Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 1 марта, 2012 · Жалоба Учитывайте локализацию кеша. Т.е. у ядер может быть общий кеш, плюс локализация по процессору и т.п. Я скоро постараюсь написать на эту тему небольшую статейку, если будет время. Если не будет - выкину то, что нарыл и кто-то напишет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 1 марта, 2012 · Жалоба Учитывайте локализацию кеша. Т.е. у ядер может быть общий кеш, плюс локализация по процессору и т.п. Тяжеловатая задачка для меня, если не сказать хуже. :) Я скоро постараюсь написать на эту тему небольшую статейку, если будет время. Если не будет - выкину то, что нарыл и кто-то напишет :) А основные постулаты можно сейчас увидеть? P.S. Кстати, а вообще, есть ли какой смысл увеличивать кол-во очередей до 8 при наличии 4-х ядер? Не пойму, что это может дать? Все равно одно ядро будет вместо одной очереди обслуживать две, т.е. соотв. увеличивается как загрузка ядра, так и время обработки прерывания. Да, и еще - насчет "обратного" соотношение загрузки CPU и прерываний есть какие-либо соображения? Что-то беспокоит меня этот Гондурас. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_INF_ Опубликовано 1 марта, 2012 · Жалоба Учитывайте локализацию кеша. Т.е. у ядер может быть общий кеш, плюс локализация по процессору и т.п. Я скоро постараюсь написать на эту тему небольшую статейку, если будет время. Если не будет - выкину то, что нарыл и кто-то напишет :) Здесь же один процессор :) Если бы было два процессора, то имело бы смысл прерывания от eth0 кинуть на ядра первого процессора, прерывания от eth1 раскидать по ядрам второго. На данном форуме видел shell скрипт который делает подобное. Кидайте что нарыли, можем совместно статью оформить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 1 марта, 2012 · Жалоба Здесь же один процессор :) Если бы было два процессора, то имело бы смысл прерывания от eth0 кинуть на ядра первого процессора, прерывания от eth1 раскидать по ядрам второго. На данном форуме видел shell скрипт который делает подобное. Это у Вас один, а у меня два! ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 1 марта, 2012 · Жалоба Если бы было два процессора, то имело бы смысл прерывания от eth0 кинуть на ядра первого процессора, прерывания от eth1 раскидать по ядрам второго. Вряд ли. Обмен данными будет проходить через кэш L1 или даже через ОЗУ, из-за этого проигрыш скорости будет сильнее, чем ускорение из-за количества ядер. На данном форуме видел shell скрипт который делает подобное. http://forum.nag.ru/forum/index.php?showtopic=53404&view=findpost&p=459338 Это у Вас один, а у меня два! ;) Такая же бесполезная imho вещь на роутере, как hyperthreading. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 2 марта, 2012 · Жалоба Это у Вас один, а у меня два! ;) Такая же бесполезная imho вещь на роутере, как hyperthreading. Не в первый раз вижу, как ht называют бесполезной вещью на этом форуме. Расскажите, в чем бесполезность? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 2 марта, 2012 · Жалоба Не в первый раз вижу, как ht называют бесполезной вещью на этом форуме. Расскажите, в чем бесполезность? Конвейеры команд и блоки регистров разные, всё остальное общее. Из-за этого один из конвейеров почти всегда заблокирован. Плюс потери собственно на операциях блокировки. HT полезен только для сложных вычислений, у которых промежуточные данные помещаются в регистры (MISD в таксономии Флинна). Роутер - это скорее MIMD или даже SIMD. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 2 марта, 2012 · Жалоба Не в первый раз вижу, как ht называют бесполезной вещью на этом форуме. Расскажите, в чем бесполезность? Конвейеры команд и блоки регистров разные, всё остальное общее. Из-за этого один из конвейеров почти всегда заблокирован. Плюс потери собственно на операциях блокировки. HT полезен только для сложных вычислений, у которых промежуточные данные помещаются в регистры (MISD в таксономии Флинна). Роутер - это скорее MIMD или даже SIMD. А разве в шедьюлере ОС блокировок нет? Есть мнение, что переключение контекстов внутри аппаратного ядра будет все-таки побыстрее, чем переключение контекстов средствами ОС. Да и HT сейчас уже не тот, что прежде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 2 марта, 2012 (изменено) · Жалоба Открою секрет: аппаратное переключение контекстов на x86 уже давно не используется. Основная причина - сохраняет не всё состояние, регистров FPU в TSS никогда не было. Ну и в целом зачастую оно все-таки медленнее софтового переключения контекста - поскольку не всегда надо сохранять всё целиком, смотря что за вызов. А в x86_64 архитектуре аппаратный context switch вообще отменили, оставив от TSS минимально необходимый набор параметров. Изменено 2 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 2 марта, 2012 · Жалоба Открою секрет: аппаратное переключение контекстов на x86 уже давно не используется. Основная причина - сохраняет не всё состояние, регистров FPU в TSS никогда не было. Ну и в целом медленнее софтового переключения контекста - поскольку не всегда надо сохранять всё целиком, смотря что за вызов. А в x86_64 архитектуре аппаратный context switch вообще отменили, оставив от TSS минимально необходимый набор параметров. В данном случае под контекстами я подразумеваю общую инфраструктуру, используемую тредами: Другие ресурсы можно совместно использовать двумя потоками, сюда входит вся логика внеочередного выполнения (буфер изменения порядка инструкций/instruction reorder buffer, исполнительные блоки и кэш). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 2 марта, 2012 · Жалоба А разве в шедьюлере ОС блокировок нет? Есть мнение, что переключение контекстов внутри аппаратного ядра будет все-таки побыстрее, чем переключение контекстов средствами ОС. Ну Вы и загнули. Вообще-то Карл Маркс и Фридрих Энгельс - это не муж и жена, а четыре совершенно разных человека. Блокировки в планировщике ОС и в ядре процессора используются для разных вещей. Переключение контекстов на маршрутизаторе не используется вообще - все выполняется в ядре (про minix и divert-сокеты в другой раз). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 2 марта, 2012 · Жалоба Переключение контекстов на маршрутизаторе не используется вообще - все выполняется в ядре (про minix и divert-сокеты в другой раз). Т.е. вы хотите сказать, что шедьюлинг средствами ОС двух ядерных процессов на одном физическом ядре будет выполняться быстрее, чем шедьюлинг средствами процессора двух процессов, разложенных по двум логическим ядрам одного физического ядра? Заранее прошу прощения за сумбурность изложения, я с такими тонкими материями не работал. Меня интересуют именно возможные ограничения SMT в современных интелах. Во что упрется? И когда? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 2 марта, 2012 · Жалоба Т.е. вы хотите сказать, что шедьюлинг средствами ОС двух ядерных процессов на одном физическом ядре будет выполняться быстрее, чем шедьюлинг средствами процессора двух процессов, разложенных по двум логическим ядрам одного физического ядра? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 2 марта, 2012 · Жалоба Т.е. вы хотите сказать, что шедьюлинг средствами ОС двух ядерных процессов на одном физическом ядре будет выполняться быстрее, чем шедьюлинг средствами процессора двух процессов, разложенных по двум логическим ядрам одного физического ядра? Во что упрется? И когда? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 2 марта, 2012 (изменено) · Жалоба Господа! А можно что-нибудь по теме? Например, увеличить кол-во очередей до 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)? Изменено 2 марта, 2012 пользователем AlKov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 2 марта, 2012 · Жалоба Блин, вы бы уже быстрее сами попробовали бы и сравнили результаты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 2 марта, 2012 · Жалоба Такс, подсказки, с примером: Машинка, относительно старенькая двухкотловая, процы E5440, Quad Core (Harpertown). Итого 8 ядер, без SMT. Визуально архитектуру смотрим здесь По сути два 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 шейпера Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...