Перейти к содержимому
Калькуляторы

FreeBSD9.0 ng_queue выжирает до 100% одного из CPU Иногда один из процессов ng_queue выжирает до 100% одного из CPU при э

Name: <unnamed> Type: ksocket ID: 00000040 Num hooks: 1

 

похоже эта, но лучше построчно запускать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Name: <unnamed> Type: ksocket ID: 00000040 Num hooks: 1

 

похоже эта, но лучше построчно запускать.

 

Благодарю всех за помощь - заработало как надо

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Followup

 

FreeBSD 7.2 em ng_nat Core2Duo

 

В среднем 10000 pps, пики в 20000 pps. Не очень много.... Процессор на 20-30% максимум загружен.

Но вот сегодня случился матч по хоккею Россия-Норвегия.

И видимо много абонентов одновременно захотели его посмотреть.

 

Сервер впал в кому:

одно ядро 100% ng_queue0, второе простаивает

пинг до сервера 1000ms, ssh с трудом протискивается

на коммутаторах нагрузка интерфейса минимальная....

 

На сервере крутиться ng_nat и шейпер через dummynet

 

03000 netgraph tablearg ip from any to table(6) in recv vlan0
10000 pipe tablearg ip from table(100) to any in
10005 deny ip from table(109) to any
10010 netgraph tablearg ip from table(5) to any out xmit vlan0
10100 pipe tablearg ip from any to table(101) out

 

Вот что нашлось в интернете:

 

http://lists.freebsd.org/pipermail/freebsd-net/2010-January/024357.html

Вкратце - на FreeBSD7.2 у человека как только количество пакетов в ng_ipfw превышает порог и узел перестает успевать обрабатывать пакеты

наступает попа. одно ядро занято ng_queueX, остальные простаивают.

ng_ipfw один, не параллелится.

 

моя нагрузка.

netstat -w1 -I em0
           input          (em0)           output
  packets  errs      bytes    packets  errs      bytes colls
     9033     0    7058753       8767     0    7037515     0
    10096     0    7769096       9803     0    7757513     0
     9882     0    7798929       9635     0    7787372     0
    10365     0    7842143       9998     0    7702506     0
    11305     0    8400510      11066     0    8442332     0
    12084     0    9238992      11750     0    9167847     0
    14929     0   11745265      14722     0   11777404     0
    12287     0    9132906      12031     0    9180145     0

 11 root        1 171 ki31     0K     8K CPU1    1 124:22 100.00% idle: cpu1
  12 root        1 171 ki31     0K     8K RUN     0 127:00 90.58% idle: cpu0
  27 root        1 -68    -     0K     8K WAIT    0  19:07  9.67% irq256: em0
   2 root        1 -68    -     0K     8K sleep   1  28:03  0.29% ng_queue0
   3 root        1 -68    -     0K     8K sleep   1   6:49  0.20% ng_queue1
  48 root        1 -68    -     0K     8K -       0   9:13  0.00% dummynet
  14 root        1 -32    -     0K     8K WAIT    0   1:42  0.00% swi4: clock
  28 root        1 -68    -     0K     8K WAIT    1   1:00  0.00% irq257: em0
  26 root        1 -68    -     0K     8K -       0   0:40  0.00% em0 taskq

 

У меня 7.2, работало без проблем, а у топик стартера 9.0 - и такие же сипмтомы.

неужели не починили....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Followup

 

FreeBSD 7.2 em ng_nat Core2Duo

FreeBSD 9.1-STABLE #0: Fri Jan 18 16:20:47 YEKT 2013

 

У меня такое же бывало

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

sysctl на нетграфову память крутили?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сейчас:

[size=2]                  SIZE     LIMIT      USED      FREE  REQUESTS  FAILURES[/size]
NetGraph items:            52,     4130,        0,      177,       89,        0
NetGraph data items:       52,      531,        1,      530, 1791029767,  1178838

net.graph.msg_version: 8
net.graph.abi_version: 65547
net.graph.maxdata: 512
net.graph.maxalloc: 4096
net.graph.threads: 2
net.graph.control.proto: 2
net.graph.data.proto: 1
net.graph.family: 32
net.graph.recvspace: 128000
net.graph.maxdgram: 128000

 

Добавил в boot/loder.conf

 

net.graph.maxdata=65536

net.graph.maxalloc=65536

на будущее.

 

Пока попробовал поставить

net.isr.direct=0

 

net.inet.ip.fastforwarding: 0

 

Нагрузка с irq уползла на swi1:net, распределилась на два ядра параллельно,

НО стала больше.

Если раньше одно ядро было под 28%, второе в районе 10%, то теперь одно 32%, второе 20%

 

PPS при этом 24к

Жалоб от клиентов нет, буду дальше смотреть на статистику

и да. сетевуха - десктопный интел за 1000 руб.

Изменено пользователем LuckySB

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Решил поменять железо. Взял соседний core i3 с 4Gb и перенес в него винт и сетевуху.

 

В процессе смены выяснилось, что на том сервере, с которого переносил винт проблемы с кулером на проце.

После включения обороты в районе 100-300 rpm, потом правда раскручивается по полной. Возможно и в этом проблема была...

 

 

Смущает, что на нем загрузка процессора больше....

Но пока все работает хорошо. сегодня обмолотил 37к пакетов в секунду....

200/50 мбит трафика

(но видимо есть проблемы с bsnmpd, при опросе snmp-счетчиков кактусом и mrtg не рисуется трафик больше 200мбит.

Увеличил begemotIfForcePoll = 6000, будем посмотреть.

[/size]


    15560     0   12530952      14991     0   12022975     0
    13433     0   10742020      12755     0   10129682     0
    16931     0   14308109      16385     0   13788607     0
    14928     0   12408319      14408     0   11974836     0
    12836     0   10533682      12286     0   10033641     0
[size=2]^C[/size]

# top -SP
last pid: 28766;  load averages:  0.08,  0.08,  0.07
132 processes: 3 running, 109 sleeping, 1 zombie, 19 waiting
CPU 0:  0.0% user,  0.0% nice,  8.3% system,  0.8% interrupt, 91.0% idle
CPU 1:  0.0% user,  0.0% nice,  0.8% system, 13.2% interrupt, 86.1% idle
Mem: 116M Active, 1149M Inact, 341M Wired, 116K Cache, 199M Buf, 1577M Free
Swap: 4096M Total, 4096M Free

 PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  12 root        1 171 ki31     0K     8K RUN     0 116.6H 91.06% idle: cpu0
  11 root        1 171 ki31     0K     8K CPU1    1 110.9H 85.50% idle: cpu1
  32 root        1 -68    -     0K     8K WAIT    1 897:31 19.48% irq256: em0
   2 root        1 -68    -     0K     8K sleep   0 207:59  3.08% ng_queue0
   3 root        1 -68    -     0K     8K sleep   0 207:58  3.08% ng_queue1
  33 root        1 -68    -     0K     8K WAIT    0  61:08  0.68% irq257: em0

 

Старый сервер

loader.conf

[size=2]kern.ipc.maxpipekva="60000000"[/size]
geom_label_load="YES"
hw.em.rxd=4096
hw.em.txd=4096
[size=2]

sysctl

[/size]
[size=2]
kern.ipc.maxsockbuf=2097152
kern.ipc.somaxconn=1024
[size=2]kern.ipc.nmbclusters=65535[/size]
kern.maxfiles=65000
kern.maxfilesperproc=32000
net.inet.ip.fw.dyn_buckets=65536
net.inet.ip.fw.dyn_max=65536
net.inet.ip.rtmaxcache=1024
net.inet.ip.ttl=255
net.inet.ip.intr_queue_maxlen=1000
net.route.netisr_maxqlen=2048
net.inet.ip.fw.one_pass=1
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.io_fast=1
# Generate random IP_ID's
net.inet.ip.random_id=1
net.inet.ip.fastforwarding=1
net.graph.recvspace=128000
net.graph.maxdgram=128000


dev.em.0.rx_int_delay=1000
dev.em.0.tx_int_delay=1000
dev.em.0.rx_abs_int_delay=2000
dev.em.0.tx_abs_int_delay=2000
dev.em.0.rx_processing_limit=4096
[/size]
[size=2]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

(но видимо есть проблемы с bsnmpd, при опросе snmp-счетчиков кактусом и mrtg не рисуется трафик больше 200мбит.

Увеличил begemotIfForcePoll = 6000, будем посмотреть.

 

Это у вас в какти счетчики 32-х битные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это у вас в какти счетчики 32-х битные.

 

Конечно же нет. тот же какти с коммутаторов по полгигабита загрузки спокойно рисует на интерфейсах

 

 

Сегодня в середине дня опять случился жорик.

Не помогло новое железо. ;(

 

Причем жорик длился около часа и прошел сам собой. ;(

будем переползать на 9.2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Конечно же нет. тот же какти с коммутаторов по полгигабита загрузки спокойно рисует на интерфейсах

 

Конечно рисует, если при создании выбрать протокол v2 и график 64-бита...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Конечно же нет. тот же какти с коммутаторов по полгигабита загрузки спокойно рисует на интерфейсах

 

Конечно рисует, если при создании выбрать протокол v2 и график 64-бита...

не надо считать людей глупее себя.

заменил штатный bsmnpd на netsnmpd - все стало рисоваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

заменил штатный bsmnpd на netsnmpd - все стало рисоваться.

Значит, вы не подгрузили соответствующие netgraph модули.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

заменил штатный bsmnpd на netsnmpd - все стало рисоваться.

Значит, вы не подгрузили соответствующие netgraph модули.

 

Или не покормили собаку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Имеются сходные симптомы

ng_queue грузит ядро на 100%

ping: sendto: Cannot allocate memory

NetGraph data items fails

 

Накрутка

net.graph.maxdata=262144

net.graph.maxalloc=262144

 

ничего не дает в каой то момент все равно происходит переполнение.

NetGraph data items: 72, 262160, 262147, 13,52086227,1246688, 0

 

 

root@firewall-2:/usr/home/Multik # top -HS

last pid: 18557; load averages: 1.55, 1.41, 1.55 up 23+14:57:53 22:05:50

139 processes: 6 running, 106 sleeping, 27 waiting

CPU: 0.4% user, 0.0% nice, 23.2% system, 8.0% interrupt, 68.5% idle

Mem: 918M Active, 437M Inact, 817M Wired, 827M Buf, 5717M Free

Swap: 10G Total, 10G Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

13 root -16 - 0K 64K CPU3 3 49.5H 100.00% ng_queue{ng_qu

11 root 155 ki31 0K 64K RUN 3 431.2H 75.39% idle{idle: cpu3

11 root 155 ki31 0K 64K CPU2 2 431.1H 73.19% idle{idle: cpu2

11 root 155 ki31 0K 64K RUN 0 433.4H 68.36% idle{idle: cpu0

11 root 155 ki31 0K 64K CPU1 1 431.5H 67.09% idle{idle: cpu1

12 root -92 - 0K 432K WAIT 0 34.4H 3.86% intr{irq261: ig

12 root -92 - 0K 432K WAIT 3 39.1H 3.47% intr{irq259: ig

12 root -92 - 0K 432K WAIT 0 39.3H 3.27% intr{irq256: ig

12 root -92 - 0K 432K WAIT 1 39.4H 2.69% intr{irq257: ig

12 root -92 - 0K 432K WAIT 2 39.1H 2.29% intr{irq258: ig

12 root -92 - 0K 432K WAIT 2 34.2H 2.20% intr{irq263: ig

12 root -92 - 0K 432K WAIT 3 33.7H 1.76% intr{irq264: ig

12 root -92 - 0K 432K WAIT 1 34.1H 1.17% intr{irq262: ig

13 root -16 - 0K 64K sleep 0 49.0H 0.78% ng_queue{ng_que

13 root -16 - 0K 64K sleep 1 48.7H 0.68% ng_queue{ng_que

13 root -16 - 0K 64K sleep 2 49.9H 0.49% ng_queue{ng_que

 

 

Присем данная проблема возникает на 2х машинах на одной 9.0 на второй 9.2

обе машины обновлялись с 8.2 и там была эта же проблема.

 

К разным машинкам подключены 2а разных канала от 2х не зависимых провайдеров.

 

работают как нат+шейпер

 

От нагрузки возникновение проблемы не зависит, иногда это бывает в моменты близкие к пикам 150k pps иногда это вообще не серьезная нагрузка вида 50k pps

 

Перезагрузка сервера помогает не на долго, минут через 10 проблема снова возникает, потом сама собой проходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Имеются сходные симптомы

ng_queue грузит ядро на 100%

ping: sendto: Cannot allocate memory

NetGraph data items fails

 

Накрутка

net.graph.maxdata=262144

net.graph.maxalloc=262144

 

ничего не дает в каой то момент все равно происходит переполнение.

NetGraph data items: 72, 262160, 262147, 13,52086227,1246688, 0

 

 

Допишите в /etc/sysctl.conf

 

net.graph.recvspace=2048000
net.graph.maxdgram=2048000
kern.ipc.nmbclusters=2000000

и покажите

netstat -m

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я уже крутил эти параметры немного

net.graph.maxdgram=724248

net.graph.recvspace=724248

kern.ipc.maxsockbuf=23175936

 

 

никакого эффекта не дает.

netstat -m вышлю как проблема повторится

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

собственно вот

начинается процесс умирания всего

поднялся пинг от пользователей чере нат

начало расти заполнение буфера

 

NetGraph data items: 72, 262160, 2448, 4106,2757945007, 0, 0

NetGraph data items: 72, 262160, 2529, 4025,2760913074, 0, 0

но пока ошибок еще нет

и про отсутствие памяти не пишет

 

 

root@firewall-2:/usr/home/Multik # netstat -m

9541/6209/15750 mbufs in use (current/cache/total)

9533/5321/14854/524288 mbuf clusters in use (current/cache/total/max)

9533/5315 mbuf+clusters out of packet secondary zone in use (current/cache)

0/77/77/12800 4k (page size) jumbo clusters in use (current/cache/total/max)

0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)

0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)

21557K/12502K/34059K bytes allocated to network (current/cache/total)

0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)

0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)

0/0/0 requests for jumbo clusters delayed (4k/9k/16k)

0/0/0 requests for jumbo clusters denied (4k/9k/16k)

0/0/0 sfbufs in use (current/peak/max)

0 requests for sfbufs denied

0 requests for sfbufs delayed

0 requests for I/O initiated by sendfile

0 calls to protocol drain routines

 

динамика такая

root@firewall-2:/usr/home/Multik # netstat -m

10701/5049/15750 mbufs in use (current/cache/total)

10693/4161/14854/524288 mbuf clusters in use (current/cache/total/max)

10693/4155 mbuf+clusters out of packet secondary zone in use (current/cache)

0/77/77/12800 4k (page size) jumbo clusters in use (current/cache/total/max)

0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)

0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)

24225K/9892K/34117K bytes allocated to network (current/cache/total)

0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)

0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)

0/0/0 requests for jumbo clusters delayed (4k/9k/16k)

0/0/0 requests for jumbo clusters denied (4k/9k/16k)

0/0/0 sfbufs in use (current/peak/max)

0 requests for sfbufs denied

0 requests for sfbufs delayed

0 requests for I/O initiated by sendfile

0 calls to protocol drain routines

 

Переключил пользователей на другого провайдера, без перезагрузки сервера, просто нат завернул на другой ИП

все нормализовалось.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот в очередной раз ситуация повторилась

root@firewall-2:/usr/home/Multik # netstat -mb

8573/263437/272010 mbufs in use (current/cache/total)

8451/262659/271110/524288 mbuf clusters in use (current/cache/total/max)

8451/262648 mbuf+clusters out of packet secondary zone in use (current/cache)

0/104/104/12800 4k (page size) jumbo clusters in use (current/cache/total/max)

0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)

0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)

19110K/591593K/610704K bytes allocated to network (current/cache/total)

0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)

0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)

0/0/0 requests for jumbo clusters delayed (4k/9k/16k)

0/0/0 requests for jumbo clusters denied (4k/9k/16k)

0/0/0 sfbufs in use (current/peak/max)

0 requests for sfbufs denied

0 requests for sfbufs delayed

0 requests for I/O initiated by sendfile

0 calls to protocol drain routines

 

 

NetGraph data items: 72, 262160, 674, 261486,62733990280,39958556, 36

 

но на этот раз все не умерло а через некоторое время очухалось.

 

распределение нагрузки по ядрам вроде нормальное

 

last pid: 48472; load averages: 2.65, 2.34, 2.16 up 11+23:34:07 22:03:19

130 processes: 6 running, 97 sleeping, 27 waiting

CPU 0: 0.0% user, 0.0% nice, 13.8% system, 37.9% interrupt, 48.3% idle

CPU 1: 0.0% user, 0.0% nice, 27.6% system, 17.2% interrupt, 55.2% idle

CPU 2: 0.0% user, 0.0% nice, 27.6% system, 17.2% interrupt, 55.2% idle

CPU 3: 0.0% user, 0.0% nice, 31.0% system, 17.2% interrupt, 51.7% idle

Mem: 784M Active, 312M Inact, 1765M Wired, 973M Buf, 5028M Free

Swap: 10G Total, 10G Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11 root 155 ki31 0K 64K CPU3 3 224.2H 58.89% idle{idle: cpu3}

11 root 155 ki31 0K 64K RUN 1 224.5H 58.25% idle{idle: cpu1}

11 root 155 ki31 0K 64K RUN 2 224.4H 54.79% idle{idle: cpu2}

11 root 155 ki31 0K 64K CPU0 0 216.8H 51.17% idle{idle: cpu0}

12 root -72 - 0K 432K WAIT 2 39.5H 25.59% intr{swi1: netisr 0}

13 root -16 - 0K 64K sleep 1 21.3H 23.39% ng_queue{ng_queue2}

13 root -16 - 0K 64K sleep 3 22.2H 22.56% ng_queue{ng_queue1}

13 root -16 - 0K 64K sleep 2 21.3H 22.36% ng_queue{ng_queue3}

13 root -16 - 0K 64K CPU2 2 21.7H 21.97% ng_queue{ng_queue0}

12 root -92 - 0K 432K WAIT 3 19.0H 13.28% intr{irq259: igb0:que}

12 root -92 - 0K 432K WAIT 1 18.9H 12.79% intr{irq257: igb0:que}

12 root -92 - 0K 432K WAIT 0 19.7H 10.79% intr{irq256: igb0:que}

12 root -92 - 0K 432K WAIT 2 19.0H 10.50% intr{irq258: igb0:que}

12 root -92 - 0K 432K WAIT 0 890:13 7.76% intr{irq261: igb1:que}

12 root -92 - 0K 432K WAIT 1 422:17 3.17% intr{irq262: igb1:que}

12 root -92 - 0K 432K WAIT 2 423:43 2.78% intr{irq263: igb1:que}

12 root -92 - 0K 432K WAIT 3 427:36 2.20% intr{irq264: igb1:que}

12 root -60 - 0K 432K WAIT 0 286:15 0.88% intr{swi4: clock}

4342 bind 20 0 814M 764M uwait 2 15:02 0.29% named{named}

4342 bind 20 0 814M 764M uwait 3 15:00 0.29% named{named}

4342 bind 20 0 814M 764M uwait 3 14:58 0.29% named{named}

4342 bind 20 0 814M 764M uwait 2 15:01 0.20% named{named}

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В свое время были такие проблемы - перешли на ipfw nat.

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

Добавьте в правило фаервола

 

00011    382711287     27928042812 deny ip from any to any dst-port 6881

 

это стандартный порт обмена DHT у торрентов

может достигать умопомрачительный чисел для процессора запросов на соединение и ждать ответа.

 

P.S. В последних версиях торрент клиентов видимо также появилась возможность использовать другие порты для DHT.

Ребята нашли решение в пересборке libalias с меньшими временами поддержания соединения.

Изменено пользователем vitcin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня тоже были подозрения на торенты. Когда снифирил входящий трафик было очень много соединений на этот порт как раз. Сейчас попробовал закрыть, посмотрим как пойдет.

А что за сборка библиотеки libalias?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прошел почти месц с момента как закрыл порт 6881 полет нормальный, проблема не повторялась.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Совсем DHT резать - это наверное жестоко.... ;)

 

Попробую я вот такую конструкцию:

allow ip from any to any dst-port 6881 limit src-addres,dst-port 100

Кстати, на FreeBSD 9.2 ng_queue более щадяще в 100% упирается, чем на 7.3....

хоть на консоль можно без тормозов зайти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.