Jump to content
Калькуляторы

FreeBSD 7.2 ng_queue 100% загрузка.

где этот процесс показывает, что полинг работает на одном ядре?

Могу только посоветовать по-больше читать, на этом форуме все уже давно разжевано.

Share this post


Link to post
Share on other sites
где этот процесс показывает, что полинг работает на одном ядре?
Могу только посоветовать по-больше читать, на этом форуме все уже давно разжевано.

Значит еще раз разжую.

Этот процесс отвечает за прерывания сетевух.

Поллинг принимает эти прерывания и когда освобождается одно из ядер, передает этот процесс ядру

Если вы заметите, то этот процесс передает не одному ядру, а тому которое на данный момен свободное.

По поводу других жеваний, вижу только одно: попробывал не пошло, буду ждать когда другие попробуют.

Полинг работае в SMP уже с 5 версии, до этого он через sysctl запускался, теперь через ifconfig. Просто информацию надо читать посвежей.

Если я не прав, поправьте.

Share this post


Link to post
Share on other sites

Если я не прав, поправьте.

Какая разница как включается поллинг? Хоть через сисктл, хоть через ифконфиг, всеравно он использует только одно ядро. Если планируете нагружать этот комп, я бы посоветовал задуматься уже сейчас, чтобы не кусать локти потом.

Share this post


Link to post
Share on other sites
Если я не прав, поправьте.
Какая разница как включается поллинг? Хоть через сисктл, хоть через ифконфиг, всеравно он использует только одно ядро. Если планируете нагружать этот комп, я бы посоветовал задуматься уже сейчас, чтобы не кусать локти потом.

Так в том то и дело два одинаковых сервака если вы читали выше с яндекс дровами грузил одно ядро при нагрузке до 100%

и кусали локти именно тогда, когда канал падал раз в 10 и пинги выростали до 200-600мс.

с полингом и родными дровами при нагрузке все ядра распределяются равномерно и никаких тормозов нет уже 4-й день.

И не понятно откуда вы берете что поллинг работает с одним ядром?

Вы хоть смотрите top -PS ?

Edited by wsimons

Share this post


Link to post
Share on other sites

Вы хоть смотрите top -PS ?

Я смотрю, и вижу, что у вас вся сетевая подсистема работает на одном ядре. А что видите Вы?

Share this post


Link to post
Share on other sites
Вы хоть смотрите top -PS ?
Я смотрю, и вижу, что у вас вся сетевая подсистема работает на одном ядре. А что видите Вы?

Не путайте процесс с работой SMP.

Я вот вижу совсем другое

Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.

15 root 1 -44 - 0K 16K CPU2 2 27.5H 42.24% swi1: net

 

15 root 1 -44 - 0K 16K CPU3 3 27.5H 46.39% swi1: net

 

15 root 1 -44 - 0K 16K CPU0 0 27.5H 47.56% swi1: net

 

и т.д.

кстати сейчас нагрузка на этом сервере: более 400 клиентов, более 35kpps на одной сетевухе в каждую сторону и более 200Мбит так же в каждую сторону.

на яндекс дровах без полинга больше 20kpps не наблюдали и тем более сейчас еще раз повторюсь нет проблем с повышением пинга более чем в 5мс и падения pps

 

 

Share this post


Link to post
Share on other sites

Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.

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

Share this post


Link to post
Share on other sites
Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.
Он работает со всеми ядрами, но не параллельно, а по очереди.

Так очредность - это что одно ядро?

В freebsd почти все процессы так и работают

и не только в freebsd

кстати с яндекс дровами этот процесс работает точно так же.

яндекс дрова его не распараллеливает.

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

Edited by wsimons

Share this post


Link to post
Share on other sites
Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.
Он работает со всеми ядрами, но не параллельно, а по очереди.

Так очредность - это что одно ядро?

В freebsd почти все процессы так и работают

и не только в freebsd

кстати с яндекс дровами этот процесс работает точно так же.

яндекс дрова его не распараллеливает.

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

У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено.

Share this post


Link to post
Share on other sites
Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.
Он работает со всеми ядрами, но не параллельно, а по очереди.

Так очредность - это что одно ядро?

В freebsd почти все процессы так и работают

и не только в freebsd

кстати с яндекс дровами этот процесс работает точно так же.

яндекс дрова его не распараллеливает.

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

У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено.

Именно это я и описываю. Только вот яндекс дрова некоректно распределяют нагрузку в SMP

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

Edited by wsimons

Share this post


Link to post
Share on other sites
Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.
Он работает со всеми ядрами, но не параллельно, а по очереди.

Так очредность - это что одно ядро?

В freebsd почти все процессы так и работают

и не только в freebsd

кстати с яндекс дровами этот процесс работает точно так же.

яндекс дрова его не распараллеливает.

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

У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено.

Именно это я и описываю. Только вот яндекс дрова некоректно распределяют нагрузку в SMP

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

Может уже на 7.3-Release перейдем?

 

Share this post


Link to post
Share on other sites

поллинг работает на одном ядре

Вы наверно не понимаете главного. При поллинге вся сетевая подсистема в единый момент времени обрабатывается ОДНИМ ядром. Я уже не знаю как Вам объяснить столь очевидные вещи. Насчет яндексов у Вас вообще, как я понимаю, свой взгляд на Мир. У всех они работают прекрасно, а Вам не угодили. Если у других все хорошо стоит поискать проблему у себя.

Share this post


Link to post
Share on other sites

PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root     171 ki31     0K    16K CPU7    7  68.9H 100.00% idle: cpu7
   12 root     171 ki31     0K    16K RUN     6  68.8H 100.00% idle: cpu6
   13 root     171 ki31     0K    16K CPU5    5  68.3H 100.00% idle: cpu5
   15 root     171 ki31     0K    16K CPU3    3  69.4H 97.36% idle: cpu3
   17 root     171 ki31     0K    16K CPU1    1  69.0H 94.09% idle: cpu1
   14 root     171 ki31     0K    16K CPU4    4  65.1H 83.89% idle: cpu4
   18 root     171 ki31     0K    16K CPU0    0  61.1H 83.06% idle: cpu0
   16 root     171 ki31     0K    16K CPU2    2  61.6H 75.20% idle: cpu2
76727 root      43    -     0K    16K WAIT    0 291:12 10.99% em1_rx_kthread_2
76728 root      43    -     0K    16K WAIT    2 291:43 10.60% em1_rx_kthread_3
   67 root      43    -     0K    16K WAIT    2 301:31 10.50% em1_rx_kthread_0
   68 root      43    -     0K    16K WAIT    0 302:00 10.06% em1_rx_kthread_1
76662 root      43    -     0K    16K WAIT    0 248:41  8.59% em0_rx_kthread_3
76661 root      43    -     0K    16K WAIT    5 248:32  8.59% em0_rx_kthread_2
   64 root      43    -     0K    16K WAIT    3 259:46  8.40% em0_rx_kthread_1
   63 root      43    -     0K    16K WAIT    0 259:20  8.15% em0_rx_kthread_0
   19 root     -32    -     0K    16K WAIT    7 173:56  1.66% swi4: clock sio
72280 root      96    0 83240K 32568K select  6  31:30  0.20% mpd5
   66 root     -68    -     0K    16K WAIT    4  32:45  0.00% em1_txcleaner
   62 root     -68    -     0K    16K WAIT    4  19:23  0.00% em0_txcleaner
   41 root      44    -     0K    16K -       2   4:32  0.00% yarrow
   84 root      20    -     0K    16K syncer  4   1:22  0.00% syncer
   79 root       8    -     0K    16K pftm    6   1:02  0.00% pfpurge
3452 root      44    0  5856K  1448K select  7   0:23  0.00% syslogd
    5 root     -68    -     0K    16K sleep   4   0:21  0.00% ng_queue3
    7 root     -68    -     0K    16K sleep   4   0:21  0.00% ng_queue5
    3 root     -68    -     0K    16K sleep   4   0:21  0.00% ng_queue1
    4 root     -68    -     0K    16K sleep   4   0:21  0.00% ng_queue2
    9 root     -68    -     0K    16K sleep   2   0:21  0.00% ng_queue7
    8 root     -68    -     0K    16K sleep   4   0:21  0.00% ng_queue6

 

packets  errs      bytes    packets  errs      bytes colls
    335185     0  209992823     254527     0  169373415     0
    338935     0  214580075     255092     0  169751118     0
    335443     0  211247010     254734     0  170707083     0
    327842     0  205201850     247467     0  161428697     0
    328424     0  205379409     246017     0  162671318     0

 

ifconfig |grep ng |wc -l
     845

 

Вот теперь скажите мне wsimons, почему у меня процесс ng_queue совсем не грузит систему.

Почему работают яндекс драйвера, и таки работают в классическом понимании SMP(а не в вашем)

что я делаю не так?

Edited by UTP

Share this post


Link to post
Share on other sites
поллинг работает на одном ядре
Насчет яндексов у Вас вообще, как я понимаю, свой взгляд на Мир. У всех они работают прекрасно, а Вам не угодили. Если у других все хорошо стоит поискать проблему у себя.

На счет яндекс дров у меня понимание такое же как и у всех. Только не стоит говорить за всех, что они везде работают прекрасно. Советую вам на форумах почитать как они работают у многих.

 

Вот теперь скажите мне wsimons, почему у меня процесс ng_queue совсем не грузит систему.

Почему работают яндекс драйвера, и таки работают в классическом понимании SMP(а не в вашем)

что я делаю не так?

У вас нат на нем работает? Думаю что нет. Иначе показания бы ng_queue были бы далеко не 0%.

Ну мне до сих пор никто здесь не объяснил, что я делаю не так, что этот процесс грузит время от времени одно ядро на 100%, остальные все свободные.

Точнее предложения были, но они проблему не решили.

Share this post


Link to post
Share on other sites
У вас нат на нем работает? Думаю что нет

pfctl -si
Status: Enabled for 3 days 20:25:50           Debug: Urgent

State Table                          Total             Rate
  current entries                    17935
  searches                     54378409558       163421.2/s
  inserts                         61485264          184.8/s
  removals                        61467329          184.7/s
Counters
  match                        51300951214       154172.7/s
  bad-offset                             0            0.0/s
  fragment                           29290            0.1/s
  short                               3345            0.0/s
  normalize                              0            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                          57391            0.2/s
  proto-cksum                      1086994            3.3/s
  state-mismatch                   3762063           11.3/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s

 

Share this post


Link to post
Share on other sites

wsimsons, а что используется в качесте ната? ng_nat/ipfw nat? И как трафик в него заворачивается?

И что еще на нетграфе крутится? `ngctl types`

 

В том, что не сильно различающиеся конфигурации могут работать соверешенно по разному, нет ничего особенного.

Совсем недавно, кстати, в freebsd-net поднимали теуа с проблемами масштабируемости в связке ng_ipfw+ng_nat: http://lists.freebsd.org/pipermail/freebsd...ary/024357.html

 

PS: с "яндексовскими" драйверами у меня тоже были проблемы на тестовых машинах. Считаю, что их не стоит ставить без необходимости.

Share this post


Link to post
Share on other sites

UTP мне непонятно вы хотите показать как у вас все замечательно, _longhorn_ вы рассказываете как работает процесс swi1. А я хочу узнать почему загружается ng_queue на одном ядре на 100%, когда на остальных ядрах нет превышения 5%. И это на двух одинаковых машинах. Кстати на одной родные дрова em и polling, на другой яндек дрова. Если не знаете что ответить не надо заниматся флудом. Если я себе поставлю машину 2015г выпуска, то у меня вопрос отпадет сам по себе. Но мне непонятно, почему здесь на форуме пишут, что у них по 400 пользователей на серваке при этом 700Kpps и более, 600-700Мбит занятого канала. Просто какая то сказка. Или интернет стали раздавать без ограничений? Ну как не стремился раздать побольше, но при колличестве хомяков в 1400 больше 300 Мбит канал не поднимался. При всем этом никто не жалуется, что скорость зажимается. Проблему конечно решаем, но неправильно, точнее не решение проблеммы. Вместо того, чтобы всех держала 1 машина, держит 4.

Share this post


Link to post
Share on other sites
wsimsons, а что используется в качесте ната? ng_nat/ipfw nat? И как трафик в него заворачивается?

И что еще на нетграфе крутится? `ngctl types`

используется ng_nat, трафик заворачиваем через ipfw

на нетграфе крутится только нат и подсчет трафика, ограничение через mpd ng_car

 

00230 netgraph 5 ip from ххх.ххх.ххх.0/23 to any via ng* in

00330 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.0/23 to not ххх.ххх.ххх.0/23

00430 netgraph 1 ip from 10.0.0.0/8 to any via ng* in

00530 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.ххх to not ххх.ххх.ххх.0/23

00630 netgraph 23 ip from any to any in via inet0

00730 allow ip from any to any

 

/usr/sbin/ngctl -f- <<-SEQ

mkpeer ipfw: netflow 1 iface0

name ipfw:1 netflow

mkpeer netflow: split out0 in

name netflow:out0 split1

mkpeer netflow: ksocket export inet/dgram/udp

msg netflow:export connect inet/$ngnat_export

connect split1: netflow: out iface1

connect ipfw: netflow: 4 out1

mkpeer split1: nat mixed out

name split1:mixed nat1

connect ipfw: nat1: 23 in

connect ipfw: netflow: 5 iface2

connect ipfw: netflow: 6 out2

msg nat1: setaliasaddr $ngnat_aliasaddr

msg netflow: setdlt { iface=0 dlt=12 }

msg netflow: setifindex { iface=0 index=1000 }

msg netflow: setdlt { iface=1 dlt=12 }

msg netflow: setifindex { iface=1 index=1001 }

msg netflow: setdlt { iface=2 dlt=12 }

msg netflow: setifindex { iface=2 index=1002 }

SEQ

 

 

There are 15 total types:

Type name Number of living nodes

--------- ----------------------

mppc 0

socket 5

iface 122

car 210

bpf 105

vjc 0

tee 122

tcpmss 122

split 1

netflow 1

pptpgre 122

ppp 122

nat 1

ksocket 123

ipfw 1

 

 

Совсем недавно, кстати, в freebsd-net поднимали теуа с проблемами масштабируемости в связке ng_ipfw+ng_nat: http://lists.freebsd.org/pipermail/freebsd...ary/024357.html
Ну слава богу что я не один такой, только вот там о 1500-2000 сессиях пишут, а у нас такое бывает даже при 50-100, а бывает больше 400 и ничего страшного не происходит.
Edited by wsimons

Share this post


Link to post
Share on other sites
iface 122

Это явно в момент минимальной загрузки.

 

Еще не помешает статистика vmstat -z | fgrep NetGraph и vmstat -m | fgrep netgraph

 

На 7.3 стоит попробовать ipfw nat. У ng_netflow уменьшить таймауты, раза в 3.

 

 

 

Share this post


Link to post
Share on other sites
iface 122

Это явно в момент минимальной загрузки.

 

Еще не помешает статистика vmstat -z | fgrep NetGraph и vmstat -m | fgrep netgraph

 

На 7.3 стоит попробовать ipfw nat. У ng_netflow уменьшить таймауты, раза в 3.

Да это минимальная загрузка

 

vmstat -z | fgrep NetGraph

 

NetGraph items: 72, 4140, 77, 688, 7424225660, 0

NetGraph data items: 72, 540, 1, 539, 18526492846, 6884988

 

vmstat -m | fgrep netgraph

 

netgraph_msg 0 0K - 15395909 64,128,256,512,1024,2048,4096

netgraph_node 1347 337K - 101560 256

netgraph_hook 3230 404K - 188458 128

netgraph 1056 3417K - 62764 16,32,64,256,512,1024,4096

netgraph_bpf 1608 201K - 66704 128

netgraph_iface 156 20K - 4778 128

netgraph_ksock 157 20K - 14885 128

netgraph_parse 0 0K - 16 16,64

netgraph_ppp 156 1872K - 4778

netgraph_sock 4 1K - 29956 128

netgraph_path 0 0K - 7860441 16,32

netgraph_mppc 0 0K - 1 1024

 

 

попробуем на одной ipfw nat

результаты отпишу.

Edited by wsimons

Share this post


Link to post
Share on other sites
00230 netgraph 5 ip from ххх.ххх.ххх.0/23 to any via ng* in

00330 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.0/23 to not ххх.ххх.ххх.0/23

00430 netgraph 1 ip from 10.0.0.0/8 to any via ng* in

00530 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.ххх to not ххх.ххх.ххх.0/23

А оптимизировать эти правила не пробовали ?

via ng* in - жрет намного больше чем via inet0 out

Для каких целей fwd используете ? Неужели route add отменили ? ;)

 

натить сразу 10/8 в один адрес - круто. Помогает поднять несколько нат и натить каждую /24 в свой белый адрес.

00630 netgraph 23 ip from any to any in via inet0 - тоже красиво. Сквозь это правило проходит ВЕСЬ входящий трафик.

Что мешает поменять на 00630 netgraph 23 ip from any to me in via inet0 ?

 

 

Но мне непонятно, почему здесь на форуме пишут, что у них по 400 пользователей на серваке при этом 700Kpps и более, 600-700Мбит занятого канала. Просто какая то сказка. Или интернет стали раздавать без ограничений?
а головой подумать ?

Там же москвичи, у них тарифы на порядок скоростнее, ната нету, шейпер на отдельной машине...

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

 

Share this post


Link to post
Share on other sites
00230 netgraph 5 ip from ххх.ххх.ххх.0/23 to any via ng* in

00330 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.0/23 to not ххх.ххх.ххх.0/23

00430 netgraph 1 ip from 10.0.0.0/8 to any via ng* in

00530 fwd ххх.ххх.ххх.ххх ip from ххх.ххх.ххх.ххх to not ххх.ххх.ххх.0/23

А оптимизировать эти правила не пробовали ?

via ng* in - жрет намного больше чем via inet0 out

Для каких целей fwd используете ? Неужели route add отменили ? ;)

 

натить сразу 10/8 в один адрес - круто. Помогает поднять несколько нат и натить каждую /24 в свой белый адрес.

00630 netgraph 23 ip from any to any in via inet0 - тоже красиво. Сквозь это правило проходит ВЕСЬ входящий трафик.

Что мешает поменять на 00630 netgraph 23 ip from any to me in via inet0 ?

Спасибо за советы. Будем пробывать :)

Share this post


Link to post
Share on other sites

Образовалась интересная тема при вводе очередного сервера доступа. Как обычно берем топовый core i7 и двухпортовку на драйвере igb. loader.conf и sysctl.conf переносим с сервера доступа, который настраивали последним и в бой.

 

Но не все так гладко пошло. Во первых впервые была установлена (в связи с релизом) 7.4-RELEASE (на соседнем сервере стоит еще 7.3-RELEASE), глюки:

 

- ребуты либо во времена малой активности, либо в пик (последний page fault показал current process 28 ng_queue10)

- выставление в лоадере hw.igb.rxd="2048" и hw.igb.txd="2048" приводит к неработающей сетке (пришлось убрать)

 

Для сравнения топы во времена низкой загрузки на серваке с 7.3 (где всё ок) и на серваке с 7.4)

 

7.3

 

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   15 root        1 171 ki31     0K     8K CPU7    7 1907.9 100.00% idle: cpu7
   17 root        1 171 ki31     0K     8K CPU5    5 1900.3 100.00% idle: cpu5
   13 root        1 171 ki31     0K     8K CPU9    9 1879.9 100.00% idle: cpu9
   12 root        1 171 ki31     0K     8K CPU10  10 1876.0 100.00% idle: cpu10
   16 root        1 171 ki31     0K     8K CPU6    6 1821.2 100.00% idle: cpu6
   21 root        1 171 ki31     0K     8K RUN     1 1901.8 98.14% idle: cpu1
   11 root        1 171 ki31     0K     8K CPU11  11 1890.7 96.63% idle: cpu11
   18 root        1 171 ki31     0K     8K CPU4    4 1807.0 95.41% idle: cpu4
   19 root        1 171 ki31     0K     8K CPU3    3 1887.1 94.97% idle: cpu3
   20 root        1 171 ki31     0K     8K CPU2    2 1727.5 90.58% idle: cpu2
   22 root        1 171 ki31     0K     8K CPU0    0 1667.4 85.89% idle: cpu0
   14 root        1 171 ki31     0K     8K CPU8    8 1354.7 69.58% idle: cpu8
   59 root        1 -68    -     0K     8K CPU8    8 667.8H 29.74% irq266: igb1
   55 root        1 -68    -     0K     8K WAIT    2 130.7H  6.54% irq263: igb0
    9 root        1 -68    -     0K     8K sleep   9  89.5H  3.47% ng_queue7
    2 root        1 -68    -     0K     8K sleep   3  89.6H  3.37% ng_queue0
    7 root        1 -68    -     0K     8K sleep   6  89.6H  3.32% ng_queue5
   61 root        1 -68    -     0K     8K -       2  45.3H  3.32% igb1 taskq
    3 root        1 -68    -     0K     8K sleep  11  89.6H  3.22% ng_queue1
    4 root        1 -68    -     0K     8K sleep   6  89.6H  3.22% ng_queue2
   29 root        1 -68    -     0K     8K sleep   1  89.5H  3.22% ng_queue11
    8 root        1 -68    -     0K     8K sleep   0  89.5H  3.22% ng_queue6
   27 root        1 -68    -     0K     8K sleep   0  89.6H  3.12% ng_queue9
    6 root        1 -68    -     0K     8K sleep   7  89.6H  3.12% ng_queue4
   28 root        1 -68    -     0K     8K sleep  10  89.5H  3.12% ng_queue10
   26 root        1 -68    -     0K     8K sleep   8  89.5H  2.88% ng_queue8
    5 root        1 -68    -     0K     8K sleep   4  89.6H  2.83% ng_queue3
   54 root        1 -68    -     0K     8K WAIT    0  35.1H  2.05% irq262: igb0
   57 root        1 -68    -     0K     8K -       2  32.5H  1.90% igb0 taskq
   58 root        1 -68    -     0K     8K WAIT    2  27.0H  1.22% irq265: igb1
1139 root        2  44    0 61116K 53284K select  4   0:00  1.07% mpd5
   24 root        1 -32    -     0K     8K WAIT    9  40.8H  0.73% swi4: clock sio

 

7.4

 

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   12 root        1 171 ki31     0K     8K CPU10  10 130:13 100.00% idle: cpu10
   11 root        1 171 ki31     0K     8K CPU11  11 130:11 100.00% idle: cpu11
   13 root        1 171 ki31     0K     8K CPU9    9 130:10 100.00% idle: cpu9
   14 root        1 171 ki31     0K     8K CPU8    8 130:09 100.00% idle: cpu8
   20 root        1 171 ki31     0K     8K CPU2    2 128:15 100.00% idle: cpu2
   22 root        1 171 ki31     0K     8K CPU0    0 126:17 100.00% idle: cpu0
   16 root        1 171 ki31     0K     8K CPU6    6 129:34 99.17% idle: cpu6
   19 root        1 171 ki31     0K     8K CPU3    3 129:33 99.17% idle: cpu3
   15 root        1 171 ki31     0K     8K CPU7    7 129:41 99.07% idle: cpu7
   17 root        1 171 ki31     0K     8K CPU5    5 129:28 98.39% idle: cpu5
   18 root        1 171 ki31     0K     8K CPU4    4 129:05 98.10% idle: cpu4
   21 root        1 171 ki31     0K     8K RUN     1 129:11 97.75% idle: cpu1
   65 root        1 -68    -     0K     8K WAIT    1   0:45  1.17% irq266: igb1
   67 root        1 -68    -     0K     8K WAIT    2   0:32  1.17% irq267: igb1
   63 root        1 -68    -     0K     8K WAIT    0   0:51  0.98% irq265: igb1
   71 root        1 -68    -     0K     8K WAIT    4   0:43  0.78% irq269: igb1
   73 root        1 -68    -     0K     8K WAIT    5   0:37  0.78% irq270: igb1
   77 root        1 -68    -     0K     8K WAIT    7   0:34  0.68% irq272: igb1
   46 root        1 -68    -     0K     8K WAIT    0   0:32  0.59% irq256: igb0
   75 root        1 -68    -     0K     8K WAIT    6   0:39  0.39% irq271: igb1
   69 root        1 -68    -     0K     8K WAIT    3   0:34  0.39% irq268: igb1
   48 root        1 -68    -     0K     8K WAIT    1   0:18  0.10% irq257: igb0
   56 root        1 -68    -     0K     8K WAIT    5   0:16  0.10% irq261: igb0
   24 root        1 -32    -     0K     8K WAIT    6   0:41  0.00% swi4: clock sio
    2 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue0
   28 root        1 -68    -     0K     8K sleep   2   0:24  0.00% ng_queue10
    6 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue4
   26 root        1 -68    -     0K     8K sleep   8   0:24  0.00% ng_queue8
   27 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue9
    4 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue2
    9 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue7
    5 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue3
    8 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue6
    3 root        1 -68    -     0K     8K sleep   0   0:24  0.00% ng_queue1
    7 root        1 -68    -     0K     8K sleep   2   0:24  0.00% ng_queue5
   29 root        1 -68    -     0K     8K sleep   2   0:24  0.00% ng_queue11
   47 root        1 -68    -     0K     8K -       4   0:11  0.00% igb0 que
   52 root        1 -68    -     0K     8K WAIT    3   0:11  0.00% irq259: igb0
   34 root        1 -16    -     0K     8K -      11   0:10  0.00% yarrow
   60 root        1 -68    -     0K     8K WAIT    7   0:10  0.00% irq263: igb0
   50 root        1 -68    -     0K     8K WAIT    2   0:06  0.00% irq258: igb0
   54 root        1 -68    -     0K     8K WAIT    4   0:05  0.00% irq260: igb0
   58 root        1 -68    -     0K     8K WAIT    6   0:04  0.00% irq262: igb0
   64 root        1 -68    -     0K     8K -       4   0:02  0.00% igb1 que

 

Больше всего напрягает невозможность выставить повышенный hw.igb.rxd. Погуглил это про 7.4 - ничего найти не удалось. Кроме обновления до STABLE в голову ничего не идёт.

 

Share this post


Link to post
Share on other sites
- ребуты либо во времена малой активности, либо в пик (последний page fault показал current process 28 ng_queue10)

На днях Глеб в r219827 исправил (вроде как) ошибки, приводящие к зависанию системы при удалении интерфейсов.

 

Share this post


Link to post
Share on other sites
- ребуты либо во времена малой активности, либо в пик (последний page fault показал current process 28 ng_queue10)

На днях Глеб в r219827 исправил (вроде как) ошибки, приводящие к зависанию системы при удалении интерфейсов.

Тем временем мы нашли как через сисктл поднять процессинг лимит на igb и сделали 2048:

 

dev.igb.0.rx_processing_limit=2048

 

И еще некоторые sysctl ввели для нетграфа и для сетевой подсистемы.

 

Теперь изменения Глеба должны появиться в RELENG? Пока помониторим текущее состояние дел.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this