[vadius]

Запарились уже. Спасайте.

 

В связи с увеличением канала (интернет,город) в январе был установлен новый сервер на граничный маршрутизатор с FreeBSD 8.1 (AMD64), потом обновлен до 8.2-Release (AMD64).

Железо такое:

Мать Intel S5520UR, два CPU Xeon E5620, памяти 8 Гб

две двухголовые (em) HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)

две встроенные (igb) 82575EB Gigabit Network Connection

 

На нем крутится bgp, ospf, dummynet, ssh, ipfw, dns. NATа - нет.

Firewall 90 правил, включая 22 pipe для шейпера.

 

Входящий трафик в пике: Интернет около 300Мбит(~50К пакетов), город 600-700Мбит (~90К пакетов). Город и интернет на разных каналах. Исходящий раза в полтора поменьше. Ошибок на интерфейсах нет. Шейпер висит на входящем из интернета.

 

Проблема в следующем:

Раз в неделю получаем kernel panic fatal trap 12 (current process = 12 (irq258:igb0:que 2) или (current process = 0 (em2 taskq)) и завис, пару раз была перезагрузка. Самое интересное, часто падает днем в то время когда нагрузка ниже средней. Пробовали драйвера от яндекса один черт. Убираешь тюнинг падает дня через 2-3.

 

Из тюнинга:

sysctl.conf

kern.ipc.nmbclusters=524288

kern.ipc.maxsockbuf=2097152

kern.ipc.somaxconn=32768

kern.maxfiles=204800

kern.maxfilesperproc=200000

net.inet.tcp.blackhole=2

net.inet.udp.blackhole=0

net.inet.tcp.drop_synfin=1

net.inet.tcp.syncookies=1

net.inet.tcp.recvspace=65536

net.inet.tcp.sendspace=65536

net.inet.icmp.drop_redirect=1

net.inet.icmp.icmplim=1000

net.inet.ip.dummynet.io_fast=1

net.inet.ip.dummynet.pipe_slot_limit=2048

net.inet.ip.fastforwarding=1

net.inet.ip.sourceroute=0

net.inet.ip.accept_sourceroute=0

net.inet.ip.intr_queue_maxlen=1000

kern.ipc.shm_use_phys=1

net.isr.direct=1

net.isr.direct_force=1

net.link.ether.inet.log_arp_movements=0

dev.igb.0.flow_control=0

dev.igb.1.flow_control=0

dev.em.X.rx_int_delay=1000

dev.em.X.tx_int_delay=1000

dev.em.X.rx_abs_int_delay=2000

dev.em.X.tx_abs_int_delay=2000

dev.em.X.rx_processing_limit=2000

dev.em.X.flow_control=0

 

loader.conf

net.isr.maxthreads=4

 

Из ядра все лишнее выброшено. Flowtable, polling отключен.

 

Вот top днем, когда нагрузка невысокая. В пике загрузки сервера CPU idle ~85%

top -SH

last pid: 39098; load averages: 0.44, 0.61, 0.56 up 0+23:34:55 15:01:39

163 processes: 9 running, 122 sleeping, 32 waiting

CPU: 0.0% user, 0.0% nice, 5.9% system, 1.1% interrupt, 93.0% idle

Mem: 370M Active, 510M Inact, 700M Wired, 272K Cache, 822M Buf, 6245M Free

Swap: 8192M Total, 8192M Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11 root 171 ki31 0K 128K CPU6 6 23.5H 100.00% {idle: cpu6}

11 root 171 ki31 0K 128K CPU5 5 23.4H 100.00% {idle: cpu5}

11 root 171 ki31 0K 128K RUN 4 23.4H 100.00% {idle: cpu4}

11 root 171 ki31 0K 128K CPU3 3 23.2H 100.00% {idle: cpu3}

11 root 171 ki31 0K 128K CPU1 1 23.1H 100.00% {idle: cpu1}

11 root 171 ki31 0K 128K CPU7 7 23.5H 99.66% {idle: cpu7}

11 root 171 ki31 0K 128K CPU2 2 17.6H 75.59% {idle: cpu2}

11 root 171 ki31 0K 128K CPU0 0 16.8H 71.88% {idle: cpu0}

0 root -68 0 0K 336K - 2 153:07 15.48% {em0 taskq}

0 root -68 0 0K 336K - 2 166:42 14.89% {em1 taskq}

0 root -68 0 0K 336K - 0 94:47 10.79% {em2 taskq}

0 root -68 0 0K 336K - 2 133:54 9.38% {em3 taskq}

12 root -68 - 0K 512K WAIT 1 18:30 3.56% {irq257: igb0:que}

0 root -68 0 0K 336K - 0 155:54 2.59% {dummynet}

0 root -68 0 0K 336K - 2 26:09 1.95% {igb0 que}

12 root -68 - 0K 512K WAIT 0 16:22 0.59% {irq256: igb0:que}

12 root -68 - 0K 512K WAIT 3 15:21 0.39% {irq259: igb0:que}

12 root -68 - 0K 512K WAIT 2 15:52 0.10% {irq258: igb0:que}

2173 root 44 0 144M 137M select 1 10:35 0.00% bgpd

12 root -32 - 0K 512K WAIT 4 6:54 0.00% {swi4: clock}

0 root 44 0 0K 336K sched 0 3:02 0.00% {swapper}

13 root -16 - 0K 16K - 4 2:28 0.00% yarrow

12 root -68 - 0K 512K WAIT 0 1:23 0.00% {irq261: igb1:que}

12 root -68 - 0K 512K WAIT 1 1:05 0.00% {irq262: igb1:que}

12 root -68 - 0K 512K WAIT 3 0:59 0.00% {irq264: igb1:que}

2196 root 44 0 24896K 6420K select 1 0:59 0.00% snmpd

12 root -68 - 0K 512K WAIT 2 0:54 0.00% {irq263: igb1:que}

0 root -68 0 0K 336K - 0 0:39 0.00% {igb1 que}

 

Если нужна какая информация пишите.

[Giga-Byte]

покажите правила фаерволла.

 

net.inet.ip.fastforwarding=1 выключить?

 

почти оффтоп, просто заметка:

loader.conf

net.isr.maxthreads=4

разве есть смысл при net.isr.direct=1

и

kern.ipc.nmbclusters=524288

kern.ipc.maxsockbuf=2097152

kern.ipc.somaxconn=32768

kern.maxfiles=204800

kern.maxfilesperproc=200000

kern.ipc.shm_use_phys=1

вернуть в базовые значения

Изменено 13 апреля, 2011 пользователем Giga-Byte

[vadius]

net.inet.ip.fastforwarding=1 был отключен до недавнего времени, сейчас включили для тестирования. Сервер умирает и так и так :(

 

net.isr.maxthreads=4 с net.isr.direct=1 смысла конечно нет, я оставил для того чтобы пробовать с net.isr.direct=0, но тогда загрузка проца растет и один черт виснет.

 

kern.ipc.nmbclusters=524288

kern.ipc.maxsockbuf=2097152

kern.ipc.somaxconn=32768

kern.maxfiles=204800

kern.maxfilesperproc=200000

kern.ipc.shm_use_phys=1

т.е убрать их из rc.conf?

 

00011 pipe 1 ip from any to 111.222.80.0/21 in via eth1

00011 pipe 2 ip from 111.222.80.0/21 to any out via eth1

00012 pipe 3 ip from any to 111.222.88.0/22 in via eth1

00012 pipe 4 ip from 111.222.88.0/22 to any out via eth1

00012 pipe 3 ip from any to 111.222.92.0/24 in via eth1

00012 pipe 4 ip from 111.222.92.0/24 to any out via eth1

00013 pipe 5 ip from any to 111.222.93.0/24 in via eth1

00013 pipe 6 ip from 111.222.93.0/24 to any out via eth1

00013 pipe 5 ip from any to 111.222.94.0/23 in via eth1

00013 pipe 6 ip from 111.222.94.0/23 to any out via eth1

00014 pipe 7 ip from any to 111.333.16.0/24 in via eth1

00014 pipe 8 ip from 111.333.16.0/24 to any out via eth1

00021 pipe 9 ip from any to 111.333.23.0/27 in via eth1

00021 pipe 10 ip from 111.333.23.0/27 to any out via eth1

00022 pipe 11 ip from any to 111.333.23.32/27 in via eth1

00022 pipe 12 ip from 111.333.23.32/27 to any out via eth1

00023 pipe 13 ip from any to 111.333.23.64/27 in via eth1

00023 pipe 14 ip from 111.333.23.64/27 to any out via eth1

00024 pipe 15 ip from any to 111.333.23.96/27 in via eth1

00024 pipe 16 ip from 111.333.23.96/27 to any out via eth1

00031 pipe 13 ip from any to 111.333.23.192/27 in via eth1

00031 pipe 14 ip from 111.333.23.192/27 to any out via eth1

00100 allow ip from any to any via lo0

00200 deny ip from any to 127.0.0.0/8

00300 deny ip from 127.0.0.0/8 to any

01300 deny ip from any to 172.16.0.0/12 via eth1

01400 deny ip from 172.16.0.0/12 to any via eth1

01500 deny ip from any to 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4

01600 deny ip from 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any

01700 skipto 10000 ip from any to 111.333.23.192/27

01800 fwd 192.168.251.12 ip from any to any out recv eth1 xmit eth3

01900 fwd 192.168.252.12 ip from any to any out recv eth1 xmit eth2

10000 allow icmp from any to any

10100 allow tcp from any to any established

10200 allow ip from any to any frag

10300 allow ip from 172.10.0.0/20,172.10.128.0/22 to any { via vlan1 or via eth4 or via vlan2 or via vlan4 or via eth5 }

10400 allow ip from any to 172.10.0.0/20,172.10.128.0/22 { via vlan1 or via eth4 or via vlan2 or via vlan4 or via eth5 }

10500 allow ip from any to 111.222.80.0/20,111.333.16.0/21

10600 allow ip from 111.222.80.0/20,111.333.16.0/21 to any

...

далее идут правила доступа к локальным сервисам и серверам внутри сети

...

65535 deny ip from any to any

 

eth0 - входящий город поделен на вланы

eth1 - входящий интернет

eth2,eth3 - исходящий к Nas-ам

eth4,eth5 - исходящий еще к 2 сетям

 

11-31 - пайпы шейпера, скорости доступа поделили по подсетям

1800,1900 - заворачиваем интернет трафик в вланы к Nas-ам, для дальнейшего обсчета в биллинге.

10300,10400 серые адреса по городу

Изменено 13 апреля, 2011 пользователем vadius

[st_re]

Вообще конечно лучше корку получить и sendpr+писать в -net (ну судя по irq258:igb0:que 2 таки в нет)

 

зы

"emХ taskq" и "irqХ: igbХ:que" по процессорам бы поприбивать неплохо бы...

[Giga-Byte]

kern.ipc.nmbclusters=524288

kern.ipc.maxsockbuf=2097152

kern.ipc.somaxconn=32768

kern.maxfiles=204800

kern.maxfilesperproc=200000

kern.ipc.shm_use_phys=1

т.е убрать их из rc.conf?

угу

 

00011 pipe 1 ip from any to 111.222.80.0/21 in via eth1

00011 pipe 2 ip from 111.222.80.0/21 to any out via eth1

00012 pipe 3 ip from any to 111.222.88.0/22 in via eth1

00012 pipe 4 ip from 111.222.88.0/22 to any out via eth1

00012 pipe 3 ip from any to 111.222.92.0/24 in via eth1

00012 pipe 4 ip from 111.222.92.0/24 to any out via eth1

00013 pipe 5 ip from any to 111.222.93.0/24 in via eth1

00013 pipe 6 ip from 111.222.93.0/24 to any out via eth1

00013 pipe 5 ip from any to 111.222.94.0/23 in via eth1

00013 pipe 6 ip from 111.222.94.0/23 to any out via eth1

00014 pipe 7 ip from any to 111.333.16.0/24 in via eth1

00014 pipe 8 ip from 111.333.16.0/24 to any out via eth1

00021 pipe 9 ip from any to 111.333.23.0/27 in via eth1

00021 pipe 10 ip from 111.333.23.0/27 to any out via eth1

00022 pipe 11 ip from any to 111.333.23.32/27 in via eth1

00022 pipe 12 ip from 111.333.23.32/27 to any out via eth1

00023 pipe 13 ip from any to 111.333.23.64/27 in via eth1

00023 pipe 14 ip from 111.333.23.64/27 to any out via eth1

00024 pipe 15 ip from any to 111.333.23.96/27 in via eth1

00024 pipe 16 ip from 111.333.23.96/27 to any out via eth1

00031 pipe 13 ip from any to 111.333.23.192/27 in via eth1

00031 pipe 14 ip from 111.333.23.192/27 to any out via eth1

попробуйте не использовать in via eth1, используйте out via ethX на какой интерфейс там ваши сети уходят 111.х.у.z соответственно.

[Giga-Byte]

Вообще конечно лучше корку получить и sendpr+писать в -net (ну судя по irq258:igb0:que 2 таки в нет)

сильно долбить туда тоже не стоит, а то начнут игнорировать :)

зы

"emХ taskq" и "irqХ: igbХ:que" по процессорам бы поприбивать неплохо бы...

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

[st_re]

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

 

одно другому не мешает.

[vadius]

Вообще конечно лучше корку получить и sendpr+писать в -net (ну судя по irq258:igb0:que 2 таки в нет)

вот с коркой проблема, никак ее нет

 

"emХ taskq" и "irqХ: igbХ:que" по процессорам бы поприбивать неплохо бы...

Сейчас прибито:

cpuset -l 0,2 -p 0

в top-е видно

 

попробуйте не использовать in via eth1, используйте out via ethX на какой интерфейс там ваши сети уходят 111.х.у.z соответственно.

это вот можно попробовать

[st_re]

вот с коркой проблема, никак ее нет

 

т.е. всякие

 

# Build kernel with gdb(1) debug symbols
makeoptions DEBUG=-g

# Don't enter the debugger for a panic. Intended for unattended operation
# where you may want to enter the debugger from the console, but still want
# the machine to recover from a panic.
# (in a nutshell, reboot if there's a panic)
options    KDB_UNATTENDED

 

не помогают и все равно висит ?

 

 

Сейчас прибито:

cpuset -l 0,2 -p 0

в top-е видно

Я бы таки размазал по ядрам, уж коли их есть. приэтом 0,2 оно все равно болтается то там, то там. ну да ладно, скорее всего к висам/трапам оно таки отношения не имеет.

[vadius]

в ядре:

 

makeoptions DEBUG=-g

options KDB

options KDB_TRACE

 

а вот options KDB_UNATTENDED

нет

 

Я бы таки размазал по ядрам, уж коли их есть. приэтом 0,2 оно все равно болтается то там, то там. ну да ладно, скорее всего к висам/трапам оно таки отношения не имеет.

пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90%

меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так

[Giga-Byte]

пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90%

меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так

это решается заменой в pipe правилах in via... на out via...

[vadius]

это решается заменой в pipe правилах in via... на out via...

Giga-Byte спасибо за совет, срочным образом меняю на out :)

[st_re]

/bin/ps -p 0 -axcH -o lwp,command | egrep 'dummynet'  | while read lwp cmd; do /usr/bin/cpuset -l Х -t $lwp; done

 

приколотит думминет (а не весь кернел) к конкретному процессору X. У меня в таком виде оно не грузит процессоры ни на in ни на out... (ну аут конечно правильнее.)

 

а вот options KDB_UNATTENDED

нет

 

У утверждается что должно помочь получить ребут и соотв дамп....

[vadius]

/bin/ps -p 0 -axcH -o lwp,command | egrep 'dummynet' | while read lwp cmd; do /usr/bin/cpuset -l Х -t $lwp; done

приколотит думминет (а не весь кернел) к конкретному процессору X. У меня в таком виде оно не грузит процессоры ни на in ни на out... (ну аут конечно правильнее.)

st_re благодарю за помощь, а то я что-то не смог найти как отдельный процесс прибить к нужному ядру (видимо плохо искал :) ), буду экспериментировать. options KDB_UNATTENDED попробую поставить.

[vadius]

Фигня какая то, на разных ядрах загрузка dummynet кардинально отличается.

 

Прибиваю dummynet к 0 ядру:

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11 root 171 ki31 0K 128K CPU1 1 41:16 100.00% {idle: cpu1}

11 root 171 ki31 0K 128K CPU3 3 41:14 100.00% {idle: cpu3}

11 root 171 ki31 0K 128K CPU4 4 40:57 100.00% {idle: cpu4}

11 root 171 ki31 0K 128K CPU2 2 38:04 100.00% {idle: cpu2}

11 root 171 ki31 0K 128K CPU0 0 37:31 100.00% {idle: cpu0}

11 root 171 ki31 0K 128K CPU7 7 40:37 98.19% {idle: cpu7}

11 root 171 ki31 0K 128K CPU6 6 41:07 96.39% {idle: cpu6}

11 root 171 ki31 0K 128K RUN 5 40:20 91.46% {idle: cpu5}

0 root -68 0 0K 336K - 7 2:06 8.69% {em3 taskq}

0 root -68 0 0K 336K - 5 3:13 7.76% {em1 taskq}

0 root -68 0 0K 336K - 6 1:00 5.86% {em2 taskq}

0 root -68 0 0K 336K - 4 0:51 4.05% {em0 taskq}

12 root -68 - 0K 512K WAIT 0 0:08 0.20% {irq256: igb0:que}

0 root 44 0 0K 336K sched 2 3:02 0.00% {swapper}

0 root -68 0 0K 336K - 0 1:47 0.00% {dummynet}

 

к 1 ядру:

0 root -68 0 0K 336K - 1 1:50 0.00% {dummynet}

 

ко 2:

0 root -68 0 0K 336K - 2 1:55 0.00% {dummynet}

 

к 3:

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11 root 171 ki31 0K 128K CPU1 1 44:34 100.00% {idle: cpu1}

11 root 171 ki31 0K 128K CPU4 4 44:12 100.00% {idle: cpu4}

11 root 171 ki31 0K 128K CPU7 7 43:46 100.00% {idle: cpu7}

11 root 171 ki31 0K 128K CPU2 2 41:24 100.00% {idle: cpu2}

0 root -68 0 0K 336K - 3 2:00 100.00% {dummynet}

11 root 171 ki31 0K 128K RUN 5 43:24 99.66% {idle: cpu5}

11 root 171 ki31 0K 128K RUN 0 40:50 98.97% {idle: cpu0}

11 root 171 ki31 0K 128K CPU6 6 44:22 96.09% {idle: cpu6}

 

к 4 ядру:

0 root -68 0 0K 336K - 4 2:07 96.29% {dummynet}

 

к 5:

0 root -68 0 0K 336K - 5 2:11 0.00% {dummynet}

 

к 6:

0 root -68 0 0K 336K - 6 2:12 0.00% {dummynet}

 

к 7:

0 root -68 0 0K 336K - 7 2:15 0.00% {dummynet}

[vadius]

kern.ipc.nmbclusters=524288

kern.ipc.maxsockbuf=2097152

kern.ipc.somaxconn=32768

kern.maxfiles=204800

kern.maxfilesperproc=200000

kern.ipc.shm_use_phys=1

вернуть в базовые значения

что то я сомневаюсь на счет базового значения kern.ipc.nmbclusters, оно равно 25600.

я сохранял netstat -m, когда у меня было kern.ipc.nmbclusters=262144

 

26540/10074/36614/262144 mbuf clusters in use (current/cache/total/max)

 

получается не хватит mbuf кластеров?

[Giga-Byte]

kern.ipc.nmbclusters=524288

kern.ipc.maxsockbuf=2097152

kern.ipc.somaxconn=32768

kern.maxfiles=204800

kern.maxfilesperproc=200000

kern.ipc.shm_use_phys=1

вернуть в базовые значения

что то я сомневаюсь на счет базового значения kern.ipc.nmbclusters, оно равно 25600.

я сохранял netstat -m, когда у меня было kern.ipc.nmbclusters=262144

 

26540/10074/36614/262144 mbuf clusters in use (current/cache/total/max)

 

получается не хватит mbuf кластеров?

согласен, поставьте тогда в 61000

либо kern.maxusers=512 >> /boot/loader.conf

в конфиге ядра кстати какое значение?

с повышеным maxusers можно (а может нужно) попробовать увеличить vm.kmem_size, vm.kmem_size_max к 1G (если памяти 2Гб и больше)

а также vm.kmem_size_scale=2

 

 

 

на счет прибить дамминет к ядрам - ИМХО надо тогда и потоки обработки "прерываний" (em taskq) прибивать к той же группе ядер, у которых кэш L3 один.

некоторые говорили отключать HT (hyper threading), чтобы не путались ядра.

[vadius]

в ядре все по умолчанию, вот sysctl-ы

kern.maxuser: 384

vm.kmem_size_scale: 1

vm.kmem_size: 8206544896

vm.kmem_size_max: 329853485875

[Giga-Byte]

в ядре все по умолчанию, вот sysctl-ы

kern.maxuser: 384

vm.kmem_size_scale: 1

vm.kmem_size: 8206544896

vm.kmem_size_max: 329853485875

ай, вру, тогда не трогайте, там с amd64 куча варнингов и ахтунгов было на счет изменения этих значений. у меня то на роутерах i386, аптаймы уже годами.

тогда просто maxusers до 512 и смотрите как увеличится nmbclusters (можно на другой машине), либо поставьте nmbclusters в 61000, думаю никуда больше не упрётся с таким значением (нежели с 262144)

[vadius]

да уже думал что надо было ставить i386 на роутер.

nmbclusters поставил в 61000 буду смотреть.

[st_re]

А что там такое на 3-4 ядрах ?

 

что это вообще ?

 

egrep '^[[:space:]]*cpu' /var/run/dmesg.boot

? не HT часом ?

[Ivan_83]

флоу кеш из ядра удалить нафик - пересобрать ядро без него.

[vadius]

А что там такое на 3-4 ядрах ?

не знаю, я ничего к ним не привязывал

 

HT отключен.

 

egrep '^[[:space:]]*cpu' /var/run/dmesg.boot

cpu0 (BSP): APIC ID: 0

cpu1 (AP): APIC ID: 2

cpu2 (AP): APIC ID: 18

cpu3 (AP): APIC ID: 20

cpu4 (AP): APIC ID: 32

cpu5 (AP): APIC ID: 34

cpu6 (AP): APIC ID: 50

cpu7 (AP): APIC ID: 52

cpu0: <ACPI CPU> on acpi0

cpu1: <ACPI CPU> on acpi0

cpu2: <ACPI CPU> on acpi0

cpu3: <ACPI CPU> on acpi0

cpu4: <ACPI CPU> on acpi0

cpu5: <ACPI CPU> on acpi0

cpu6: <ACPI CPU> on acpi0

cpu7: <ACPI CPU> on acpi0

 

 

флоу кеш из ядра удалить нафик - пересобрать ядро без него.

flowtable из ядра убран был сразу, с ним сетевая подсистема вставала колом буквально через 1-2 минуты после поднятия сервера.

Изменено 14 апреля, 2011 пользователем vadius

[dadv]

Проблема в следующем:

Раз в неделю получаем kernel panic fatal trap 12 (current process = 12 (irq258:igb0:que 2) или (current process = 0 (em2 taskq)) и завис, пару раз была перезагрузка. Самое интересное, часто падает днем в то время когда нагрузка ниже средней.

 

Проблема известная. Обновляйтесь до 8.2-STABLE, там это на днях исправили. И держите net.isr.direct=1 и net.isr.direct_force=1 (по дефолту, то есть), другие значения тоже провоцируют паники, а с этими всё стабильно.

[Ivan_83]

пробовал ставить разные ядра (0,2,4),(0,2,4,6), но не понятно почему, процесс dummynet начинает грузить некоторые ядра (4 или 6) до 80-90% меняешь на 0,2 загрузка падает ниже 10%, поэтому временно оставил так

Потому что 4 ядра получились у интела объединением двух двух ядреных процессоров в один корпус, но с общим L3 кешем, соотвественно когда у вас сетевухи на одной паре ядрес с общим кешем, а диминет на другой то вы получаете пинальти и процессор стоит и синхронизирует кеши L2 через L3.