https://www.opennet.ru/openforum/vsluhforumID1/87589.html Доброго времени суток. Натолкнулся на проблему след. характера. Растет wired memory, когда в Wired уходит вся память система зависает. Железо было разное. Система FreeBSD 8.0 amd64.<br>Ядро GENERIC +<br>options HZ=2000<br>options IPFIREWALL_DEFAULT_TO_ACCEPT<br>options IPFIREWALL<br>options IPFIREWALL_VERBOSE<br>options IPFIREWALL_VERBOSE_LIMIT=500<br>options IPFIREWALL_FORWARD<br>options IPFIREWALL_NAT<br>options DUMMYNET<br>options DEVICE_POLLING<br>options IPDIVERT<br>options LIBALIAS<br>options NETGRAPH<br>options NETGRAPH_IPFW<br>options NETGRAPH_NAT<br>options NETGRAPH_NETFLOW<br>options NETGRAPH_SPLIT<br>options NETGRAPH_ETHER<br>options NETGRAPH_KSOCKET<br>options NETGRAPH_SOCKET<br>options NETGRAPH_BPF<br>options NETGRAPH_IFACE<br>options NETGRAPH_MPPC_ENCRYPTION<br>options NETGRAPH_PPP<br>options NETGRAPH_PPTPGRE<br>options NETGRAPH_TCPMSS<br>options https://www.opennet.ru/openforum/vsluhforumID1/87589.html#6 Wed, 15 Jun 2011 06:35:21 GMT аналогичная проблема на 8.2 amd64<br>месяц аптайма и на обоих бордерах lltable съедает память. Не смотря на разную нагрузку. (на одном 50 мегабит на втором 200)<br><br>FreeBSD 8.2-RELEASE amd64<br>До этого была проблема зависаний из-за опции ядра <br>option FLOWTABLE<br>после отключения которой, проработало все 1 месяц.<br>патч по теме написан под 8.0 stable можно ли его на 8.2 наложить?<br> https://www.opennet.ru/openforum/vsluhforumID1/87589.html#5 Thu, 08 Apr 2010 09:17:36 GMT Несомненно уже поздно что-то советовать, но случайно на глаза попал problem report касательно "роста lltable" - http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144564<br>По всей видимости это та же проблема с которой столкнулись вы, и судя по комментариям в этом PR присутствует патч, который решает эту проблему.<br> https://www.opennet.ru/openforum/vsluhforumID1/87589.html#4 Thu, 18 Feb 2010 08:52:39 GMT Вобщем то у меня очень похожая ситуация, freeebsd 7.x AMD64, работает в качестве бордера, запущен openBGPD, принимает два full-view, в сутки утекает в wired около 100Мб. Судя по vmstat -m больше всех отжирает - routetbl 642995 20163K - 2204266 32,64,128,256,512.<br>Может кто сталкивался с таким?<br> https://www.opennet.ru/openforum/vsluhforumID1/87589.html#3 Thu, 11 Feb 2010 07:34:31 GMT Достойных идей пока нет. Могу только сказать, что lltable (link level address tables) относится к сетевой подсистеме.<br>Я бы попытался найти зависимость между количеством записей (или динамикой изменения количества записей в lltable) и операциями выполняемыми данной машиной. Можно будет приблизиться к причине проблемы если получится связать рост количества записей в lltable с, например, количеством маршрутов или попаданиями на какое-нибуть из правил/очередей ipfw или с количеством установленных соединений и т.п.<br>Ещё один момент - сейчас значение "Requests" (2645748) несколько ниже значения "InUse" (2643140) возможно вы замечали какую-то временнУю зависимость когда появляется это расхождение в значениях или когда оно начинает (начнёт) расти более стремительно.<br> https://www.opennet.ru/openforum/vsluhforumID1/87589.html#2 Wed, 10 Feb 2010 06:57:35 GMT Ситуация один в один<br>uname -rp<br>8.0-RELEASE amd64<br>device vlan<br>options SC_NO_HISTORY<br>options SC_DISABLE_REBOOT<br>options IPFIREWALL<br>options IPFIREWALL_VERBOSE<br>options IPFIREWALL_DEFAULT_TO_ACCEPT<br>options IPFIREWALL_FORWARD<br>options IPDIVERT<br>options DUMMYNET<br>options PANIC_REBOOT_WAIT_TIME=16<br><br>vmstat -m&#124;sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/\1+/;$s/$/1024*p/'&#124;dc&#124;awk '{print $1/1048576 " MB"}'<br>673,183 MB<br><br>vmstat -m &#124; grep lltab<br> lltable 2643140 660787K - 2645748 256,512<br><br> https://www.opennet.ru/openforum/vsluhforumID1/87589.html#1 Fri, 11 Dec 2009 19:33:58 GMT Попробую ткнуть пальцем в небо - данные симптомы могут означать рост количества памяти, используемой ядром и последующий deadlock/panic из-за невозможности выполнить "kernel malloc".<br><br>Вывод следующей команды и динамика результирующего значения во времени могут подтвердить или опровергнуть мою гипотезу:<br>[code]vmstat -m&#124;sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/\1+/;$s/$/1024*p/'&#124;dc&#124;awk '{print $1/1048576 " MB"}'[/code]<br><br>Если гипотеза подтвердится (т.е. значение будет например 512Мб и более), то анализ vmstat -m на предмет "самого толстого" потребителя памяти хотябы подскажет в какой "подсистеме ядра" происходит "неконтролируемый рост"/"утечка памяти"/"неосвобождение ресурсов".<br>