ALT Linux sysadmins discussion
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@altlinux.ru>
To: Sysadmins@lists.altlinux.org
Subject: Re: [Sysadmins] Что это может быть (dmesg)?
Date: Fri, 5 Apr 2013 19:45:56 +0400
Message-ID: <20130405194556.67b1ad63@center4.lan.mivlgu.ru> (raw)
In-Reply-To: <CAA8E9_s_+a7v1yO0M2t1NvfHYyQ2fzFrUE5bB6j6w_Vxtg4oLA@mail.gmail.com>

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


  parent reply	other threads:[~2013-04-05 15:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 12:02     ` Anton Gorlov
2013-04-05 12:12         ` Anton Gorlov
2013-04-05 15:45 ` Sergey Vlasov [this message]
2013-04-29 12:22     ` Michael Shigorin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130405194556.67b1ad63@center4.lan.mivlgu.ru \
    --to=vsu@altlinux.ru \
    --cc=Sysadmins@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux sysadmins discussion

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/sysadmins/0 sysadmins/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 sysadmins sysadmins/ http://lore.altlinux.org/sysadmins \
		sysadmins@lists.altlinux.org sysadmins@lists.altlinux.ru sysadmins@lists.altlinux.com
	public-inbox-index sysadmins

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.sysadmins


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git