LINUX.ORG.RU
решено ФорумAdmin

отваливается vsftpd, page allocation failure

 ,


0

1

vsftpd-3.0.2, авторизация в Active Directory через pam_winbind.so.
переодически отваливается, не могу залогиниться, причины и закономерности отваливания не понятны, в dmesg вот это (при каждой попытке логина сыпится) http://pastebin.com/CsgpDNva
gentoo ~amd64, linux 3.6.2, glibc-2.15-r3

сейчас покрутил /proc/sys/vm/min_free_kbytes, вроде бы заработало, по крайней мере залогиниться получается. но всё равно интересно из-за чего это происходит и нормально ли это.. -__-

dorsett_case ()
Ответ на: комментарий от tailgunner

и нормально ли это..

При включенном overcommit - да.

А где-то про этом можно прочитать? В смысле что при включенном overcommit процессы могут «умирать» из-за нехватки памяти при наличии места в swap.

mky ★★★★★ ()
Ответ на: комментарий от mky

При наличии места в свапе умирать не будут, я думаю. Я пару раз сталкивался с проблемами аллокации на сервере с 48гб мозгов, который играет роль iscsi таргета и где почти вся память это дисковый кэш. Там вываливалсь ошибки в каком то демоне, который активно работал с памятью. Свапа не было.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

В случае ТС места в свопе достаточно:

Free swap = 4193052kB

У меня было что-то похожее. Проблемы с памятью при свопинге Процессы не убиваются ядром, они просто получают ошибку при выполнении системного вызова и завершаются сами. Причём я так и не понял, почему моей системе помогло отключения overcommit'а. Ошибка ведь происходила от того, что ядро не могло взять память для себя (для системного вызова). Вроде для этого всегда резервируется немного памяти /proc/sys/vm/min_free_kbytes , которая не отдаётся пользовательским процессам.

mky ★★★★★ ()
Ответ на: комментарий от mky

В смысле что при включенном overcommit процессы могут «умирать» из-за нехватки памяти при наличии места в swap.

Наличие свободного swap я прохлопал. Тогда проблема, конечно, в другом. Похоже, в DMA32 закончились страницы... какому-то драйверу не хватает памяти? Судя по стеку вызовов, это драйвер сетевой карты.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Как я уже писал, у меня была аналогичная ошибка с аналогичным стеком вызовов, с драйвером rtl8139, но вылечилось /proc/sys/vm/overcommit_memory = 2.

При этом от отключения overcommit'а потребление памяти/свопа практически не возрасло. То есть не так уж много было в моём случае памяти, которую процессы «попросили», но не использовали.

mky ★★★★★ ()
Ответ на: комментарий от mky

Как я уже писал, у меня была аналогичная ошибка с аналогичным стеком вызовов, с драйвером rtl8139

Тоже AMD64?

вылечилось /proc/sys/vm/overcommit_memory = 2.

Думаю, просто пейджер стал работать по-другому.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Памяти не хватает.

дык её 2Гб, по htop'у занято 169M

При включенном overcommit - да.

что-то сходу не нагуглил конкретики, что это?

dorsett_case ()
Ответ на: комментарий от dorsett_case

дык её 2Гб, htop'у занято 169M

Делается запрос на 128Кбайт единым куском.

какие зоны?

Это зона DMA:

Node 0 DMA: 54*4kB 11*8kB 8*16kB 17*32kB 11*64kB 10*128kB 3*256kB 1*512kB 2*1024kB 1*2048kB 0*4096kB = 8336kB

Это зона DMA32:

Node 0 DMA32: 9020*4kB 18472*8kB 722*16kB 3*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 197552kB

А это запрос памяти:

vsftpd: page allocation failure: order:5, mode:0xc0d0

Что происходит: делается запрос памяти 5 порядка (128Кбайт) и он не проходит; видим, что в зоне DMA такие куски есть, а в зоне DMA32 нет - значит, это запрос к DMA32. Память в зоне DMA32 нужна драйверам устройств, которые не поддерживают 64-бит шинные адреса; судя по стеку (tcp_net_metrics_init), заказ памяти делается из сетевой подсистемы, значит, первый подозреваемый - драйвер сетевой карты. Правда, ситуация всё равно мутная, потому что в DMA32 есть один протяженный кусок памяти в 2048k, и, IIUC, память должна быть выделена там.

Что можно попробовать: во-первых, 'echo 1 >/proc/sys/vm/compact_memory' - попробуй компактифицировать память; во-вторых, 'echo 2 > /proc/sys/vm/overcommit_memory' - это отключение overcommit, который не имеет прямого отношения к проблеме, но измененеие режима работы VMM может помочь.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Что можно попробовать: во-первых, 'echo 1 >/proc/sys/vm/compact_memory' - попробуй компактифицировать память; во-вторых, 'echo 2 > /proc/sys/vm/overcommit_memory' - это отключение overcommit, который не имеет прямого отношения к проблеме, но измененеие режима работы VMM может помочь.

а хуже не станет?

dorsett_case ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.