Hello, Vadim Goncharov!
On Tue, Apr 05, 2011 at 07:12:17PM +0700
[email protected] wrote about "Re: [freebsd] ngctl: send msg: No buffer
space available":
> 05.04.11 @ 18:16 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 обратно (память
> тоже не резиновая).
А что выяснилось ниже?
> >>>>>Добавил в 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.
Я готов крутить все что нужно, лишь бы помогло. Но четкого понимания
пока нету. :(
> >А как бы без прерывания пользовательских сессий узнать поднимится ли
> >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 и выше
похоже ничего не меняют? Верно?
Вот еще:
# 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
#
--
Lystopad Olexandr
