[freebsd] em, input errors and kernel load

645 views
Skip to first unread message

Alexey Karguine

unread,
Mar 15, 2011, 1:14:33 PM3/15/11
to UaFUG
Здравствуйте!

Писал сюда недавно по поводу машины с em, натом и bgpd, которая падала в корку. Ту проблему поборол, перейдя на ipfw nat. Но появилась новая проблема.

Напомню, в машине две em-сетевухи, quagga (~750 маршрутов) и ipfw nat.

Раз в некоторое время (так и не понял зависимость возникновения проблемы от внешних факторов) начинается такая петрушка:

input (em1) output
packets errs idrops bytes packets errs bytes colls
2400 728 0 509482 2971 0 416493 0
2200 1463 0 411559 2842 0 398831 0
0 0 0 0 0 0 0 0
1500 547 0 297841 1887 0 234200 0
970 620 0 186645 1248 0 204491 0
2030 828 0 406982 2704 0 349913 0
800 0 0 148909 1002 0 137851 0
1300 767 0 268112 1677 0 224365 0
2520 1207 0 525578 3239 0 473462 0
480 0 0 87836 631 0 75961 0
1700 730 0 371454 2197 0 295217 0
900 556 0 174892 1138 0 158689 0
1500 862 0 291094 2011 0 276371 0


Это при том, обычно загрузка интерфейса выглядит так:

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
6841 0 0 5709565 7099 0 3496599 0
8349 0 0 7024005 8596 0 3875781 0
8232 0 0 6877310 8665 0 4221700 0


Наблюдал за выводом top -S в момент возникновения проблемы. Загрузка процесса kernel начинает плавно возрастать обычных 20-30 процентов до 200% (Ядро с SMP). Выглядит это так:

last pid: 1596; load averages: 10.49, 3.80, 1.52 up 0+00:13:49 19:55:28
84 processes: 18 running, 54 sleeping, 12 waiting
CPU: 0.1% user, 0.0% nice, 99.9% system, 0.1% interrupt, 0.0% idle
Mem: 21M Active, 13M Inact, 56M Wired, 104K Cache, 16M Buf, 1871M Free
Swap: 2048M Total, 2048M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
0 root 10 -68 0 0K 72K - 0 7:01 200.00% kernel
11 root 2 171 ki31 0K 16K RUN 0 20:59 0.00% idle
12 root 13 -64 - 0K 104K WAIT 0 0:03 0.00% intr
13 root 1 -16 - 0K 8K RUN 0 0:02 0.00% yarrow

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

Вывод ifconfig на всякий случай:
re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:27:0e:13:8b:a9
media: Ethernet autoselect (10baseT/UTP <half-duplex>)
status: no carrier
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
ether 00:07:e9:0b:93:30
inet 89.222.133.241 netmask 0xfffffffc broadcast 89.222.133.243
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
ether 00:07:e9:8a:1c:4a
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:07:e9:8a:1c:4a
inet 89.222.201.10 netmask 0xfffffffc broadcast 89.222.201.11
inet 89.222.133.209 netmask 0xffffffff broadcast 89.222.133.209
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 208 parent interface: em1
vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:07:e9:8a:1c:4a
inet 172.30.254.14 netmask 0xfffffffc broadcast 172.30.254.15
inet 89.222.133.210 netmask 0xffffffff broadcast 89.222.133.210
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 23 parent interface: em1

Текущий приступ можно "вылечить" выдернув кабель из сетевухи на некоторое время. Также помогает ifconfig em1 down/up.

Перекопал весь гугл, перепробовал кучу всего:
- отключать VLAN_HWTAGGING
- добавлять всяких буферов
- перешел с bsnmpd на net-snmpd (кому-то в интернетах помогло)
- менял кучу разных параметров sysctl
- пересобрал ядро с KVA_PAGES=512

Ситуация не выровнялась. Проблема так и возникает через неопределенные промежутки времени.

Куда смотреть, что делать? У меня уже скоро крыша поедет.

Сразу приведу свои несложные конфиги.

ipfw:
${fwcmd} nat 10 config ip 89.222.133.209 same_ports reset unreg_only
${fwcmd} nat 20 config ip 89.222.133.210 same_ports reset unreg_only
${fwcmd} add 1000 nat 10 all from any to any via vlan0
${fwcmd} add 2000 nat 20 all from table'(10)' to any out xmit vlan1
${fwcmd} add 2000 nat 20 all from any to 89.222.133.210 in recv vlan1

netstat -m
2049/906/2955 mbufs in use (current/cache/total)
2048/518/2566/25600 mbuf clusters in use (current/cache/total/max)
2048/512 mbuf+clusters out of packet secondary zone in use (current/cache)
0/14/14/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
4608K/1318K/5926K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/5/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Конфиг ядра (кроме стандартных для GENERIC строк):
options IPFIREWALL
options IPFIREWALL_FORWARD
options DUMMYNET
options DEVICE_POLLING
options HZ=2000
options IPFIREWALL_NAT
options LIBALIAS
options KVA_PAGES=512

vmstat -if в момент приступа и в обычное время не отличаются.

netstat -idn
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop
re0* 1500 <Link#1> 00:27:0e:13:8b:a9 0 0 0 0 0 0 0
em0 1500 <Link#2> 00:07:e9:0b:93:30 13817974 44813 0 12820388 0 0 0
em0 1500 89.222.133.24 89.222.133.241 22685 - - 22648 - - -
em1 1500 <Link#3> 00:07:e9:8a:1c:4a 13690281 162477 0 14660527 0 0 0
ipfw0 65536 <Link#4> 0 0 0 0 0 0 0
lo0 16384 <Link#5> 286 0 0 286 0 0 0
lo0 16384 fe80:5::1/64 fe80:5::1 0 - - 0 - - -
lo0 16384 ::1/128 ::1 0 - - 0 - - -
lo0 16384 127.0.0.0/8 127.0.0.1 286 - - 286 - - -
vlan0 1500 <Link#6> 00:07:e9:8a:1c:4a 10913137 0 0 11950724 0 0 0
vlan0 1500 89.222.201.8/ 89.222.201.10 91 - - 848611 - - -
vlan0 1500 89.222.133.20 89.222.133.209 892352 - - 0 - - -
vlan1 1500 <Link#7> 00:07:e9:8a:1c:4a 2776691 0 0 2709802 0 0 0
vlan1 1500 172.30.254.12 172.30.254.14 108 - - 21242 - - -
vlan1 1500 89.222.133.21 89.222.133.210 9 - - 0 - - -

Если нужны ещё какие-то данные, с удовольствием их предоставлю.

Alexey Karguine
alexeyk...@me.com

Alex Belinsky

unread,
Mar 15, 2011, 3:54:21 PM3/15/11
to Alexey Karguine, UaFUG
2011/3/15 Alexey Karguine <alexeyk...@me.com>:

> Здравствуйте!
>
> Писал сюда недавно по поводу машины с em, натом и bgpd, которая падала в корку. Ту проблему поборол, перейдя на ipfw nat. Но появилась новая проблема.
>
> Напомню, в машине две em-сетевухи, quagga (~750 маршрутов) и ipfw nat.
>
> Раз в некоторое время (так и не понял зависимость возникновения проблемы от внешних факторов) начинается такая петрушка:
>
>            input          (em1)           output
>   packets  errs idrops      bytes    packets  errs      bytes colls
>      2400   728     0     509482       2971     0     416493     0
>      2200  1463     0     411559       2842     0     398831     0
>         0     0     0          0          0     0          0     0
>      1500   547     0     297841       1887     0     234200     0
>       970   620     0     186645       1248     0     204491     0
>      2030   828     0     406982       2704     0     349913     0
>       800     0     0     148909       1002     0     137851     0
>      1300   767     0     268112       1677     0     224365     0
>      2520  1207     0     525578       3239     0     473462     0
>       480     0     0      87836        631     0      75961     0
>      1700   730     0     371454       2197     0     295217     0
>       900   556     0     174892       1138     0     158689     0
>      1500   862     0     291094       2011     0     276371     0
>
>
Нечто похожее вылечилось установкой драйвера em имени Яндекса. На
машинке живет fullview и dummynet.


--
wbr, Alex

Alexey Karguine

unread,
Mar 15, 2011, 5:00:36 PM3/15/11
to Alex Belinsky, UaFUG

On Mar 15, 2011, at 22:54 , Alex Belinsky wrote:

> Нечто похожее вылечилось установкой драйвера em имени Яндекса. На
> машинке живет fullview и dummynet.

Просто из любопытства: какая нагрузка была по сети на эту машину?


Alexey Karguine
alexeyk...@me.com



Alex Belinsky

unread,
Mar 15, 2011, 5:12:06 PM3/15/11
to Alexey Karguine, UaFUG
2011/3/15 Alexey Karguine <alexeyk...@me.com>:

>
> On Mar 15, 2011, at 22:54 , Alex Belinsky wrote:
>
>> Нечто похожее вылечилось установкой драйвера em имени Яндекса. На
>> машинке живет fullview и dummynet.
>
> Просто из любопытства: какая нагрузка была по сети на эту машину?
>
>
~300-400 mbps,~ 50k pps


> Alexey Karguine
> alexeyk...@me.com
>
>
>
>

--
wbr, Alex

Alexey Karguine

unread,
Mar 15, 2011, 6:41:04 PM3/15/11
to Alex Belinsky, UaFUG

On Mar 16, 2011, at 00:12 , Alex Belinsky wrote:

>>> Нечто похожее вылечилось установкой драйвера em имени Яндекса. На
>>> машинке живет fullview и dummynet.
>>
>> Просто из любопытства: какая нагрузка была по сети на эту машину?
>>
>>
> ~300-400 mbps,~ 50k pps
>
И еще один вопрос: а версия ОС какая? (Это, как мне кажется, важнее, чем предыдущий)

Alexey Karguine
alexeyk...@me.com



Lystopad Olexandr

unread,
Mar 16, 2011, 1:22:03 AM3/16/11
to Alexey Karguine, UaFUG
Hello, Alexey Karguine!

On Tue, Mar 15, 2011 at 08:14:33PM +0300
alexeyk...@me.com wrote about "[freebsd] em, input errors and kernel load":

> О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫щё О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

uname -a?

pciconv -lvc

grep ^em /var/run/dmesg.boot

--
Lystopad Olexandr

Alex Belinsky

unread,
Mar 16, 2011, 4:23:06 AM3/16/11
to Alexey Karguine, UaFUG
2011/3/16 Alexey Karguine <alexeyk...@me.com>:
Таки да, важно, лень уже вчера вечером было дописывать. Случилось это
после переезда с 7.2 на 8.1. В данный момент FreeBSD 8.1-RELEASE-p2
i386.

dev.em.0.%desc: Intel(R) PRO/1000 Network Connection
7.0.5.Yandex[$Revision: 1.36.2.17.2.18 $]
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection
7.0.5.Yandex[$Revision: 1.36.2.17.2.18 $]

Vadim Goncharov

unread,
Mar 16, 2011, 4:35:59 AM3/16/11
to fre...@uafug.org.ua
15.03.11 @ 23:14 Alexey Karguine wrote:

> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
> COMMAND
> 0 root 10 -68 0 0K 72K - 0 7:01 200.00%
> kernel
> 11 root 2 171 ki31 0K 16K RUN 0 20:59 0.00% idle
> 12 root 13 -64 - 0K 104K WAIT 0 0:03 0.00% intr
> 13 root 1 -16 - 0K 8K RUN 0 0:02 0.00% yarrow

Судя по kernel, это 8-ка, хотя надо было указывать uname -a явно. На ней
оно объединяет треды, надо указывать top -SH.

> Если нужны ещё какие-то данные, с удовольствием их предоставлю.

Полезен еще vmstat -m и vmstat -z. Хотя я на 99% уверен, что это окажется
flowcleaner (лечится выпиливанием из ядра FLOWTABLE).

--
WBR, Vadim Goncharov

Alexey Karguine

unread,
Mar 16, 2011, 5:05:47 AM3/16/11
to UaFUG UaFUG

On Mar 16, 2011, at 08:22 , Lystopad Olexandr wrote:

> Hello, Alexey Karguine!
>
> On Tue, Mar 15, 2011 at 08:14:33PM +0300
> alexeyk...@me.com wrote about "[freebsd] em, input errors and kernel load":
>

>> Если нужны ещё какие-то данные, с удовольствием их предоставлю.
>

> uname -a?
>
> pciconv -lvc
>
> grep ^em /var/run/dmesg.boot
>

Извините, второпях забыл самое основное.

uname -a
FreeBSD mu.global-net.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Tue Mar 15 18:29:34 MSK 2011 ro...@mu.global-net.ru:/usr/obj/usr/src/sys/MU i386


pciconf -lv
em0@pci0:4:3:0: class=0x020000 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Ethernet Controller (82540EM)'
class = network
subclass = ethernet
em1@pci0:4:4:0: class=0x020000 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Ethernet Controller (82540EM)'
class = network
subclass = ethernet


em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xd040-0xd07f mem 0xd04a0000-0xd04bffff,0xd0480000-0xd049ffff irq 20 at device 3.0 on pci4
em0: [FILTER]
em0: Ethernet address: 00:07:e9:0b:93:30
em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xd000-0xd03f mem 0xd0440000-0xd045ffff,0xd0420000-0xd043ffff irq 21 at device 4.0 on pci4
em1: [FILTER]
em1: Ethernet address: 00:07:e9:8a:1c:4a

Убрать FLOWTABLE из ядра попробую.

Alexey Karguine
alexeyk...@me.com

Vladislav V. Prodan

unread,
Mar 16, 2011, 7:50:57 AM3/16/11
to fre...@uafug.org.ua
16.03.2011 10:35, Vadim Goncharov пишет:

> Хотя я на 99% уверен, что это окажется flowcleaner (лечится выпиливанием
> из ядра FLOWTABLE).

Достаточно его выключить в /etc/sysctl.conf

### disable flowtable
net.inet.flowtable.enable=0

Что за манера пересобирать ядро с поводом или без?

--
Vladislav V. Prodan
VVP24-UANIC
+380[67]4584408
+380[99]4060508
vla...@jabber.ru

Sayetsky Anton

unread,
Mar 16, 2011, 7:55:41 AM3/16/11
to Рассылка FreeBSD UA
16 марта 2011 г. 13:50 пользователь Vladislav V. Prodan
<unive...@ukr.net> написал:

> Что за манера пересобирать ядро с поводом или без?

> Traditionally, FreeBSD has had what is called a "monolithic" kernel. This means that the kernel was one large program, supported a fixed list of devices, and if you wanted to change the kernel's behavior then you had to compile a new kernel, and then reboot your computer with the new kernel.
> Building a custom kernel is one of the most important rites of passage for advanced BSD users.
(c) Handbook, Chapter 8.2,
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-custom-kernel.html

Не сказал бы, что это "манера". Это скорее следование рекомендации
разработчиков. Тем более, ведро-то быстро собирается на новом железе -
3-5 минут.

Vasiliy P. Melnik

unread,
Mar 16, 2011, 8:38:40 AM3/16/11
to fre...@uafug.org.ua
On Wed, Mar 16, 2011 at 01:50:57PM +0200, Vladislav V. Prodan wrote:
> 16.03.2011 10:35, Vadim Goncharov пишет:
> >Хотя я на 99% уверен, что это окажется flowcleaner (лечится выпиливанием
> >из ядра FLOWTABLE).
>
> Достаточно его выключить в /etc/sysctl.conf
>
> ### disable flowtable
> net.inet.flowtable.enable=0
>
> Что за манера пересобирать ядро с поводом или без?

я тож предпочитаю через кернел все проводить - при обновлении можно и не
заметить и переписать sysctl.conf.

но "на потестить" sysctl конечно самый удобный вариант.


З.Ы. самое главное, что можно и так и эдак


--
-------------------------------------------------------------------------------
Vasiliy P. Melnik VPM-UANIC

Vladislav V. Prodan

unread,
Mar 16, 2011, 10:57:11 AM3/16/11
to fre...@uafug.org.ua
16.03.2011 16:55, Vladislav V. Prodan пишет:
> При этом я сохраняю старый конфиг под новым номер _с отключенным_
> проблемным ядром.
проблемным модулем /опцией/девайсом

Vladislav V. Prodan

unread,
Mar 16, 2011, 10:55:05 AM3/16/11
to fre...@uafug.org.ua
16.03.2011 13:55, Sayetsky Anton пишет:

Я за отключение некорректно работающего модуля без перекомпилляции ядра.


При этом я сохраняю старый конфиг под новым номер _с отключенным_
проблемным ядром.

Чаще всего тазики в продакшене, нагружены, и лишний раз перенагружать и
ребутить нельзя.
Когда возникает окно или плановое ТО и _необходимость_ перекомпиляции
ядра, тогда и выкидываю проблемные модули.

Я всегда был, есть и буду за монолитное ядро

Mikolaj Golub

unread,
Mar 16, 2011, 11:18:58 AM3/16/11
to Vasiliy P. Melnik, fre...@uafug.org.ua

On Wed, 16 Mar 2011 14:38:40 +0200 Vasiliy P. Melnik wrote:

VPM> On Wed, Mar 16, 2011 at 01:50:57PM +0200, Vladislav V. Prodan wrote:
>> 16.03.2011 10:35, Vadim Goncharov О©╫О©╫О©╫О©╫О©╫:
>> >О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ 99% О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ flowcleaner (О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
>> >О©╫О©╫ О©╫О©╫О©╫О©╫ FLOWTABLE).
>>
>> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ /etc/sysctl.conf
>>
>> ### disable flowtable
>> net.inet.flowtable.enable=0
>>
>> О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫?

VPM> О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫
VPM> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ sysctl.conf.

VPM> О©╫О©╫ "О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫" sysctl О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.


VPM> О©╫.О©╫. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫

О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ flowtable О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ sysctl О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. flowtable.enable=0 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
flow_lookup_hash. О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫:

root 19 0.0 0.0 0 16 ?? DL 8:13 0:00.18 [flowcleaner]

О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
flowtable_flush(). О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ flowcleaner О©╫ flowtable_flush О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ 100% О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ CPU:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-11/msg00218.html

--
Mikolaj Golub

Vladislav V. Prodan

unread,
Mar 16, 2011, 11:53:08 AM3/16/11
to fre...@uafug.org.ua
16.03.2011 17:18, Mikolaj Golub пишет:

> В случае с flowtable отключение sysctl это далеко не то же, что отключение
> опции сборки ядра. flowtable.enable=0 приведет только к отключению
> flow_lookup_hash. Но допустим эта треда:


>
> root 19 0.0 0.0 0 16 ?? DL 8:13 0:00.18 [flowcleaner]
>

> будет продолжать бежать. И при удалении интерфейса будет вызываться
> flowtable_flush(). А как раз лок между flowcleaner и flowtable_flush может
> привести к 100% загрузке CPU:
>
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-11/msg00218.html
>

Я устранил причину паников, на данном этапе это для меня главное.
Спасибо за ссылку, при следующих сборках ядра выключу эту опцию.
Хоть он и распараллеливает работу mpd, но устойчивая работы системы -
важнее.

Alexey Karguine

unread,
Mar 17, 2011, 1:17:16 PM3/17/11
to fre...@uafug.org.ua
Да, извините, забыл указать uname. Это 8.2:

FreeBSD mu.global-net.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Wed Mar 16 12:13:29 MSK 2011     ro...@mu.global-net.ru:/usr/obj/usr/src/sys/MU i386

Попробовал убрать из ядра 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   SIZE    RES STATE   C   TIME   WCPU COMMAND
   0 root     -68    0     0K    64K -       1 160:09 100.00% {em0 taskq}
   0 root     -68    0     0K    64K CPU0    0 221:28 99.07% {em1 taskq}
  11 root     171 ki31     0K    16K RUN     1  21.4H  0.05% {idle: cpu1}
  11 root     171 ki31     0K    16K RUN     0  20.4H  0.00% {idle: cpu0}
  13 root      44    -     0K     8K RUN     1   3:18  0.00% yarrow
1182 root      44    0  8164K  4964K select  1   1:31  0.00% snmpd
  15 root      44    -     0K     8K RUN     0   1:24  0.00% syncer
  12 root     -32    -     0K   104K WAIT    1   0:52  0.00% {swi4: clock}
   0 root      44    0     0K    64K sched   1   0:44  0.00% {swapper}
1156 zabbix    49    5  5268K  1816K select  0   0:12  0.00% zabbix_agentd
1158 zabbix    49    5  5268K  1812K select  1   0:12  0.00% zabbix_agentd
1157 zabbix    49    5  5268K  1816K accept  0   0:12  0.00% zabbix_agentd
1392 root      44    0 10244K  7568K select  1   0:11  0.00% python
1155 zabbix    49    5  5268K  1912K RUN     0   0:08  0.00% zabbix_agentd


Подскажите плиз, чего бы ещё попробовать. У меня вариантов больше нет. Сетевухи поменять на аналогичные, но новые?

Vladislav V. Prodan

unread,
Mar 17, 2011, 5:45:34 PM3/17/11
to fre...@uafug.org.ua
17.03.2011 19:17, Alexey Karguine пишет:

>
> Подскажите плиз, чего бы ещё попробовать. У меня вариантов больше нет.
> Сетевухи поменять на аналогичные, но новые?

Они сидят на разных прерываниях?
Замена на другие будет тоже лотереей.

Vadim Goncharov

unread,
Mar 18, 2011, 2:57:14 AM3/18/11
to fre...@uafug.org.ua
17.03.11 @ 23:16 Alexey Karguine wrote:

>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
>>> COMMAND
>>> 0 root 10 -68 0 0K 72K - 0 7:01 200.00%
>>> kernel

>> Судя по kernel, это 8-ка, хотя надо было указывать uname -a явно. На
>> ней оно объединяет треды, надо указывать top -SH.
>>
>>> Если нужны ещё какие-то данные, с удовольствием их предоставлю.
>>
>> Полезен еще vmstat -m и vmstat -z. Хотя я на 99% уверен, что это
>> окажется flowcleaner (лечится выпиливанием из ядра FLOWTABLE).
>
> Да, извините, забыл указать uname. Это 8.2:

Ну так vmstat вышеуказанный-то где?

> Попробовал убрать из ядра 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 SIZE RES STATE C TIME WCPU COMMAND
> 0 root -68 0 0K 64K - 1 160:09 100.00% {em0
> taskq}
> 0 root -68 0 0K 64K CPU0 0 221:28 99.07% {em1 taskq}
>

> Подскажите плиз, чего бы ещё попробовать. У меня вариантов больше нет.
> Сетевухи поменять на аналогичные, но новые?

Это программная проблема, taskq уже не в hardware interrupt крутится, так
что не поможет.

http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
- пересобрать ядро по инструкции отсюда, попробовать остальные шаги во
время затыка.

--
WBR, Vadim Goncharov

Alexey Karguine

unread,
Mar 18, 2011, 6:49:51 AM3/18/11
to fre...@uafug.org.ua

On Mar 18, 2011, at 9:57 AM, Vadim Goncharov wrote:

> 17.03.11 @ 23:16 Alexey Karguine wrote:
>
>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
>>>> 0 root 10 -68 0 0K 72K - 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 SIZE RES STATE C TIME WCPU COMMAND
>> 0 root -68 0 0K 64K - 1 160:09 100.00% {em0 taskq}
>> 0 root -68 0 0K 64K CPU0 0 221:28 99.07% {em1 taskq}
>>
>> Подскажите плиз, чего бы ещё попробовать. У меня вариантов больше нет. Сетевухи поменять на аналогичные, но новые?
>
> Это программная проблема, taskq уже не в hardware interrupt крутится, так что не поможет.
>
> http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время затыка.

Спасибо, попробую и обязательно отпишусь.

Alexey Karguine

unread,
Mar 18, 2011, 10:30:05 AM3/18/11
to fre...@uafug.org.ua

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 - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время затыка.

Это ещё не пробовал. Ядро уже пересобранное, но т.к. машина боевая, ребутнуть её получится только ближе к вечеру. После этого буду ждать очередного приступа.


vmstat-z.txt
vmstat-m.txt

Alex Belinsky

unread,
Mar 18, 2011, 10:40:03 AM3/18/11
to Alexey Karguine, fre...@uafug.org.ua
2011/3/18 Alexey Karguine <alexeyk...@me.com>:
Ещё раз напоминаю о яндексовских дровах. 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 все красиво и спокойно.

Lystopad Olexandr

unread,
Mar 18, 2011, 10:48:07 AM3/18/11
to fre...@uafug.org.ua
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, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

--
Lystopad Olexandr

Alex Belinsky

unread,
Mar 18, 2011, 10:53:26 AM3/18/11
to Lystopad Olexandr, fre...@uafug.org.ua
2011/3/18 Lystopad Olexandr <l...@laa.zp.ua>:
>  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

Alexey Karguine

unread,
Mar 18, 2011, 11:45:14 AM3/18/11
to Vadim Goncharov, fre...@uafug.org.ua

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
alexeyk...@me.com

Vadim Goncharov

unread,
Mar 18, 2011, 3:18:13 PM3/18/11
to fre...@uafug.org.ua
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 нет.

Да в общем-то можно было не выкладывать, там самое главное в строчках
Top-5 пожирателей времени (80% времени в сумме):

% cumulative self self total
time seconds seconds calls 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.00 11536 973.39 1001.30 rn_match [26]

Это явный lock contention (glebius@ тут считает, что если сделать ядро с
MUTEX_PROFILING, то будет видно, что libalias лок - most contended). Там
выше в call graph есть подтверждение:

called/total parents
index %time self descendents called+self name index
called/total children

485.00 227154.59 678354/678354 ipfw_nat [8]
[10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
151066.41 1.70 678355/799402 _mtx_lock_sleep [11]
1053.00 75033.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_SIZE 8123
#define LINK_TABLE_IN_SIZE 16411

и пересобрать ядро (и при каждом обновлении исходников придется руками
поддерживать патченым так).

--
WBR, Vadim Goncharov

Lystopad Aleksandr

unread,
Mar 19, 2011, 1:56:00 AM3/19/11
to fre...@uafug.org.ua
Hello, Vadim Goncharov!

On Sat, Mar 19, 2011 at 01:18:13AM +0600
vadimn...@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 seconds calls 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.00 11536 973.39 1001.30 rn_match [26]
>

> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ lock contention (glebius@ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫
> MUTEX_PROFILING, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ libalias О©╫О©╫О©╫ - most contended). О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫ О©╫ call graph О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫:


>
> called/total parents
> index %time self descendents called+self name index
> called/total children
>
> 485.00 227154.59 678354/678354 ipfw_nat [8]
> [10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
> 151066.41 1.70 678355/799402 _mtx_lock_sleep [11]
> 1053.00 75033.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_SIZE 8123
> #define LINK_TABLE_IN_SIZE 16411
>

> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ (О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫).

--
Lystopad Olexandr

Vadim Goncharov

unread,
Mar 21, 2011, 6:03:25 AM3/21/11
to fre...@uafug.org.ua
19.03.11 @ 11:56 Lystopad Aleksandr wrote:

>> called/total parents
>> index %time self descendents called+self name index
>> called/total children
>>
>> 485.00 227154.59 678354/678354 ipfw_nat [8]
>> [10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
>> 151066.41 1.70 678355/799402 _mtx_lock_sleep
>> [11]
>> 1053.00 75033.48 794/794 LibAliasInLocked
>> [14]
>>

>> То есть, несколько тредов одновременно постоянно дерутся за доступ к
>> instance ната - оно не параллелится. Решение: натить в несколько внешних
>> IP-адресов, для каждого заводить отдельный инстанс libalias (ipfw nat).
>

> Вадим, можно мне пояснить, вернее разжевать, такое: нагрузка в emX:
> taskq. Так? В первых постах топикстартер показывает свой трафик:
> 7-10кппс и 7-9МБс. На такой нагрузке нат как бы не должен
> выпендриваться. Почему вспсплески по CPU у топикстартера получаются?
>
> У меня более слабая машинка натила под 200мбит без проблем!

Это значит, что ему попался такой паттерн трафика, на котором у libalias
возникают проблемы. У хэш-функций такое не редкость, что некоторые
граничные случаи приводят к большому количеству коллизий (а хэш в libalias
довольно тупой), вероятно, топикстартеру как раз и не повезло. Впрочем,
такие проседания случаются время от времени, я бы предположил, что во
время чистки старых записей в таблице.

По-хорошему, тут надо "научными исследованиями" заняться, что именно там
происходит, но проблематично это в условиях рассылки и
"производственников-эксплуатационщиков"...

--
WBR, Vadim Goncharov

Lystopad Aleksandr

unread,
Mar 21, 2011, 6:17:04 AM3/21/11
to fre...@uafug.org.ua
Hello, Vadim Goncharov!

On Mon, Mar 21, 2011 at 04:03:25PM +0600


vadimn...@tpu.ru wrote about "Re: [freebsd] em, input errors and kernel load":

> 19.03.11 @ 11:56 Lystopad Aleksandr wrote:
>
> >> called/total parents
> >>index %time self descendents called+self name index
> >> called/total children
> >>
> >> 485.00 227154.59 678354/678354 ipfw_nat [8]
> >>[10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
> >> 151066.41 1.70 678355/799402 _mtx_lock_sleep
> >>[11]
> >> 1053.00 75033.48 794/794 LibAliasInLocked
> >>[14]
> >>

> >>О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫

> >>instance О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫: О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> >>IP-О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ libalias (ipfw nat).
> >
> >О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫: О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ emX:
> >taskq. О©╫О©╫О©╫? О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫:
> >7-10О©╫О©╫О©╫О©╫ О©╫ 7-9О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> >О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ CPU О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?
> >
> >О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ 200О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫!
>

> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ libalias
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫ О©╫О©╫О©╫ О©╫ libalias
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫), О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫

> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫!


О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫

О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ 8.2-REL О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫.

net.isr О©╫О©╫ О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫,


О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

imho О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ ET dual port.

> О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫" О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫
> "О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫"...

О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ :)

--
Lystopad Olexandr

Vadim Goncharov

unread,
Mar 21, 2011, 6:44:36 AM3/21/11
to fre...@uafug.org.ua
21.03.11 @ 16:17 Lystopad Aleksandr wrote:

>> Это значит, что ему попался такой паттерн трафика, на котором у libalias
>> возникают проблемы. У хэш-функций такое не редкость, что некоторые
>> граничные случаи приводят к большому количеству коллизий (а хэш в
>> libalias
>> довольно тупой), вероятно, топикстартеру как раз и не повезло. Впрочем,
>> такие проседания случаются время от времени, я бы предположил, что во
>> время чистки старых записей в таблице.
>

> Спасибо за ответ, Вадим!
> Но за рамками рассылки осталось наше общение с топикстартером, и там
> он говорит, что у него такие же карточки на 8.2-REL стоят на других
> машинках и работают. Такой же трафик примерно переливают и там нет
> проблем. Чипы сверяли, такие же.
>
> net.isr мы с ним покрутили, не помогает. Вернее частично помогло,
> залипания стали не такие болезненные.
>
> Яндекс драйвера он попробовал, не совсем помогает.
> imho ему надо ставить другие карточки на другом чипе. Я бы
> рекомендовал ET dual port.

Я же ранее объяснял, дело совсем не карточке и не в драйверах, а в
программной части - более того, любое дополнительное распараллеливание
только усугубит проблему. Другим образом надо параллелить, а не просто
добавлять элементы.

И трафик там не такой же, раз проблемы нет. Ибо "такой же" - это вовсе не
объем kpps/Мбит, а комбинации адресов/портов/протоколов внутри этого
трафика.

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

>> По-хорошему, тут надо "научными исследованиями" заняться, что именно там
>> происходит, но проблематично это в условиях рассылки и
>> "производственников-эксплуатационщиков"...
>

> Думаю, топикстартеру надо не исследования, а чтоб работало :)

Потому и говорю, что проблематично. Чтоб работало, я практические
рекомендации уже приводил.

--
WBR, Vadim Goncharov

Lystopad Aleksandr

unread,
Mar 21, 2011, 7:45:09 AM3/21/11
to fre...@uafug.org.ua
Hello, Vadim Goncharov!

On Mon, Mar 21, 2011 at 04:03:25PM +0600


vadimn...@tpu.ru wrote about "Re: [freebsd] em, input errors and kernel load":

> 19.03.11 @ 11:56 Lystopad Aleksandr wrote:
>
> >> called/total parents
> >>index %time self descendents called+self name index
> >> called/total children
> >>
> >> 485.00 227154.59 678354/678354 ipfw_nat [8]
> >>[10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
> >> 151066.41 1.70 678355/799402 _mtx_lock_sleep
> >>[11]
> >> 1053.00 75033.48 794/794 LibAliasInLocked
> >>[14]
> >>

> >>О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫

> >>instance О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫: О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> >>IP-О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ libalias (ipfw nat).
> >
> >О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫: О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ emX:
> >taskq. О©╫О©╫О©╫? О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫:
> >7-10О©╫О©╫О©╫О©╫ О©╫ 7-9О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> >О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ CPU О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?
> >
> >О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ 200О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫!
>

> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ libalias
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫ О©╫О©╫О©╫ О©╫ libalias
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫), О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫

> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫, О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ PR О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ freebsd О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫?
;)

--
Lystopad Olexandr

Vadim Goncharov

unread,
Mar 21, 2011, 12:57:35 PM3/21/11
to fre...@uafug.org.ua
21.03.11 @ 17:45 Lystopad Aleksandr wrote:

>> >> called/total parents
>> >>index %time self descendents called+self name index
>> >> called/total children
>> >>
>> >> 485.00 227154.59 678354/678354 ipfw_nat [8]
>> >>[10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
>> >> 151066.41 1.70 678355/799402 _mtx_lock_sleep
>> >>[11]
>> >> 1053.00 75033.48 794/794 LibAliasInLocked
>> >>[14]
>> >>

>> >>То есть, несколько тредов одновременно постоянно дерутся за доступ к
>> >>instance ната - оно не параллелится. Решение: натить в несколько
>> внешних
>> >>IP-адресов, для каждого заводить отдельный инстанс libalias (ipfw
>> nat).
>> >
>> >Вадим, можно мне пояснить, вернее разжевать, такое: нагрузка в emX:
>> >taskq. Так? В первых постах топикстартер показывает свой трафик:
>> >7-10кппс и 7-9МБс. На такой нагрузке нат как бы не должен
>> >выпендриваться. Почему вспсплески по CPU у топикстартера получаются?
>> >
>> >У меня более слабая машинка натила под 200мбит без проблем!
>>
>> Это значит, что ему попался такой паттерн трафика, на котором у libalias
>> возникают проблемы. У хэш-функций такое не редкость, что некоторые
>> граничные случаи приводят к большому количеству коллизий (а хэш в
>> libalias
>> довольно тупой), вероятно, топикстартеру как раз и не повезло. Впрочем,
>> такие проседания случаются время от времени, я бы предположил, что во
>> время чистки старых записей в таблице.
>

> Вадим, пожалуйста, объясни это поподробней. Очень интересно. Как
> работает эта хэш-функция. Опиши подобный граничный случай. Может, с
> твоей помощью уйдет PR разработчикам и freebsd станет чуточку лучше?

Для этого как раз смотреть надо, что у него реально, поскольку случаев
много, ибо код там очень простой:

n = alias_addr.s_addr; /* alias_* принадлежат самому NAT box
*/
if (link_type != LINK_PPTP)
n += alias_port;
n += link_type;
return (n % LINK_TABLE_IN_SIZE);

Использовать удаленные адрес-порт оно не может, потому что в этот же слот
должен попасть и первый входящий пакет для редиректа, от кого угодно.

Для out-случая оно использует оба адреса и порта.

--
WBR, Vadim Goncharov

Reply all
Reply to author
Forward
0 new messages