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

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

[Anton Gorlov]

05.04.2013 13:43, Yuri Khachaturyan пишет:
> top - 13:42:05 up 18:45,  2 users,  load average: 0.30, 0.15, 0.15
> Tasks: 170 total,   3 running, 167 sleeping,   0 stopped, 0 zombie
> CPU0  : 14.0%us,  4.3%sy,  0.3%ni, 81.4%id,  0.0%wa,  0.0%hi,  0.0%si, 
>  0.0%st
> CPU1  :  4.3%us,  0.3%sy,  0.0%ni, 84.1%id, 11.3%wa,  0.0%hi,  0.0%si, 
>  0.0%st
> CPU2  :  5.6%us,  2.2%sy,  0.0%ni, 91.5%id,  0.6%wa,  0.0%hi,  0.0%si, 
>  0.0%st
> CPU3  :  3.0%us,  0.3%sy,  0.0%ni, 96.7%id,  0.0%wa,  0.0%hi,  0.0%si, 
>  0.0%st
> Mem:   8130940K total,  7416924K used,   714016K free,  62400K buffers
> Swap:        0K total,        0K used,        0K free,  4980212K cached
>
Добавьте хотя бы пару гигов свопа. Должно помочь

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

[Anton Gorlov]

05.04.2013 16:09, Stanislav Vlasov пишет:
> Про память лучше всё-таки спрашивать free.
> Оно там нагляднее видно.
> Но даже из того топа, что прислан - видно, что там 5Гб кеша и буферов, 
> что можно не учитывать в объёме занятой памяти.
как показывает практика "ага, щазз"
Особенно если приложению понадобилась кучка не фрагментированной памяти.
Буквально на днях наблюдал смерть мускла с криками что мало памяти при 
кеше и буферах на почти 10гиг в сумме

Re: [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 получить не удастся.

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

[Michael Shigorin]

On Fri, Apr 26, 2013 at 05:08:15PM +0400, Yuri Khachaturyan wrote:
> На одном из серверов проблема сохраняется и повторяется достаточно часто:
[...]
> Что это может быть? Битая память? Как отследить?

Если на одном -- стоит её пропылесосить и, возможно,
по очереди поснимать планки (в идеале заменяя на
заведомо рабочие).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/