[_longhorn_]

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

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

[wsimons]

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

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

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

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

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

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

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

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

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

[_longhorn_]

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

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

[wsimons]

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

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

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

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

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

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

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

Изменено 29 марта, 2010 пользователем wsimons

[_longhorn_]

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

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

[wsimons]

Вы хоть смотрите 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

 

 

[_longhorn_]

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

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

[wsimons]

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

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

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

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

и не только в freebsd

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

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

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

Изменено 29 марта, 2010 пользователем wsimons

[bsdelnik]

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

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

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

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

и не только в freebsd

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

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

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

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

[wsimons]

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

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

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

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

и не только в freebsd

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

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

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

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

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

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

Изменено 29 марта, 2010 пользователем wsimons

[Zohan]

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

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

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

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

и не только в freebsd

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

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

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

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

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

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

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

 

[_longhorn_]

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

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

[UTP]

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(а не в вашем)

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

Изменено 29 марта, 2010 пользователем UTP

[wsimons]

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

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

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

 

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

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

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

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

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

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

[UTP]

У вас нат на нем работает? Думаю что нет

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

 

[littlesavage]

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

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

 

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

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

 

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

[wsimons]

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

[wsimons]

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 и ничего страшного не происходит.

Изменено 31 марта, 2010 пользователем wsimons

[littlesavage]

iface 122

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

 

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

 

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

 

 

 

[wsimons]

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

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

Изменено 31 марта, 2010 пользователем wsimons

[Lucky SB]

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Мбит занятого канала. Просто какая то сказка. Или интернет стали раздавать без ограничений?

а головой подумать ?

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

Проблему конечно решаем, но неправильно, точнее не решение проблеммы

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

 

[wsimons]

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 ?

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

[kaN5300]

Образовалась интересная тема при вводе очередного сервера доступа. Как обычно берем топовый 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 в голову ничего не идёт.

 

[Сильвер]

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

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

 

[kaN5300]

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

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

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

 

dev.igb.0.rx_processing_limit=2048

 

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

 

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