Доброго времени суток. Натолкнулся на проблему след. характера. Растет wired memory, когда в Wired уходит вся память система зависает. Железо было разное. Система FreeBSD 8.0 amd64.
Ядро GENERIC +
options HZ=2000
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=500
options IPFIREWALL_FORWARD
options IPFIREWALL_NAT
options DUMMYNET
options DEVICE_POLLING
options IPDIVERT
options LIBALIAS
options NETGRAPH
options NETGRAPH_IPFW
options NETGRAPH_NAT
options NETGRAPH_NETFLOW
options NETGRAPH_SPLIT
options NETGRAPH_ETHER
options NETGRAPH_KSOCKET
options NETGRAPH_SOCKET
options NETGRAPH_BPF
options NETGRAPH_IFACE
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_PPP
options NETGRAPH_PPTPGRE
options NETGRAPH_TCPMSS
options NETGRAPH_VJC
options IPFILTER
options IPFILTER_LOG
Попробую ткнуть пальцем в небо - данные симптомы могут означать рост количества памяти, используемой ядром и последующий deadlock/panic из-за невозможности выполнить "kernel malloc".Вывод следующей команды и динамика результирующего значения во времени могут подтвердить или опровергнуть мою гипотезу:
vmstat -m|sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/\1+/;$s/$/1024*p/'|dc|awk '{print $1/1048576 " MB"}'Если гипотеза подтвердится (т.е. значение будет например 512Мб и более), то анализ vmstat -m на предмет "самого толстого" потребителя памяти хотябы подскажет в какой "подсистеме ядра" происходит "неконтролируемый рост"/"утечка памяти"/"неосвобождение ресурсов".
Ситуация один в один
uname -rp
8.0-RELEASE amd64
device vlan
options SC_NO_HISTORY
options SC_DISABLE_REBOOT
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET
options PANIC_REBOOT_WAIT_TIME=16vmstat -m|sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/\1+/;$s/$/1024*p/'|dc|awk '{print $1/1048576 " MB"}'
673,183 MBvmstat -m | grep lltab
lltable 2643140 660787K - 2645748 256,512
Достойных идей пока нет. Могу только сказать, что lltable (link level address tables) относится к сетевой подсистеме.
Я бы попытался найти зависимость между количеством записей (или динамикой изменения количества записей в lltable) и операциями выполняемыми данной машиной. Можно будет приблизиться к причине проблемы если получится связать рост количества записей в lltable с, например, количеством маршрутов или попаданиями на какое-нибуть из правил/очередей ipfw или с количеством установленных соединений и т.п.
Ещё один момент - сейчас значение "Requests" (2645748) несколько ниже значения "InUse" (2643140) возможно вы замечали какую-то временнУю зависимость когда появляется это расхождение в значениях или когда оно начинает (начнёт) расти более стремительно.
Вобщем то у меня очень похожая ситуация, freeebsd 7.x AMD64, работает в качестве бордера, запущен openBGPD, принимает два full-view, в сутки утекает в wired около 100Мб. Судя по vmstat -m больше всех отжирает - routetbl 642995 20163K - 2204266 32,64,128,256,512.
Может кто сталкивался с таким?
Несомненно уже поздно что-то советовать, но случайно на глаза попал problem report касательно "роста lltable" - http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144564
По всей видимости это та же проблема с которой столкнулись вы, и судя по комментариям в этом PR присутствует патч, который решает эту проблему.
аналогичная проблема на 8.2 amd64
месяц аптайма и на обоих бордерах lltable съедает память. Не смотря на разную нагрузку. (на одном 50 мегабит на втором 200)FreeBSD 8.2-RELEASE amd64
До этого была проблема зависаний из-за опции ядра
option FLOWTABLE
после отключения которой, проработало все 1 месяц.
патч по теме написан под 8.0 stable можно ли его на 8.2 наложить?