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 получить не удастся. _______________________________________________ Sysadmins mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/sysadmins
