[Sysadmins] Что это может быть (dmesg)?
Yuri Khachaturyan
yukh на yukh.ru
Пт Апр 26 17:08:15 MSK 2013
На одном из серверов проблема сохраняется и повторяется достаточно часто:
[134118.883440] swapper: page allocation failure: order:1, mode:0x20
[134118.883446] Pid: 0, comm: swapper Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[134277.223458] php5-fpm: page allocation failure: order:1, mode:0x20
[134277.223465] Pid: 3718, comm: php5-fpm Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[135102.694001] swapper: page allocation failure: order:1, mode:0x20
[135102.694007] Pid: 0, comm: swapper Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[135412.344250] swapper: page allocation failure: order:1, mode:0x20
[135412.344255] Pid: 0, comm: swapper Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[135630.433746] swapper: page allocation failure: order:1, mode:0x20
[135630.433751] Pid: 0, comm: swapper Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[135816.365417] smbd: page allocation failure: order:1, mode:0x20
[135816.365423] Pid: 1942, comm: smbd Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[137965.370600] klogd: page allocation failure: order:1, mode:0x20
[137965.370605] Pid: 4029, comm: klogd Not tainted
3.0.74-std-def-alt0.M60P.1 #1
[137965.452384] php5-fpm: page allocation failure: order:1, mode:0x20
[137965.452391] Pid: 4935, comm: php5-fpm Not tainted
3.0.74-std-def-alt0.M60P.1 #1
В основном - ругается на swapper, но попадаются и другие процессы.
SWAP на месте:
# free -m
total used free shared buffers cached
Mem: 5983 5826 157 0 3 5457
-/+ buffers/cache: 365 5618
Swap: 1023 31 992
Что это может быть? Битая память? Как отследить?
5 апреля 2013 г., 19:45 пользователь Sergey Vlasov <vsu на altlinux.ru>написал:
> 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
> Sysadmins на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sysadmins
>
--
С уважением,
Хачатурян Юрий (yukh на yukh.ru)
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/sysadmins/attachments/20130426/d799b693/attachment-0001.html>
Подробная информация о списке рассылки Sysadmins