Писал сюда недавно по поводу машины с 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
--
wbr, Alex
> Alexey Karguine
> alexeyk...@me.com
>
>
>
>
--
wbr, Alex
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
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 $]
> 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
> 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
Достаточно его выключить в /etc/sysctl.conf
### disable flowtable
net.inet.flowtable.enable=0
Что за манера пересобирать ядро с поводом или без?
--
Vladislav V. Prodan
VVP24-UANIC
+380[67]4584408
+380[99]4060508
vla...@jabber.ru
> 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 минут.
я тож предпочитаю через кернел все проводить - при обновлении можно и не
заметить и переписать sysctl.conf.
но "на потестить" sysctl конечно самый удобный вариант.
З.Ы. самое главное, что можно и так и эдак
--
-------------------------------------------------------------------------------
Vasiliy P. Melnik VPM-UANIC
Я за отключение некорректно работающего модуля без перекомпилляции ядра.
При этом я сохраняю старый конфиг под новым номер _с отключенным_
проблемным ядром.
Чаще всего тазики в продакшене, нагружены, и лишний раз перенагружать и
ребутить нельзя.
Когда возникает окно или плановое ТО и _необходимость_ перекомпиляции
ядра, тогда и выкидываю проблемные модули.
Я всегда был, есть и буду за монолитное ядро
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
> В случае с 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, но устойчивая работы системы -
важнее.
Они сидят на разных прерываниях?
Замена на другие будет тоже лотереей.
>>> 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
> 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 - пересобрать ядро по инструкции отсюда, попробовать остальные шаги во время затыка.
Спасибо, попробую и обязательно отпишусь.
> О©╫щё О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. 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
> --
> Lystopad Olexandr
>
--
wbr, Alex
fozz-ripe
> Это программная проблема, 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
>> Ну так 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
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
>> 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
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
>> Это значит, что ему попался такой паттерн трафика, на котором у libalias
>> возникают проблемы. У хэш-функций такое не редкость, что некоторые
>> граничные случаи приводят к большому количеству коллизий (а хэш в
>> libalias
>> довольно тупой), вероятно, топикстартеру как раз и не повезло. Впрочем,
>> такие проседания случаются время от времени, я бы предположил, что во
>> время чистки старых записей в таблице.
>
> Спасибо за ответ, Вадим!
> Но за рамками рассылки осталось наше общение с топикстартером, и там
> он говорит, что у него такие же карточки на 8.2-REL стоят на других
> машинках и работают. Такой же трафик примерно переливают и там нет
> проблем. Чипы сверяли, такие же.
>
> net.isr мы с ним покрутили, не помогает. Вернее частично помогло,
> залипания стали не такие болезненные.
>
> Яндекс драйвера он попробовал, не совсем помогает.
> imho ему надо ставить другие карточки на другом чипе. Я бы
> рекомендовал ET dual port.
Я же ранее объяснял, дело совсем не карточке и не в драйверах, а в
программной части - более того, любое дополнительное распараллеливание
только усугубит проблему. Другим образом надо параллелить, а не просто
добавлять элементы.
И трафик там не такой же, раз проблемы нет. Ибо "такой же" - это вовсе не
объем kpps/Мбит, а комбинации адресов/портов/протоколов внутри этого
трафика.
Вы количественные решения пробуете, а не качественные.
>> По-хорошему, тут надо "научными исследованиями" заняться, что именно там
>> происходит, но проблематично это в условиях рассылки и
>> "производственников-эксплуатационщиков"...
>
> Думаю, топикстартеру надо не исследования, а чтоб работало :)
Потому и говорю, что проблематично. Чтоб работало, я практические
рекомендации уже приводил.
--
WBR, 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
>> >> 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