From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.2.5 Date: Fri, 5 Apr 2013 19:45:56 +0400 From: Sergey Vlasov To: Sysadmins@lists.altlinux.org Message-ID: <20130405194556.67b1ad63@center4.lan.mivlgu.ru> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.10; x86_64-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: Re: [Sysadmins] =?koi8-r?b?/tTPINzUzyDNz9bF1CDC2dTYIChkbWVzZyk/?= X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux sysadmins' discussion List-Id: ALT Linux sysadmins' discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 15:46:05 -0000 Archived-At: List-Archive: 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] [] > __alloc_pages_nodemask+0x67f/0x8b0 > [34302.847019] [] kmem_getpages+0x66/0x180 > [34302.847023] [] fallback_alloc+0x17f/0x240 > [34302.847026] [] ____cache_alloc_node+0x90/0x150 > [34302.847030] [] kmem_cache_alloc+0xe3/0x170 > [34302.847035] [] sk_prot_alloc+0x43/0x180 > [34302.847038] [] sk_clone+0x1b/0x300 > [34302.847043] [] inet_csk_clone+0x11/0xc0 > [34302.847047] [] tcp_create_openreq_child+0x24/0x4c0 > [34302.847051] [] 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 : tunables : slabdata 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 получить не удастся.