05.04.11 @ 19:37 Lystopad Aleksandr wrote:
>>>>>При попытке сделать ngctl list получаю subj. В утреннее время,
когда
>>>>>на mpd меньше нагрузка -- ngctl list работает. В пики примерно 500
>>>>>интерфейсов у mpd. Утром 200-300. При этом даже в пики телнет в mpd
>>>>>админ-консоль пускает. Можно смотреть инфу, которую предоставляет
>>>>>mpd. Юзера работают даже в пики, но subj пугает.
>>>>
>>>>Смахивает на нехватку mbuf. Попробовать поднять kern.ipc.nmbclusters
^^^ - вот в этой строке прозвучала идея поднять kern.ipc.nmbclusters
>>>
>>>Это которые в netstat -m? Дык там валом, похоже.
>>
>>Ну, отдельной крутилки для самих mbuf нет. В контексте прерывания
>>доступно
>>не всё из свободного количества. Возможно, дело в этом, надо
проверять.
>
>Было kern.ipc.nmbclusters=128000, поднял в 2 раза. Это значит у меня
>будет выделятся до 512Мб памяти для этих целей? Верно, же?
До 576, если точнее. Хотя судя по выясненному ниже, это был другой code
path, дело не в кластерах, и можно вернуть nmbclusters обратно (память
тоже не резиновая).
А что выяснилось ниже?
Это я невнимательно прочитал письмо первый раз - во втором куске
показалось, что написано maxsockbuf. Потом перечитал, тогда уточнил насчет
опечатки. Но судя по соседнему письму, всё верно, nmbclusters не влияет.
>>>>>Добавил в sysctl
>>>>>
>>>>>net.graph.maxdgram=128000
>>>>>net.graph.recvspace=128000
>>>>>
>>>>>не помогло. При больших значениях вообще mpd не запускается.
>>>>
>>>>При больших значениях надо еще проверять, чтобы kern.ipc.maxsockbuf
>>был
>>>>соответствующим.
>>>
>>>Вадим, спасибо за ответ!!!!
>>
>>А помогло?
>
>Ну С kern.ipc.nmbclusters=256000 получилось поставить
>net.graph.maxdgram и net.graph.recvspace в значение 196000.
>
>mpd не перестартовывал, но ngctl list стал выводить результат, хотя
>за минуту до ввода этих крутилок выдавался сабж.
Гм, не опечатка? Может таки maxsockbuf, а не nmbclusters?
Ну вы предложили, Вадим, поднять kern.ipc.nmbclusters.
Я так понимаю, оба параметра были подняты? kern.ipc.nmbclusters не влияет,
как выясняется.
Я готов крутить все что нужно, лишь бы помогло. Но четкого понимания
пока нету. :(
kern.ipc.maxsockbuf задает общесистемный лимит на размер буфера сокета
(есть еще в ulimit), параметры в net.graph. задают их для сокетов
AF_NETGRAPH, дефолтные и неизменяеме приложением, поскольку setsockopt()
на AF_NETGRAPH не поддерживается. Сообщение netgrpah есть 1 datagram,
которая, естественно, должна влезть в буфер сокета.
>А как бы без прерывания пользовательских сессий узнать поднимится ли
>mpd в следующий раз при таких настройках? Или если работает сейчас,
>то и поднимется?
В код mpd не смотрел. Думаю, поднимется.
>>>А как самому мониторить это? Где посмотреть текущее потребление?
>>Потребление чего именно?
>
>Ну потребление процессом mpd буферов. Потребление вообще netgraph-ом
>памяти, буферов и тд. Я хочу знать хватает или нет, может надо
>добавить. Хочу это знать и мониторить.
Сам процесс mpd их почти не потребляет (можно смотреть в netstat, с
разными -f), а отдельной статистики в ядре, насколько мне известно,
кроме
vmstat -m / vmstat -z не ведется (из соображений производительности).
Вот мои результаты:
# vmstat -m:
Type InUse MemUse HighUse Requests Size(s)
....
netgraph_msg 0 0K - 1836290 64,128,256,512,1024
netgraph_node 2726 682K - 20208 256
netgraph_hook 9288 1161K - 84544 128
netgraph 1946 3235K - 15454 64,256,4096
netgraph_sock 5 1K - 40 128
netgraph_path 0 0K - 978589 16,32
netgraph_mppc 0 0K - 1 1024
netgraph_pppoe 391 37K - 6035 64,512
netgraph_iface 388 49K - 2364 128
netgraph_ppp 388 4656K - 2364
netgraph_bpf 7720 1641K - 60970 128,1024
#
При таких значениях использования памяти переменные
net.graph.maxdgram и net.graph.recvspace задранные в 128000 и выше
похоже ничего не меняют? Верно?
Размеры памяти в общем зависят от разного. Конкретно для ngctl list
релевантно netgraph_node, их примерно 2726 штук. Сообщение NGM_LISTNODES
оперирует массивом структур, по 72 байта на одну ноду. На одного клиента
mpd создается несколько узлов.
Вот еще:
# vmstat -z|grep -E "(ITEM|NetG)"
ITEM SIZE LIMIT USED FREE REQUESTS
FAILURES
NetGraph items: 72, 8207, 1, 376,
1052612, 0
NetGraph data items: 72, 2059, 0, 319,
1550143610, 0
#
Ну и всё это - и тут, и выше - данные самого netgraph, непосредственно же
пакеты данных лежат в буферах зон mbuf*
--
WBR, Vadim Goncharov
