The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"FreeBSD & Wired mem"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Система. проблемы, диагностика / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"FreeBSD & Wired mem"  +/
Сообщение от aleksuss email(ok) on 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
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "FreeBSD & Wired mem"  +/
Сообщение от temny email(??) on 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 на предмет "самого толстого" потребителя памяти хотябы подскажет в какой "подсистеме ядра" происходит "неконтролируемый рост"/"утечка памяти"/"неосвобождение ресурсов".

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "FreeBSD & Wired mem"  +/
Сообщение от Funky on 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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру