URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 87589
[ Назад ]

Исходное сообщение
"FreeBSD & Wired mem"

Отправлено aleksuss , 11-Дек-09 13:50 
Доброго времени суток. Натолкнулся на проблему след. характера. Растет 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

Содержание

Сообщения в этом обсуждении
"FreeBSD & Wired mem"
Отправлено temny , 11-Дек-09 22:33 
Попробую ткнуть пальцем в небо - данные симптомы могут означать рост количества памяти, используемой ядром и последующий 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 на предмет "самого толстого" потребителя памяти хотябы подскажет в какой "подсистеме ядра" происходит "неконтролируемый рост"/"утечка памяти"/"неосвобождение ресурсов".


"FreeBSD & Wired mem"
Отправлено Funky , 10-Фев-10 09:57 
Ситуация один в один
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=16

vmstat -m|sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/\1+/;$s/$/1024*p/'|dc|awk '{print $1/1048576 " MB"}'
673,183 MB

vmstat -m | grep lltab
      lltable 2643140 660787K       -  2645748  256,512


"FreeBSD & Wired mem"
Отправлено temny , 11-Фев-10 10:34 
Достойных идей пока нет. Могу только сказать, что lltable (link level address tables) относится к сетевой подсистеме.
Я бы попытался найти зависимость между количеством записей (или динамикой изменения количества записей в lltable) и операциями выполняемыми данной машиной. Можно будет приблизиться к причине проблемы если получится связать рост количества записей в lltable с, например, количеством маршрутов или попаданиями на какое-нибуть из правил/очередей ipfw или с количеством установленных соединений и т.п.
Ещё один момент - сейчас значение "Requests" (2645748) несколько ниже значения "InUse" (2643140) возможно вы замечали какую-то временнУю зависимость когда появляется это расхождение в значениях или когда оно начинает (начнёт) расти более стремительно.

"FreeBSD & Wired mem"
Отправлено Nick , 18-Фев-10 11:52 
Вобщем то у меня очень похожая ситуация, freeebsd 7.x AMD64, работает в качестве бордера, запущен openBGPD, принимает два full-view, в сутки утекает в wired около 100Мб. Судя по vmstat -m больше всех отжирает -  routetbl 642995 20163K       -  2204266  32,64,128,256,512.
Может кто сталкивался с таким?

"FreeBSD & Wired mem"
Отправлено аноним , 08-Апр-10 13:17 
Несомненно уже поздно что-то советовать, но случайно на глаза попал problem report касательно "роста lltable" - http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144564
По всей видимости это та же проблема с которой столкнулись вы, и судя по комментариям в этом PR присутствует патч, который решает эту проблему.

"FreeBSD & Wired mem"
Отправлено Yarikello , 15-Июн-11 10:35 
аналогичная проблема на 8.2 amd64
месяц аптайма и на обоих бордерах lltable съедает память. Не смотря на разную нагрузку. (на одном 50 мегабит на втором 200)

FreeBSD 8.2-RELEASE amd64
До этого была проблема зависаний из-за опции ядра
option FLOWTABLE
после отключения  которой, проработало все 1 месяц.
патч по теме написан под 8.0 stable можно ли его на 8.2 наложить?