[Sysadmins] Что это может быть (dmesg)?

[Sergey Vlasov]

On Fri, 5 Apr 2013 12:57:31 +0400 Yuri Khachaturyan wrote:

> С недавнего времени в dmesg наблюдаю следующее (см. ниже).
> Кто подскажет что это может быть - железо? память?

Вечная проблема с фрагментацией памяти...

> [34302.846989] smtp: page allocation failure. order:1, mode:0x20

Запрашивается блок размером 2 страницы (order:1) с флагом GFP_ATOMIC
(необходимо найти свободный блок немедленно - нельзя ожидать
освобождения памяти).

> [34302.846996] Pid: 13462, comm: smtp Not tainted 2.6.39-std-def-alt3.2 #1
> [34302.846998] Call Trace:
> [34302.847001]  <IRQ>  [<ffffffff810fa29f>]
> __alloc_pages_nodemask+0x67f/0x8b0
> [34302.847019]  [<ffffffff81136786>] kmem_getpages+0x66/0x180
> [34302.847023]  [<ffffffff811376cf>] fallback_alloc+0x17f/0x240
> [34302.847026]  [<ffffffff81137490>] ____cache_alloc_node+0x90/0x150
> [34302.847030]  [<ffffffff81137da3>] kmem_cache_alloc+0xe3/0x170
> [34302.847035]  [<ffffffff813465d3>] sk_prot_alloc+0x43/0x180
> [34302.847038]  [<ffffffff8134681b>] sk_clone+0x1b/0x300
> [34302.847043]  [<ffffffff81393cd1>] inet_csk_clone+0x11/0xc0
> [34302.847047]  [<ffffffff813ad0f4>] tcp_create_openreq_child+0x24/0x4c0
> [34302.847051]  [<ffffffff813ab528>] tcp_v4_syn_recv_sock+0x48/0x270

Причина запроса - приём очередного TCP-соединения; параметры
соответствующего slab cache можно увидеть в /proc/slabinfo:

$ head -n2 /proc/slabinfo; grep -w TCP /proc/slabinfo
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
TCP                   19     32   1664    4    2 : tunables   24   12    8 : slabdata      8      8      0

(вообще на разных версиях ядра параметры могут несколько отличаться, но
в попавшихся под руку тоже pagesperslab=2).

> [34302.847245] Node 0 DMA: 0*4kB 1*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15912kB
> [34302.847256] Node 0 DMA32: 26048*4kB 22*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 104368kB
> [34302.847267] Node 0 Normal: 11246*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 47032kB

Свободная память вроде бы и есть, но в основном в виде одиночных
страниц, а найти непрерывный блок даже из 2 страниц существенно сложнее
(вообще-то такие блоки есть, но часть памяти резервируется для совсем
особых случаев, к которым не относится даже GFP_ATOMIC - например, для
использования в процессе работы OOM killer, если для завершения процесса
вдруг временно понадобится ещё немного памяти, или для процессов с
установленным флагом PF_MEMALLOC, успешная работа которых должна
привести к освобождению памяти).

Реально работающих методов борьбы с этим безобразием, кроме подъёма
/proc/sys/vm/min_free_kbytes, практически нет.  Хотя именно на выбор
параметров slab cache в данном случае можно было бы повлиять параметром
ядра slab_max_order=0 (ценой некоторого увеличения бесполезных потерь
памяти).  Однако этот параметр доступен только начиная с ядра 3.3.

Вообще calculate_slab_order() в данном случае ведёт себя не совсем
оптимальным образом - на 1 страницу может влезть 2*1664, на 2 страницы -
4*1664, поэтому никакого преимущества по использованию памяти при выборе
order=1 получить не удастся.