загрузка проца

[KaYot 3 730]

  В 11.12.2011 в 15:03, Небесный сказал:

Ребята, попоробуйте шнягу, что вот советуют в этой статье.

http://habrahabr.ru/.../sysadm/110616/

 

А, теперь более подробно, на что я особо обратил внимание:

 

  Цитата

С хешами и без хешей

Собственно, про использование хешей статей уже написано немало – это не является “чем-то военным”. Можно обратиться к первоисточнику.

 

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

Собственно, использование хеш-фильтров абсолютно стандартная практика для построения шейперов, и обязательно при > 200 абонентов. При линейном просмотре для 5-10 тыс адресов загнется любое самое крутое железо на смешном трафике, с хешами у меня выходит 800мбит с 1000+ ppp сессий и 10% загрузкой на ядро. Т.е. сервер осилит столько, сколько влезет в интерфейсы.

[DarkSpider 36]

абсолютно согласен с KaYot.

Правила iptables уже заменены списками - выиграш коллосальный.

Кто-нибудь может привести пару примеров хеш-списков для tc ?

[arty777 15]

Парни , как лечить?

 

# 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]

Вывод iptables -nL -t nat интереснее. NAT сильнее нагружает.

Еще есть мнение что FreeBSD для задач маршрутизации рулит больше.

[arty777 15]

Я ж говорил , никаких функций кроме вебсервера

 

 

# 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 730]

cat /proc/interrupts в студию. Ну и top не помешает.

Сейчас похоже сетевка грузит одно ядро.

 

Сходу можно попробовать -j NOTRACK в iptables заюзать, при большом трафике профит может быть многократный.

[madf 279]

  В 19.07.2012 в 18:14, arty777 сказал:

Я ж говорил , никаких функций кроме вебсервера

...

Тогда каким боком тут тема про stg?

[nightfly 1 245]

  Цитата

Тогда каким боком тут тема про stg?

тут принято плакаться

 

2 arty777

  Цитата

траффика на вход 400 мегабайт (не мегабит) на исход столько же

А в винт случайно не уткнулись? Ммап, сендфайл у апачей врублены? Если нгинкс - то нопуш/ноудилай? Ну и акцепт фильтра в общем случае.

 

Если серьезно - а сколько вобще векторов прерываний у самих карточек? В вашем случае их явно должно быть в районе ~4-8 на каждую голову, итого 16-32 прерываний. Есть очень некислый шанс не добиться адекватной утилизации их возможностей на 4-х то ядрах.

 

ЗЫж ничерта не понимаю в этих ваших линуксах. Но прежде всего банально посмотрел бы

# procstat -a -t

и

# vmstat -z

с

# vmstat -i

Аналоги думаю имеются

[arty777 15]

Про прирывания я уже писал . что ручками разбросал по ядрам , но все-же:

 

  Показать содержимое

 

# 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]

Судя по TIME для ksoftirqd у вас все прерывания обрабатываются одним ядром. Сравните TIME для разных ksoftirqd - на лицо перекос. HyperThreading лучше не включать, но в вашем случае действительно не поможет.

Короче, у вас проблема с балансировкой прерываний. Думаю, "ручками раскидать" у вас не получилось. Как делали?

И к стати, самое интересное - cat /proc/interrupts - не показывает

[arty777 15]

А как это вы определили что ручками рампределить не получилось? я к пимеру # 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]

  В 20.07.2012 в 07:20, arty777 сказал:

А как это вы определили что ручками рампределить не получилось? я к пимеру # cat /proc/interrupts вижу каунты прерываний на разные ядра расбрасываются .

...

Ну я вашего cat /proc/interrupts так и не увидел, там картинка которая не грузится.

А определил просто - по времени работы ksoftirqd. Один работает, все остальные простаивают.

Ну и было бы интересно посмотреть top при пиковой нагрузке, сейчас я ничего особенного кроме ksoftirqd не вижу.

[arty777 15]

Вечером топ покажу . Ниче там примечательного . процесы нгиникса жрут 65% ЦП и все. При траффе >400 мегабайт ksoftirqd начинает хавать 50% цпу и трафф снижается , снизился - ksoftirqd отпал в 0% цпу .

 

Есть ли альтернатива irqbalance ?

 

Кастомные более производительные дрова под сетевушки ? Которые не генерят столько прерываний к примеру ) Захочу вставить еще 1 сетевуху 4-х головую , ваще отстой будет . Люди ж наверняка как-то живут на 10G ...

 

 

PS прилепил картинку вложением

[arty777 15]

Попробую апнуть дрова на 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]

Правда я никогда не ставил ручкам и дрова )) Че-то опгуглил , ниче кроме десктопной убунты с графич интерфейсом не нашет , дайте плиз ссыль на мануал по ручной установке дров для сетевух , вдруг кто знает ...

[madf 279]

Да там, по идее, проблем никаких. Нужны исходники ядра. Потом собирается модуль из новой версии дров и загружается через modprobe. Если все в порядке - кидаем его вместо старого в /lib/modules/...

ksoftirqd начинает работать когда ядро не успевает обрабатывать прерывания и ставит их в очередь.

Люди живут с 10G при маршрутизации, а у вас все-таки web-сервер. Немножко другие задачи, более тяжеловесные. Не пробовали оптимизировать nginx, сайт или раскидать его задачи на несколько серваков?

[arty777 15]

Да , я уже увидел . там подробный мануал с дровами идет )) Пробовал все оптимизировать . Нгиникс в частности . Ладно . дрова поменяю , отпишу .

[KaYot 3 730]

Судя по топу у вас таки вся загрузка от сети идет на 0 ядро. Об этом четко говорит строчка '57.9%si'. На остальных ядрах soft interrupts тоже есть, но в значительно меньшем количестве.

Может LACP неправильно работает, может IGB не умеет правильно балансировать при LACP.

Пробовали прерывания раскидать как ff на каждый вектор?

[arty777 15]

  В 20.07.2012 в 09:35, KaYot сказал:

Пробовали прерывания раскидать как ff на каждый вектор?

http://local.com.ua/..._80#entry329250

Вы это имеете ввиду?

 

Действительно нагрузка на 0-е ядро самая высокая , че-то ранее не замечал ... , вот скрин топа еще , за траффика уже 300/300 мегабайт . Как определить какой процесс какое ядро конкретно нагружает?

[KaYot 3 730]

Загрузка от nginx'ов это полностью понятно и можете на нее не смотреть. Оно само раскидается по свободным ядрам. Проблема именно в обработке трафика сетевкой, смотреть нужно в топе на колонку si(soft interrupts).

В списке процессов этого нет!!

[arty777 15]

Пошаманил . удалось добится следующей картины:

 

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 730]

Ну вот где-то так и должно быть, но с учетом того что сейчас часть ресурсов улетает впустую(все прерывания на все ядра не есть хорошо). Нужно играться с прибитием, подбирая номер ядра для лучшей сбалансированности.

Результат всегда можно увидеть в cat /proc/interrupts, при правильной настройке число прерываний на нужных ядрах будет расти примерно равномерно.

[arty777 15]

Планирую на днях вырубить гипегтрейдинг , и более тщательно прерывания сетевух раскинуть , смотреть удобно так:

watch cat /proc/interrupts

[KaYot 3 730]

o_O А у вас включен HT? А ядер сколько реально, 4?

Тогда все просто - выключайте нафиг, драйвер IGB грузите без поддержки векторов( у вас как раз 4 интерфейса на 4 ядра) - будет быстро и просто.

[arty777 15]

ядер реально 4 , HT вырублю на днях ...

  Цитата

драйвер IGB грузите без поддержки векторов

С этого места поподробнее .... )) Как ? Зачем? Последствия?