KaYot 3 711 Опубліковано: 2011-12-11 18:50:53 Share Опубліковано: 2011-12-11 18:50:53 Ребята, попоробуйте шнягу, что вот советуют в этой статье. http://habrahabr.ru/.../sysadm/110616/ А, теперь более подробно, на что я особо обратил внимание: С хешами и без хешей Собственно, про использование хешей статей уже написано немало – это не является “чем-то военным”. Можно обратиться к первоисточнику. Особо времени небыло вчитываться в статью, но думаю уголек к размышлению подкинул, был бы рад, если бы ребята нашли выход. Собственно, использование хеш-фильтров абсолютно стандартная практика для построения шейперов, и обязательно при > 200 абонентов. При линейном просмотре для 5-10 тыс адресов загнется любое самое крутое железо на смешном трафике, с хешами у меня выходит 800мбит с 1000+ ppp сессий и 10% загрузкой на ядро. Т.е. сервер осилит столько, сколько влезет в интерфейсы. Ссылка на сообщение Поделиться на других сайтах
DarkSpider 36 Опубліковано: 2011-12-11 18:55:06 Share Опубліковано: 2011-12-11 18:55:06 абсолютно согласен с KaYot. Правила iptables уже заменены списками - выиграш коллосальный. Кто-нибудь может привести пару примеров хеш-списков для tc ? Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-19 13:13:08 Share Опубліковано: 2012-07-19 13:13:08 Парни , как лечить? # uname -a Linux giant 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Xeon E3-1200 Processor - 4 ядра 12 гиг озу Intel Corporation 82576 Gigabit Network Connection (rev 01) - 4 х портовая гигиабитная карта , траффика на вход 400 мегабайт (не мегабит) на исход столько же . # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination машинка тупой вебсервер , не более . Когда траффа чуток даже больше чем 400 , начинает умирать проц от процесса ksoftirqd/0 , который прерывания раскидывает , распредилил прерывания ручками на разные ядра , не помогает , дрова с napi , igb . Что делать - непонятно . LACP , Хелп !! PS интересно . как люди с 10G живут ... Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2012-07-19 13:47:40 Share Опубліковано: 2012-07-19 13:47:40 Вывод iptables -nL -t nat интереснее. NAT сильнее нагружает. Еще есть мнение что FreeBSD для задач маршрутизации рулит больше. Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-19 18:14:18 Share Опубліковано: 2012-07-19 18:14:18 Я ж говорил , никаких функций кроме вебсервера # iptables -nL -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2012-07-19 18:39:13 Share Опубліковано: 2012-07-19 18:39:13 cat /proc/interrupts в студию. Ну и top не помешает. Сейчас похоже сетевка грузит одно ядро. Сходу можно попробовать -j NOTRACK в iptables заюзать, при большом трафике профит может быть многократный. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2012-07-19 19:04:47 Share Опубліковано: 2012-07-19 19:04:47 Я ж говорил , никаких функций кроме вебсервера ... Тогда каким боком тут тема про stg? Ссылка на сообщение Поделиться на других сайтах
nightfly 1 241 Опубліковано: 2012-07-19 20:28:36 Share Опубліковано: 2012-07-19 20:28:36 Тогда каким боком тут тема про stg? тут принято плакаться 2 arty777 траффика на вход 400 мегабайт (не мегабит) на исход столько же А в винт случайно не уткнулись? Ммап, сендфайл у апачей врублены? Если нгинкс - то нопуш/ноудилай? Ну и акцепт фильтра в общем случае. Если серьезно - а сколько вобще векторов прерываний у самих карточек? В вашем случае их явно должно быть в районе ~4-8 на каждую голову, итого 16-32 прерываний. Есть очень некислый шанс не добиться адекватной утилизации их возможностей на 4-х то ядрах. ЗЫж ничерта не понимаю в этих ваших линуксах. Но прежде всего банально посмотрел бы # procstat -a -t и # vmstat -z с # vmstat -i Аналоги думаю имеются Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 06:38:00 Share Опубліковано: 2012-07-20 06:38:00 Про прирывания я уже писал . что ручками разбросал по ядрам , но все-же: # cat /proc/interrupts Гипертрейдинг не выключал , думаю особо не поможет его отключение (( По состоянию на утро (далеко не пик нагрузки): TOP Tasks: 148 total, 2 running, 146 sleeping, 0 stopped, 0 zombie Cpu0 : 3.1%us, 10.0%sy, 0.0%ni, 29.0%id, 0.0%wa, 0.0%hi, 57.9%si, 0.0%st Cpu1 : 2.1%us, 8.4%sy, 0.0%ni, 83.6%id, 0.0%wa, 0.0%hi, 5.9%si, 0.0%st Cpu2 : 1.4%us, 4.6%sy, 0.0%ni, 88.9%id, 0.0%wa, 0.0%hi, 5.0%si, 0.0%st Cpu3 : 1.1%us, 5.1%sy, 0.0%ni, 85.1%id, 0.0%wa, 0.0%hi, 8.7%si, 0.0%st Cpu4 : 1.1%us, 2.6%sy, 0.0%ni, 91.9%id, 0.0%wa, 0.0%hi, 4.4%si, 0.0%st Cpu5 : 2.2%us, 3.6%sy, 0.0%ni, 88.5%id, 0.0%wa, 0.0%hi, 5.7%si, 0.0%st Cpu6 : 1.1%us, 4.4%sy, 0.0%ni, 81.6%id, 0.0%wa, 0.0%hi, 12.9%si, 0.0%st Cpu7 : 2.2%us, 5.1%sy, 0.0%ni, 80.9%id, 0.0%wa, 0.0%hi, 11.8%si, 0.0%st Mem: 12268612k total, 3592696k used, 8675916k free, 259192k buffers Swap: 12271612k total, 0k used, 12271612k free, 922192k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 www-data 20 0 73972 32m 1220 S 14 0.3 302:42.10 nginx2 7215 www-data 20 0 70564 28m 1220 S 13 0.2 299:44.53 nginx2 7218 www-data 20 0 75496 33m 1220 S 11 0.3 303:22.56 nginx2 7221 www-data 20 0 77384 35m 1220 S 11 0.3 300:59.74 nginx2 7220 www-data 20 0 76504 34m 1220 S 10 0.3 306:30.60 nginx2 7216 www-data 20 0 66464 24m 1220 R 10 0.2 300:11.36 nginx2 7217 www-data 20 0 67800 26m 1220 S 10 0.2 300:56.24 nginx2 7219 www-data 20 0 73204 31m 1220 S 9 0.3 300:45.42 nginx2 7525 www-data 20 0 46548 5016 920 S 5 0.0 68:05.48 nginx3 7523 www-data 20 0 47016 5624 916 S 4 0.0 68:58.23 nginx3 7522 www-data 20 0 47136 5744 916 S 3 0.0 70:08.70 nginx3 7520 www-data 20 0 48496 7104 916 S 2 0.1 71:50.83 nginx3 7527 www-data 20 0 46124 4700 920 S 2 0.0 70:38.58 nginx3 7521 www-data 20 0 48124 6732 916 S 2 0.1 71:00.18 nginx3 7524 www-data 20 0 45720 4284 920 S 2 0.0 70:04.11 nginx3 7526 www-data 20 0 47120 5592 916 S 2 0.0 69:38.56 nginx3 1635 root 20 0 15972 740 544 S 0 0.0 19:04.19 irqbalance 10396 root 20 0 11144 1248 924 S 0 0.0 2:40.12 bmon 11476 www-data 20 0 302m 3240 1316 S 0 0.0 0:01.35 nginx 11479 www-data 20 0 302m 3192 1436 S 0 0.0 0:03.69 nginx 11480 www-data 20 0 302m 2792 1328 S 0 0.0 0:03.38 nginx 11501 root 20 0 0 0 0 S 0 0.0 0:00.77 kworker/1:0 11506 root 20 0 0 0 0 S 0 0.0 0:01.90 kworker/0:0 11513 root 20 0 0 0 0 S 0 0.0 0:00.16 kworker/5:2 11527 root 20 0 0 0 0 S 0 0.0 0:00.24 kworker/7:2 11533 root 20 0 17332 1336 960 R 0 0.0 0:00.02 top 1 root 20 0 24444 2380 1332 S 0 0.0 0:01.45 init 2 root 20 0 0 0 0 S 0 0.0 0:01.35 kthreadd 3 root 20 0 0 0 0 S 0 0.0 108:48.58 ksoftirqd/0 6 root RT 0 0 0 0 S 0 0.0 30882:00 migration/0 7 root RT 0 0 0 0 S 0 0.0 5:05.02 watchdog/0 8 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1 10 root 20 0 0 0 0 S 0 0.0 0:23.32 ksoftirqd/1 12 root RT 0 0 0 0 S 0 0.0 0:15.88 watchdog/1 13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2 15 root 20 0 0 0 0 S 0 0.0 0:23.30 ksoftirqd/2 16 root RT 0 0 0 0 S 0 0.0 0:15.04 watchdog/2 17 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3 19 root 20 0 0 0 0 S 0 0.0 0:22.65 ksoftirqd/3 20 root RT 0 0 0 0 S 0 0.0 0:14.94 watchdog/3 21 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/4 23 root 20 0 0 0 0 S 0 0.0 0:20.14 ksoftirqd/4 24 root RT 0 0 0 0 S 0 0.0 0:14.49 watchdog/4 В винт и прочее , не уткнулись . Если серьезно - а сколько вобще векторов прерываний у самих карточек? ой, а как это проверить? Как узнать? y# vmstat -Sm 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 9446 265 957 0 0 0 19 2 2 3 33 63 0 0 0 0 9459 265 957 0 0 0 0 147268 45249 2 20 79 0 0 0 0 9463 265 957 0 0 0 0 150416 47691 2 20 78 0 1 0 0 9470 265 957 0 0 0 0 146319 45333 2 19 79 0 1 0 0 9482 265 957 0 0 0 0 148432 45725 2 19 79 0 0 0 0 9249 265 957 0 0 0 336 179979 87304 2 25 72 1 cat /proc/stat cpu 48093716 13068 121050720 903082116 2786842 245080 349847358 0 0 0 cpu0 6347214 1305 16514787 82025883 692608 23569 76084445 0 0 0 cpu1 6770444 2727 16891737 115470024 490415 26126 40200938 0 0 0 cpu2 6683928 1996 16651635 116289728 538886 27407 39350570 0 0 0 cpu3 6253113 3019 15595796 121984348 500645 26598 36259284 0 0 0 cpu4 5631444 633 14160269 116905769 131050 36002 38446137 0 0 0 cpu5 5790492 1395 14597703 110402926 107181 36572 44976839 0 0 0 cpu6 5546282 1503 13921342 116656496 134814 35931 39191841 0 0 0 cpu7 5070794 485 12717447 123346937 191239 32872 35337300 0 0 0 intr 42174504102 6348 872 0 0 0 0 0 0 1 0 0 0 0 0 0 0 28 0 0 0 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 40931252 0 0 0 0 0 0 0 0 0 0 3 1787352229 1940984590 1820152785 1818182976 1847385984 1873664542 1878894987 1808150942 21 3 1831208067 1797536682 1886222225 1838053569 1429884816 1416607521 1469825756 1484254547 11 1898464781 1905165307 1825372504 1440892153 1407228263 1479387037 1393852939 1481439026 3 1381011292 1740253332 1466596170 1882210557 1489470234 1466632139 1481783020 1394555853 13 29 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ctxt 159325323901 btime 1340876925 processes 366169 procs_running 3 procs_blocked 0 softirq 25925505375 0 2565727632 1073281646 2910779777 35816616 0 761 646516520 4098699 1509414540 В общем, великая проблема в распределении прерываний , проц апгреднуть не могу , на более многоядерный . Надо выкручиватся из того что есть. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2012-07-20 07:10:30 Share Опубліковано: 2012-07-20 07:10:30 Судя по TIME для ksoftirqd у вас все прерывания обрабатываются одним ядром. Сравните TIME для разных ksoftirqd - на лицо перекос. HyperThreading лучше не включать, но в вашем случае действительно не поможет. Короче, у вас проблема с балансировкой прерываний. Думаю, "ручками раскидать" у вас не получилось. Как делали? И к стати, самое интересное - cat /proc/interrupts - не показывает Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 07:20:03 Share Опубліковано: 2012-07-20 07:20:03 А как это вы определили что ручками рампределить не получилось? я к пимеру # cat /proc/interrupts вижу каунты прерываний на разные ядра расбрасываются . Делал так: ПРЕРЫВАНИЯ CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 01 02 04 08 10 20 40 80 echo 01 > /proc/irq/60/smp_affinity echo 02 > /proc/irq/61/smp_affinity echo 04 > /proc/irq/62/smp_affinity echo 08 > /proc/irq/63/smp_affinity echo 10 > /proc/irq/64/smp_affinity echo 20 > /proc/irq/65/smp_affinity echo 40 > /proc/irq/66/smp_affinity echo 80 > /proc/irq/67/smp_affinity echo 01 > /proc/irq/68/smp_affinity echo 02 > /proc/irq/70/smp_affinity echo 04 > /proc/irq/71/smp_affinity echo 08 > /proc/irq/72/smp_affinity echo 10 > /proc/irq/73/smp_affinity echo 20 > /proc/irq/74/smp_affinity echo 40 > /proc/irq/75/smp_affinity echo 80 > /proc/irq/76/smp_affinity echo 01 > /proc/irq/77/smp_affinity echo 02 > /proc/irq/78/smp_affinity echo 04 > /proc/irq/79/smp_affinity echo 08 > /proc/irq/80/smp_affinity echo 10 > /proc/irq/81/smp_affinity echo 20 > /proc/irq/82/smp_affinity echo 40 > /proc/irq/83/smp_affinity echo 80 > /proc/irq/84/smp_affinity echo 01 > /proc/irq/85/smp_affinity echo 02 > /proc/irq/86/smp_affinity echo 04 > /proc/irq/87/smp_affinity echo 08 > /proc/irq/88/smp_affinity echo 10 > /proc/irq/89/smp_affinity echo 20 > /proc/irq/90/smp_affinity echo 40 > /proc/irq/91/smp_affinity echo 80 > /proc/irq/92/smp_affinity echo 01 > /proc/irq/93/smp_affinity echo 02 > /proc/irq/94/smp_affinity echo 04 > /proc/irq/95/smp_affinity echo 08 > /proc/irq/96/smp_affinity Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2012-07-20 07:40:19 Share Опубліковано: 2012-07-20 07:40:19 А как это вы определили что ручками рампределить не получилось? я к пимеру # cat /proc/interrupts вижу каунты прерываний на разные ядра расбрасываются . ... Ну я вашего cat /proc/interrupts так и не увидел, там картинка которая не грузится. А определил просто - по времени работы ksoftirqd. Один работает, все остальные простаивают. Ну и было бы интересно посмотреть top при пиковой нагрузке, сейчас я ничего особенного кроме ksoftirqd не вижу. Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 08:23:54 Share Опубліковано: 2012-07-20 08:23:54 Вечером топ покажу . Ниче там примечательного . процесы нгиникса жрут 65% ЦП и все. При траффе >400 мегабайт ksoftirqd начинает хавать 50% цпу и трафф снижается , снизился - ksoftirqd отпал в 0% цпу . Есть ли альтернатива irqbalance ? Кастомные более производительные дрова под сетевушки ? Которые не генерят столько прерываний к примеру ) Захочу вставить еще 1 сетевуху 4-х головую , ваще отстой будет . Люди ж наверняка как-то живут на 10G ... PS прилепил картинку вложением Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 08:30:20 Share Опубліковано: 2012-07-20 08:30:20 Попробую апнуть дрова на http://sourceforge.net/projects/e1000/files/igb%20stable/ последнюю версию У меня # ethtool -i eth1 driver: igb version: 3.2.10-k firmware-version: 1.5-1 bus-info: 0000:04:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 08:42:22 Share Опубліковано: 2012-07-20 08:42:22 Правда я никогда не ставил ручкам и дрова )) Че-то опгуглил , ниче кроме десктопной убунты с графич интерфейсом не нашет , дайте плиз ссыль на мануал по ручной установке дров для сетевух , вдруг кто знает ... Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2012-07-20 09:17:29 Share Опубліковано: 2012-07-20 09:17:29 Да там, по идее, проблем никаких. Нужны исходники ядра. Потом собирается модуль из новой версии дров и загружается через modprobe. Если все в порядке - кидаем его вместо старого в /lib/modules/... ksoftirqd начинает работать когда ядро не успевает обрабатывать прерывания и ставит их в очередь. Люди живут с 10G при маршрутизации, а у вас все-таки web-сервер. Немножко другие задачи, более тяжеловесные. Не пробовали оптимизировать nginx, сайт или раскидать его задачи на несколько серваков? Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 09:28:52 Share Опубліковано: 2012-07-20 09:28:52 Да , я уже увидел . там подробный мануал с дровами идет )) Пробовал все оптимизировать . Нгиникс в частности . Ладно . дрова поменяю , отпишу . Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2012-07-20 09:35:02 Share Опубліковано: 2012-07-20 09:35:02 Судя по топу у вас таки вся загрузка от сети идет на 0 ядро. Об этом четко говорит строчка '57.9%si'. На остальных ядрах soft interrupts тоже есть, но в значительно меньшем количестве. Может LACP неправильно работает, может IGB не умеет правильно балансировать при LACP. Пробовали прерывания раскидать как ff на каждый вектор? Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 10:36:11 Share Опубліковано: 2012-07-20 10:36:11 Пробовали прерывания раскидать как ff на каждый вектор? http://local.com.ua/..._80#entry329250 Вы это имеете ввиду? Действительно нагрузка на 0-е ядро самая высокая , че-то ранее не замечал ... , вот скрин топа еще , за траффика уже 300/300 мегабайт . Как определить какой процесс какое ядро конкретно нагружает? Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2012-07-20 10:41:27 Share Опубліковано: 2012-07-20 10:41:27 Загрузка от nginx'ов это полностью понятно и можете на нее не смотреть. Оно само раскидается по свободным ядрам. Проблема именно в обработке трафика сетевкой, смотреть нужно в топе на колонку si(soft interrupts). В списке процессов этого нет!! Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 11:58:00 Share Опубліковано: 2012-07-20 11:58:00 Пошаманил . удалось добится следующей картины: top - 14:56:44 up 22 days, 2:07, 3 users, load average: 1.66, 1.57, 1.28 Tasks: 149 total, 2 running, 147 sleeping, 0 stopped, 0 zombie Cpu0 : 6.1%us, 12.5%sy, 0.0%ni, 29.5%id, 0.0%wa, 0.0%hi, 51.9%si, 0.0%st Cpu1 : 3.9%us, 12.6%sy, 0.0%ni, 38.2%id, 0.0%wa, 0.0%hi, 45.3%si, 0.0%st Cpu2 : 4.4%us, 9.9%sy, 0.0%ni, 51.5%id, 0.0%wa, 0.0%hi, 34.2%si, 0.0%st Cpu3 : 5.1%us, 13.0%sy, 0.0%ni, 53.6%id, 0.0%wa, 0.0%hi, 32.3%si, 0.0%st Cpu4 : 6.2%us, 10.5%sy, 0.0%ni, 40.6%id, 0.0%wa, 0.0%hi, 42.8%si, 0.0%st Cpu5 : 4.0%us, 11.4%sy, 0.0%ni, 44.5%id, 0.0%wa, 0.0%hi, 40.1%si, 0.0%st Cpu6 : 2.8%us, 11.3%sy, 0.0%ni, 34.3%id, 0.0%wa, 0.0%hi, 51.6%si, 0.0%st Cpu7 : 3.2%us, 9.6%sy, 0.0%ni, 45.7%id, 0.0%wa, 0.0%hi, 41.4%si, 0.0%st Mem: 12268612k total, 6445188k used, 5823424k free, 259216k buffers Swap: 12271612k total, 0k used, 12271612k free, 1006040k cached вроде лучше . Посмотрим дальше как будет оно себя вести Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2012-07-20 12:14:19 Share Опубліковано: 2012-07-20 12:14:19 Ну вот где-то так и должно быть, но с учетом того что сейчас часть ресурсов улетает впустую(все прерывания на все ядра не есть хорошо). Нужно играться с прибитием, подбирая номер ядра для лучшей сбалансированности. Результат всегда можно увидеть в cat /proc/interrupts, при правильной настройке число прерываний на нужных ядрах будет расти примерно равномерно. Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 12:19:15 Share Опубліковано: 2012-07-20 12:19:15 Планирую на днях вырубить гипегтрейдинг , и более тщательно прерывания сетевух раскинуть , смотреть удобно так: watch cat /proc/interrupts Ссылка на сообщение Поделиться на других сайтах
KaYot 3 711 Опубліковано: 2012-07-20 12:22:02 Share Опубліковано: 2012-07-20 12:22:02 o_O А у вас включен HT? А ядер сколько реально, 4? Тогда все просто - выключайте нафиг, драйвер IGB грузите без поддержки векторов( у вас как раз 4 интерфейса на 4 ядра) - будет быстро и просто. Ссылка на сообщение Поделиться на других сайтах
arty777 15 Опубліковано: 2012-07-20 12:41:23 Share Опубліковано: 2012-07-20 12:41:23 ядер реально 4 , HT вырублю на днях ... драйвер IGB грузите без поддержки векторов С этого места поподробнее .... )) Как ? Зачем? Последствия? Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас