_longhorn_ Опубликовано 28 марта, 2010 · Жалоба где этот процесс показывает, что полинг работает на одном ядре? Могу только посоветовать по-больше читать, на этом форуме все уже давно разжевано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 28 марта, 2010 · Жалоба где этот процесс показывает, что полинг работает на одном ядре?Могу только посоветовать по-больше читать, на этом форуме все уже давно разжевано. Значит еще раз разжую.Этот процесс отвечает за прерывания сетевух. Поллинг принимает эти прерывания и когда освобождается одно из ядер, передает этот процесс ядру Если вы заметите, то этот процесс передает не одному ядру, а тому которое на данный момен свободное. По поводу других жеваний, вижу только одно: попробывал не пошло, буду ждать когда другие попробуют. Полинг работае в SMP уже с 5 версии, до этого он через sysctl запускался, теперь через ifconfig. Просто информацию надо читать посвежей. Если я не прав, поправьте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 29 марта, 2010 · Жалоба Если я не прав, поправьте. Какая разница как включается поллинг? Хоть через сисктл, хоть через ифконфиг, всеравно он использует только одно ядро. Если планируете нагружать этот комп, я бы посоветовал задуматься уже сейчас, чтобы не кусать локти потом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 29 марта, 2010 (изменено) · Жалоба Если я не прав, поправьте.Какая разница как включается поллинг? Хоть через сисктл, хоть через ифконфиг, всеравно он использует только одно ядро. Если планируете нагружать этот комп, я бы посоветовал задуматься уже сейчас, чтобы не кусать локти потом. Так в том то и дело два одинаковых сервака если вы читали выше с яндекс дровами грузил одно ядро при нагрузке до 100%и кусали локти именно тогда, когда канал падал раз в 10 и пинги выростали до 200-600мс. с полингом и родными дровами при нагрузке все ядра распределяются равномерно и никаких тормозов нет уже 4-й день. И не понятно откуда вы берете что поллинг работает с одним ядром? Вы хоть смотрите top -PS ? Изменено 29 марта, 2010 пользователем wsimons Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 29 марта, 2010 · Жалоба Вы хоть смотрите top -PS ? Я смотрю, и вижу, что у вас вся сетевая подсистема работает на одном ядре. А что видите Вы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 29 марта, 2010 · Жалоба Вы хоть смотрите 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 29 марта, 2010 · Жалоба Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним. Он работает со всеми ядрами, но не параллельно, а по очереди. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 29 марта, 2010 (изменено) · Жалоба Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.Он работает со всеми ядрами, но не параллельно, а по очереди. Так очредность - это что одно ядро?В freebsd почти все процессы так и работают и не только в freebsd кстати с яндекс дровами этот процесс работает точно так же. яндекс дрова его не распараллеливает. конечно же там принцип другой по передаче прерываний, но он не решает проблем с ng, а вот поллинг эти проблемы решает превосходно, распределяя нагрузку ядер равномерно. Изменено 29 марта, 2010 пользователем wsimons Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bsdelnik Опубликовано 29 марта, 2010 · Жалоба Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.Он работает со всеми ядрами, но не параллельно, а по очереди. Так очредность - это что одно ядро?В freebsd почти все процессы так и работают и не только в freebsd кстати с яндекс дровами этот процесс работает точно так же. яндекс дрова его не распараллеливает. конечно же там принцип другой по передаче прерываний, но он не решает проблем с ng, а вот поллинг эти проблемы решает превосходно, распределяя нагрузку ядер равномерно. У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 29 марта, 2010 (изменено) · Жалоба Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.Он работает со всеми ядрами, но не параллельно, а по очереди. Так очредность - это что одно ядро?В freebsd почти все процессы так и работают и не только в freebsd кстати с яндекс дровами этот процесс работает точно так же. яндекс дрова его не распараллеливает. конечно же там принцип другой по передаче прерываний, но он не решает проблем с ng, а вот поллинг эти проблемы решает превосходно, распределяя нагрузку ядер равномерно. У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено. Именно это я и описываю. Только вот яндекс дрова некоректно распределяют нагрузку в SMPНо несколькими постами выше было описано (не мной), что поллинг работает на одном ядре. Вот это я опровергаю, а не то что как работает данный процесс. Изменено 29 марта, 2010 пользователем wsimons Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zohan Опубликовано 29 марта, 2010 · Жалоба Вы видете один процесс, но не видете, что он работает со всеми ядрами, а не с одним.Он работает со всеми ядрами, но не параллельно, а по очереди. Так очредность - это что одно ядро?В freebsd почти все процессы так и работают и не только в freebsd кстати с яндекс дровами этот процесс работает точно так же. яндекс дрова его не распараллеливает. конечно же там принцип другой по передаче прерываний, но он не решает проблем с ng, а вот поллинг эти проблемы решает превосходно, распределяя нагрузку ядер равномерно. У вас, простите, в голове каша. Яндексовые дрова параллелятся по нескольким процам, и занимаются обработкой прерываний от сетевушки, передавая пакеты в сетевой стек. swi:net - это внутренний обработчик пакетов чуть более высокого уровня, который работает при net.isr.direct=0. С яндексовскими дровами это дело не дружит. Причем на семерке - swi:net - один процесс, в восьмерке оно уже тоже распараллелено. Именно это я и описываю. Только вот яндекс дрова некоректно распределяют нагрузку в SMPНо несколькими постами выше было описано (не мной), что поллинг работает на одном ядре. Вот это я опровергаю, а не то что как работает данный процесс. Может уже на 7.3-Release перейдем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 29 марта, 2010 · Жалоба поллинг работает на одном ядре Вы наверно не понимаете главного. При поллинге вся сетевая подсистема в единый момент времени обрабатывается ОДНИМ ядром. Я уже не знаю как Вам объяснить столь очевидные вещи. Насчет яндексов у Вас вообще, как я понимаю, свой взгляд на Мир. У всех они работают прекрасно, а Вам не угодили. Если у других все хорошо стоит поискать проблему у себя. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UTP Опубликовано 29 марта, 2010 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 29 марта, 2010 · Жалоба поллинг работает на одном ядреНасчет яндексов у Вас вообще, как я понимаю, свой взгляд на Мир. У всех они работают прекрасно, а Вам не угодили. Если у других все хорошо стоит поискать проблему у себя. На счет яндекс дров у меня понимание такое же как и у всех. Только не стоит говорить за всех, что они везде работают прекрасно. Советую вам на форумах почитать как они работают у многих. Вот теперь скажите мне wsimons, почему у меня процесс ng_queue совсем не грузит систему.Почему работают яндекс драйвера, и таки работают в классическом понимании SMP(а не в вашем) что я делаю не так? У вас нат на нем работает? Думаю что нет. Иначе показания бы ng_queue были бы далеко не 0%.Ну мне до сих пор никто здесь не объяснил, что я делаю не так, что этот процесс грузит время от времени одно ядро на 100%, остальные все свободные. Точнее предложения были, но они проблему не решили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UTP Опубликовано 30 марта, 2010 · Жалоба У вас нат на нем работает? Думаю что нет 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 31 марта, 2010 · Жалоба wsimsons, а что используется в качесте ната? ng_nat/ipfw nat? И как трафик в него заворачивается? И что еще на нетграфе крутится? `ngctl types` В том, что не сильно различающиеся конфигурации могут работать соверешенно по разному, нет ничего особенного. Совсем недавно, кстати, в freebsd-net поднимали теуа с проблемами масштабируемости в связке ng_ipfw+ng_nat: http://lists.freebsd.org/pipermail/freebsd...ary/024357.html PS: с "яндексовскими" драйверами у меня тоже были проблемы на тестовых машинах. Считаю, что их не стоит ставить без необходимости. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 31 марта, 2010 · Жалоба UTP мне непонятно вы хотите показать как у вас все замечательно, _longhorn_ вы рассказываете как работает процесс swi1. А я хочу узнать почему загружается ng_queue на одном ядре на 100%, когда на остальных ядрах нет превышения 5%. И это на двух одинаковых машинах. Кстати на одной родные дрова em и polling, на другой яндек дрова. Если не знаете что ответить не надо заниматся флудом. Если я себе поставлю машину 2015г выпуска, то у меня вопрос отпадет сам по себе. Но мне непонятно, почему здесь на форуме пишут, что у них по 400 пользователей на серваке при этом 700Kpps и более, 600-700Мбит занятого канала. Просто какая то сказка. Или интернет стали раздавать без ограничений? Ну как не стремился раздать побольше, но при колличестве хомяков в 1400 больше 300 Мбит канал не поднимался. При всем этом никто не жалуется, что скорость зажимается. Проблему конечно решаем, но неправильно, точнее не решение проблеммы. Вместо того, чтобы всех держала 1 машина, держит 4. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 31 марта, 2010 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 31 марта, 2010 · Жалоба iface 122 Это явно в момент минимальной загрузки. Еще не помешает статистика vmstat -z | fgrep NetGraph и vmstat -m | fgrep netgraph На 7.3 стоит попробовать ipfw nat. У ng_netflow уменьшить таймауты, раза в 3. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 31 марта, 2010 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lucky SB Опубликовано 31 марта, 2010 · Жалоба 00230 netgraph 5 ip from ххх.ххх.ххх.0/23 to any via ng* in00330 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Мбит занятого канала. Просто какая то сказка. Или интернет стали раздавать без ограничений?а головой подумать ?Там же москвичи, у них тарифы на порядок скоростнее, ната нету, шейпер на отдельной машине... Проблему конечно решаем, но неправильно, точнее не решение проблеммыЧитайте форум, маны - в твоем конфиге бездна потенциала для оптимизации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wsimons Опубликовано 31 марта, 2010 · Жалоба 00230 netgraph 5 ip from ххх.ххх.ххх.0/23 to any via ng* in00330 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 ? Спасибо за советы. Будем пробывать :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 22 марта, 2011 · Жалоба Образовалась интересная тема при вводе очередного сервера доступа. Как обычно берем топовый 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 в голову ничего не идёт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Сильвер Опубликовано 22 марта, 2011 · Жалоба - ребуты либо во времена малой активности, либо в пик (последний page fault показал current process 28 ng_queue10) На днях Глеб в r219827 исправил (вроде как) ошибки, приводящие к зависанию системы при удалении интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 22 марта, 2011 · Жалоба - ребуты либо во времена малой активности, либо в пик (последний page fault показал current process 28 ng_queue10) На днях Глеб в r219827 исправил (вроде как) ошибки, приводящие к зависанию системы при удалении интерфейсов. Тем временем мы нашли как через сисктл поднять процессинг лимит на igb и сделали 2048: dev.igb.0.rx_processing_limit=2048 И еще некоторые sysctl ввели для нетграфа и для сетевой подсистемы. Теперь изменения Глеба должны появиться в RELENG? Пока помониторим текущее состояние дел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...