Re: [freebsd] em, input errors and kernel load
Hello, Vadim Goncharov!
On Sat, Mar 19, 2011 at 01:18:13AM +0600
vadimnucli...@tpu.ru wrote about "Re: [freebsd] em, input errors and kernel
load":
> 18.03.11 @ 21:45 Alexey Karguine wrote:
>
>
> >>Ну так vmstat вышеуказанный-то где?
> >>
> >Только что был очередной приступ. vmstat -{zm} сделать успел. Результат
> >в приложенных файлах. Посмотрите пожалуйста, сам я в эти цифрахникогда
> >не разберусь.
>
> В vmstat -z ничего такого нет, кроме большого числа кэша vnode (к 82000
> файлов обращались), да еще строки:
>
> 128:128,0, 137977,50663, 107517508,0
>
> которую проясняет vmstat -m:
>
> Type InUse MemUse HighUse Requests Size(s)
> libalias 137337 17231K - 107197469 128
>
> Число не ахти какое большое, но больше ничего подозрительного в vmstat
> -m/-z нет.
>
> >>Это программная проблема, taskq уже не в hardware interrupt крутится,
> >>так что не поможет.
> >>
> >>http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
> >>
> >>- пересобрать ядро по инструкции отсюда, попробовать остальные шаги во
> >>время затыка.
> >
> >Сделал. Чтобы не поднимать трафик в рассылке файл с выходными данными
> >(~290 килобайт) выложил тут: http://dl.dropbox.com/u/83258/hwpmc.txt
> >
> >Делал так:
> >- во время затыка запустил pmcstat -S instructions -O /tmp/sample.out
> >- нажал ctrl-c после того, как затык прошёл. Получил такое вообщение в
> >консоле:
> >pmcstat: WARNING: some events were discarded. Please consider tuning
> >the "kern.hwpmc.nbuffers" tunable.
> >- pmcstat -R /tmp/sample.out -k /boot/kernel/kernel -g
> >- gprof /boot/kernel/kernel /tmp/INSTR_RETIRED_ANY/kernel.gmon
>
> Да в общем-то можно было не выкладывать, там самое главное в строчках
> Top-5 пожирателей времени (80% времени в сумме):
>
> % cumulative self self total
> time seconds secondscalls ms/call ms/call name
> 36.9 233576.00 233576.00 3080 75836.36 76859.98 sched_idletd [9]
> 28.2 411599.00 178023.00 799402 222.70 222.70 _mtx_lock_sleep [11]
> 11.8 485951.00 74352.00 252 295047.62 296047.62 _FindLinkIn [16]
> 2.1 499405.00 13454.00 2390 5629.29 116656.65 ipfw_chk [6]
> 1.8 510634.00 11229.0011536 973.39 1001.30 rn_match [26]
>
> Это явный lock contention (glebius@ тут считает, что если сделать ядро с
> MUTEX_PROFILING, то будет видно, что libalias лок - most contended). Там
> выше в call graph есть подтверждение:
>
> called/total parents
> index %timeself descendents called+selfnameindex
> called/total children
>
> 485.00 227154.59 678354/678354 ipfw_nat [8]
> [10]36.0 485.00 227154.59 678354 LibAliasIn [10]
> 151066.411.70 678355/799402 _mtx_lock_sleep [11]
> 1053.0075033.48 794/794 LibAliasInLocked [14]
>
> То есть, несколько тредов одновременно постоянно дерутся за доступ к
Вадим, можно мне пояснить, вернее разжевать, такое: нагрузка в emX:
taskq. Так? В первых постах топикстартер показывает свой трафик:
7-10кппс и 7-9МБс. На такой нагрузке нат как бы не должен
выпендриваться. Почему вспсплески по CPU у топикстартера получаются?
У меня более слабая машинка натила под 200мбит без проблем!
> instance ната - оно не параллелится. Решение: натить в несколько внешних
> IP-адресов, для каждого заводить отдельный инстанс libalias (ipfw nat). Я
> в свое время бил кусками по /28 (16 адресов на один внешний), исходя из
> лимитов числа соединений с адреса на торрент-трекерах, аськосерверах и т.д.
>
> Еще вариант, менее выигрышный и более сложный: пропатчить исходники, в
> /usr/src/sys/netinet/libalias/alias_local.h необходимо найти и заменить
> две константы, которые cо времен 7.1 равняются 4001. Сделать их такими:
>
> #define LINK_TABLE_OUT_SIZE8123
> #define LINK_TABLE_IN_SIZE 16411
>
> и пересобрать ядро (и при каждом обновлении исходников придется руками
> поддерживать патченым так).
--
Lystopad Olexandr
[freebsd] 6.2, fxp, alias и ping - что-то лыжи не едут. :(
Добрый день сообществу! Толкните в нужную сторону, а то лыжи что-то у меня сегодня не едут. :( Есть сетка на десяток компов и роутер FreeBSD router 6.2-STABLE FreeBSD 6.2-STABLE #0: Tue Jul 10 09:30:56 EEST 2007 root@x:/usr/obj/usr/src/sys/ROUTER i386 ifconfig fxp0 fxp0: flags=88843 mtu 1500 options=8 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 ether 00:d0:b7:9e:b5:61 media: Ethernet autoselect (100baseTX ) status: active клиенты получают адреса по dhcp, основная сетка - 192.168.0.0/24, 192.168.10.0/24 - для ввода новых машинок в сеть. В ipfw этой сетке разрешены только ping-и и ssh. Но вот "ничего не работает". Новый клиент получает адрес, но ни пинг, ни ssh не работают. :( На клиенте (XP) фаервол отключен, tcpdump на fxp0 показывает следующее: 23:34:00.075748 IP 192.168.10.247.137 > 192.168.10.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 23:34:00.826305 IP 192.168.10.247.137 > 192.168.10.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST, хотя в /var/log/security вижу такое: Mar 18 23:33:59 rodnoe kernel: ipfw: 50 Accept UDP 192.168.10.247:138 192.168.10.255:138 in via fxp0 Mar 18 23:33:59 rodnoe kernel: ipfw: 50 Accept UDP 192.168.10.247:137 192.168.10.255:137 in via fxp0 ipfw list 50 00050 allow log ip from 192.168.10.0/24 to 192.168.10.0/24 via fxp0 Куда могут деваться пакеты??? pf не пользую. Заранее спасибо за идеи
Re: [freebsd] em, input errors and kernel load
18.03.11 @ 21:45 Alexey Karguine wrote:
Ну так vmstat вышеуказанный-то где?
Только что был очередной приступ. vmstat -{zm} сделать успел. Результат
в приложенных файлах. Посмотрите пожалуйста, сам я в эти цифрахникогда
не разберусь.
В vmstat -z ничего такого нет, кроме большого числа кэша vnode (к 82000
файлов обращались), да еще строки:
128:128,0, 137977,50663, 107517508,0
которую проясняет vmstat -m:
Type InUse MemUse HighUse Requests Size(s)
libalias 137337 17231K - 107197469 128
Число не ахти какое большое, но больше ничего подозрительного в vmstat
-m/-z нет.
Это программная проблема, taskq уже не в hardware interrupt крутится,
так что не поможет.
http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
- пересобрать ядро по инструкции отсюда, попробовать остальные шаги во
время затыка.
Сделал. Чтобы не поднимать трафик в рассылке файл с выходными данными
(~290 килобайт) выложил тут: http://dl.dropbox.com/u/83258/hwpmc.txt
Делал так:
- во время затыка запустил pmcstat -S instructions -O /tmp/sample.out
- нажал ctrl-c после того, как затык прошёл. Получил такое вообщение в
консоле:
pmcstat: WARNING: some events were discarded. Please consider tuning
the "kern.hwpmc.nbuffers" tunable.
- pmcstat -R /tmp/sample.out -k /boot/kernel/kernel -g
- gprof /boot/kernel/kernel /tmp/INSTR_RETIRED_ANY/kernel.gmon
Да в общем-то можно было не выкладывать, там самое главное в строчках
Top-5 пожирателей времени (80% времени в сумме):
% cumulative self self total
time seconds secondscalls ms/call ms/call name
36.9 233576.00 233576.00 3080 75836.36 76859.98 sched_idletd [9]
28.2 411599.00 178023.00 799402 222.70 222.70 _mtx_lock_sleep [11]
11.8 485951.00 74352.00 252 295047.62 296047.62 _FindLinkIn [16]
2.1 499405.00 13454.00 2390 5629.29 116656.65 ipfw_chk [6]
1.8 510634.00 11229.0011536 973.39 1001.30 rn_match [26]
Это явный lock contention (glebius@ тут считает, что если сделать ядро с
MUTEX_PROFILING, то будет видно, что libalias лок - most contended). Там
выше в call graph есть подтверждение:
called/total parents
index %timeself descendents called+selfnameindex
called/total children
485.00 227154.59 678354/678354 ipfw_nat [8]
[10]36.0 485.00 227154.59 678354 LibAliasIn [10]
151066.411.70 678355/799402 _mtx_lock_sleep [11]
1053.0075033.48 794/794 LibAliasInLocked [14]
То есть, несколько тредов одновременно постоянно дерутся за доступ к
instance ната - оно не параллелится. Решение: натить в несколько внешних
IP-адресов, для каждого заводить отдельный инстанс libalias (ipfw nat). Я
в свое время бил кусками по /28 (16 адресов на один внешний), исходя из
лимитов числа соединений с адреса на торрент-трекерах, аськосерверах и т.д.
Еще вариант, менее выигрышный и более сложный: пропатчить исходники, в
/usr/src/sys/netinet/libalias/alias_local.h необходимо найти и заменить
две константы, которые cо времен 7.1 равняются 4001. Сделать их такими:
#define LINK_TABLE_OUT_SIZE8123
#define LINK_TABLE_IN_SIZE 16411
и пересобрать ядро (и при каждом обновлении исходников придется руками
поддерживать патченым так).
--
WBR, Vadim Goncharov
Re: [freebsd] em, input errors and kernel load
On Mar 18, 2011, at 9:57 AM, Vadim Goncharov wrote: > Это программная проблема, taskq уже не в hardware interrupt крутится, так что > не поможет. > > http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html > - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время > затыка. Сделал. Чтобы не поднимать трафик в рассылке файл с выходными данными (~290 килобайт) выложил тут: http://dl.dropbox.com/u/83258/hwpmc.txt Делал так: - во время затыка запустил pmcstat -S instructions -O /tmp/sample.out - нажал ctrl-c после того, как затык прошёл. Получил такое вообщение в консоле: pmcstat: WARNING: some events were discarded. Please consider tuning the "kern.hwpmc.nbuffers" tunable. - pmcstat -R /tmp/sample.out -k /boot/kernel/kernel -g - gprof /boot/kernel/kernel /tmp/INSTR_RETIRED_ANY/kernel.gmon Alexey Karguine alexeykargu...@me.com
Re: [freebsd] em, input errors and kernel load
2011/3/18 Lystopad Olexandr :
> Hello, Alex Belinsky!
>
>> Ещё раз напоминаю о яндексовских дровах. tasq можно раскидать по разным
>> ядрам.
>> Вот так
>> 0 root -68 0 0K 112K - 7 84.1H 19.19% {em2 taskq}
>> 0 root 50 0 0K 112K CPU3 3 48.8H 15.38% {em0_rx0_3}
>> 0 root 50 0 0K 112K WAIT 2 48.7H 11.67% {em0_rx0_0}
>> 0 root 52 0 0K 112K WAIT 4 48.7H 11.18% {em0_rx0_2}
>> 0 root 44 0 0K 112K WAIT 1 48.8H 5.18% {em0_rx0_1}
>> em2 дюже древняя, поэтому дровишки её держат в legacy mode. А с em0 и
>> em1 все красиво и спокойно.
>
> топикстартер в начале писал:
>
> : Это при том, обычно загрузка интерфейса выглядит так:
> :
> : input (em1) output
> : packets errs idrops bytes packets errs bytes colls
> : 7601 0 0 6361116 7816 0 3323030 0
> : 7807 0 0 6445254 8628 0 3683657 0
> : 7581 0 0 6446709 7844 0 3352021 0
> : 6385 0 0 5257225 6692 0 3238119 0
>
> при такой нагрузке даже rl1 должна молча жевать такой трафик, а не захватывать
> процессор!
>
> imho, яндексовские драйвера не помогут в этом случае.
>
Саша, ты суслика видишь? И я не вижу. А он есть.
Выпиливание flowtable из ядра и яндексовые дрова вылечили смертельно
раненную зебру. Шаманство, не?
> --
> Lystopad Olexandr
>
--
wbr, Alex
fozz-ripe
Re: [freebsd] em, input errors and kernel load
Hello, Alex Belinsky!
> Ещё раз напоминаю о яндексовских дровах. tasq можно раскидать по разным
> ядрам.
> Вот так
>0 root -680 0K 112K - 7 84.1H 19.19% {em2 taskq}
> 0 root 500 0K 112K CPU33 48.8H 15.38% {em0_rx0_3}
> 0 root 500 0K 112K WAIT2 48.7H 11.67% {em0_rx0_0}
> 0 root 520 0K 112K WAIT4 48.7H 11.18% {em0_rx0_2}
> 0 root 440 0K 112K WAIT1 48.8H 5.18% {em0_rx0_1}
> em2 дюже древняя, поэтому дровишки её держат в legacy mode. А с em0 и
> em1 все красиво и спокойно.
топикстартер в начале писал:
: Это при том, обычно загрузка интерфейса выглядит так:
:
: input (em1) output
:packets errs idrops bytespackets errs bytes colls
: 7601 0 06361116 7816 03323030 0
: 7807 0 06445254 8628 03683657 0
: 7581 0 06446709 7844 03352021 0
: 6385 0 05257225 6692 03238119 0
при такой нагрузке даже rl1 должна молча жевать такой трафик, а не захватывать
процессор!
imho, яндексовские драйвера не помогут в этом случае.
--
Lystopad Olexandr
Re: [freebsd] em, input errors and kernel load
2011/3/18 Alexey Karguine :
>
> On Mar 18, 2011, at 9:57 AM, Vadim Goncharov wrote:
>
>> 17.03.11 @ 23:16 Alexey Karguine wrote:
>>
>>
>> Ну так vmstat вышеуказанный-то где?
>>
> Только что был очередной приступ. vmstat -{zm} сделать успел. Результат в
> приложенных файлах. Посмотрите пожалуйста, сам я в эти цифрах никогда не
> разберусь.
>
>
>>
>> Это программная проблема, taskq уже не в hardware interrupt крутится, так
>> что не поможет.
>>
>> http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
>> - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время
>> затыка.
>
> Это ещё не пробовал. Ядро уже пересобранное, но т.к. машина боевая, ребутнуть
> её получится только ближе к вечеру. После этого буду ждать очередного
> приступа.
>
>
Ещё раз напоминаю о яндексовских дровах. tasq можно раскидать по разным ядрам.
Вот так
0 root -680 0K 112K - 7 84.1H 19.19% {em2 taskq}
0 root 500 0K 112K CPU33 48.8H 15.38% {em0_rx0_3}
0 root 500 0K 112K WAIT2 48.7H 11.67% {em0_rx0_0}
0 root 520 0K 112K WAIT4 48.7H 11.18% {em0_rx0_2}
0 root 440 0K 112K WAIT1 48.8H 5.18% {em0_rx0_1}
em2 дюже древняя, поэтому дровишки её держат в legacy mode. А с em0 и
em1 все красиво и спокойно.
>
>
>
> Alexey Karguine
> alexeykargu...@me.com
>
>
>
>
>
>
>
--
wbr, Alex
Re: [freebsd] em, input errors and kernel load
On Mar 18, 2011, at 9:57 AM, Vadim Goncharov wrote:
> 17.03.11 @ 23:16 Alexey Karguine wrote:
>
>
> Ну так vmstat вышеуказанный-то где?
>
Только что был очередной приступ. vmstat -{zm} сделать успел. Результат в
приложенных файлах. Посмотрите пожалуйста, сам я в эти цифрах никогда не
разберусь.
>
> Это программная проблема, taskq уже не в hardware interrupt крутится, так что
> не поможет.
>
> http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
> - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время
> затыка.
Это ещё не пробовал. Ядро уже пересобранное, но т.к. машина боевая, ребутнуть
её получится только ближе к вечеру. После этого буду ждать очередного приступа.
ITEM SIZE LIMIT USED FREE REQUESTS FAILURES
UMA Kegs: 128,0, 87,3, 87,0
UMA Zones:888,0, 87,1, 87,0
UMA Slabs:284,0, 1064,0, 1515,0
UMA RCntSlabs:544,0, 2013,3, 2013,0
UMA Hash: 128,0,3, 27,4,0
16 Bucket: 76,0, 65, 35, 86,0
32 Bucket:140,0, 75,9, 96,0
64 Bucket:268,0, 100, 12, 146, 14
128 Bucket: 524,0, 2006,3, 2782, 112
VM OBJECT:136,0,62368, 359, 1012226,0
MAP: 140,0,7, 21,7,0
KMAP ENTRY:72,87450, 25, 240,32432,0
MAP ENTRY: 72,0, 1252, 550, 1698704,0
DP fakepg: 72,0,0,0,0,0
SG fakepg: 72,0,0,0,0,0
mt_zone: 2056,0, 224,0, 224,0
16:16,0, 2864, 384, 1425809,0
32:32,0, 3374, 9734, 656968,0
64:64,0, 5009, 5198, 1414489,0
128: 128,0, 137977,50663, 107517508,0
256: 256,0, 505, 4400, 148584,0
512: 512,0, 310, 50, 118860,0
1024:1024,0, 32, 128,13866,0
2048:2048,0, 230, 684, 1034,0
4096:4096,0, 99, 62,71969,0
Files: 56,0, 142, 394, 2054159,0
TURNSTILE: 72,0, 171, 39, 171,0
umtx pi: 52,0,0,0,0,0
MAC labels:20,0,0,0,0,0
PROC: 680,0, 61, 71,62959,0
THREAD: 720,0, 152, 18, 152,0
SLEEPQUEUE:44,0, 171, 124, 171,0
VMSPACE: 232,0, 45, 108,62942,0
cpuset:40,0,2, 182,2,0
audit_record: 816,0,0,0,0,0
mbuf_packet: 256,0, 2050, 1790, 3081503589,0
mbuf: 256,0,1, 524, 3050161074,0
mbuf_cluster:2048,25600, 3840,6, 3840,0
mbuf_jumbo_page: 4096,12800,0, 90,45345,0
mbuf_jumbo_9k: 9216, 6400,0,0,0,0
mbuf_jumbo_16k: 16384, 3200,0,0,0,0
mbuf_ext_refcnt:4,0,0,0,0,0
g_bio:140,0,0, 5768, 890323,0
ttyinq: 152,0, 180, 80, 540,0
ttyoutq: 256,0, 96, 39, 288,0
ata_request: 204,0,0, 1482, 222593,0
ata_composite:180,0,0,0,0,0
VNODE:268,0,83002, 228, 630932,0
VNODEPOLL: 60,0,0,0,0,0
S VFS Cache: 72,0,68976,11054, 663200,0
L VFS Cache: 292,0,19564, 3537,50990,0
NAMEI: 1024,0,0, 36, 4348934,0
NFSMOUNT:
Re: [freebsd] em, input errors and kernel load
On Mar 18, 2011, at 9:57 AM, Vadim Goncharov wrote:
> 17.03.11 @ 23:16 Alexey Karguine wrote:
>
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
0 root 10 -680 0K72K - 0 7:01 200.00% kernel
>>> Судя по kernel, это 8-ка, хотя надо было указывать uname -a явно. На ней
>>> оно объединяет треды, надо указывать top -SH.
>>>
Если нужны ещё какие-то данные, с удовольствием их предоставлю.
>>>
>>> Полезен еще vmstat -m и vmstat -z. Хотя я на 99% уверен, что это окажется
>>> flowcleaner (лечится выпиливанием из ядра FLOWTABLE).
>>
>> Да, извините, забыл указать uname. Это 8.2:
>
> Ну так vmstat вышеуказанный-то где?
Если честно, то не успел. Припадок закончился быстрее. Сижу, жду следующего.
Обидно то, что я не знаю, как его спровоцировать, приходится сидеть и
разглядывать вывод netstat -Iem1 -w1.
>
>> Попробовал убрать из ядра FLOWTABLE, не помогло. На момент припадка top -SHP
>> показывал следующее:
>>
>> Mem: 17M Active, 245M Inact, 278M Wired, 120K Cache, 199M Buf, 1422M Free
>> Swap: 2048M Total, 2048M Free
>>
>> PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
>>0 root -680 0K64K - 1 160:09 100.00% {em0 taskq}
>>0 root -680 0K64K CPU00 221:28 99.07% {em1 taskq}
>>
>> Подскажите плиз, чего бы ещё попробовать. У меня вариантов больше нет.
>> Сетевухи поменять на аналогичные, но новые?
>
> Это программная проблема, taskq уже не в hardware interrupt крутится, так что
> не поможет.
>
> http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
> - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время
> затыка.
Спасибо, попробую и обязательно отпишусь.
