LINUX.ORG.RU
Форум — General  

OOM killer вызван при достаточном объеме swap

 


0

1

Есть сервер c 16gb RAM. На нем установлен memcached с опциями: 

# pgrep -f -l memcached
14293 memcached -d -p 11211 -u memcached -m 14336 -c 32768 -P /var/run/memcached/memcached.pid -t 8 -l 0.0.0.0

Он был убит OOM killer при 1.4% swap usage. См. полное ядра сообщение ниже.

Поиск в Google показывает что такие ситуации возможны. К примеру:

Впрочем после чтения не совсем понятно что вызвало OOM в конкретном случае. Вроде бы исходя из: 

Pid: 14735, comm: memcached Not tainted 2.6.32-504.8.1.el6.centos.plus.x86_64 #1
Killed process 14731, UID 496, (memcached) total-vm:16485432kB, anon-rss:15755904kB, file-rss:264kB
Можно предположить что, так как memcached запущен с "-t 8", запрос был сделан одной из child threads процесса memcached(14731). Так же gfp_mask = 0xd0 = __GFP_FS | __GFP_IO | __GFP_WAIT

Вопрос что делать чтобы такого не происходило в будущем:

  • sys.vm.oom_kill_allocating_task=1 не подходит, так как allocating_task = «Pid: 14735, comm: memcached»
  • echo -1000 > /proc/`pidof memcached`/oom_score_adj не подходит по той же причине
  • Можно увеличить RAM или уменьшить размер памяти memcached (-m флаг). Но не ясно насколько нужно увеличивать RAM чтобы исключить такие ситуации в будующем.
  • Запускать memcached с "-L" флагом и установить sys.vm.oom_kill_allocating_task=1. Вроде бы как подходит так как -L «preallocate all memory up front». А sys.vm.oom_kill_allocating_task=1 в случае чего прибьет процесс запрашивающий пямять, а не memcached. 
memcached invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_score_adj=0
memcached cpuset=/ mems_allowed=0
Pid: 14735, comm: memcached Not tainted 2.6.32-504.8.1.el6.centos.plus.x86_64 #1
Call Trace:
 [<ffffffff810d4141>] ? cpuset_print_task_mems_allowed+0x91/0xb0
 [<ffffffff81127380>] ? dump_header+0x90/0x1b0
 [<ffffffff8122f37c>] ? security_real_capable_noaudit+0x3c/0x70
 [<ffffffff81127802>] ? oom_kill_process+0x82/0x2a0
 [<ffffffff81127741>] ? select_bad_process+0xe1/0x120
 [<ffffffff81127c40>] ? out_of_memory+0x220/0x3c0
 [<ffffffff81531d19>] ? _cond_resched+0x19/0x40
 [<ffffffff8113454f>] ? __alloc_pages_nodemask+0x89f/0x8d0
 [<ffffffff8116cc7a>] ? alloc_pages_current+0xaa/0x110
 [<ffffffff814acac7>] ? tcp_sendmsg+0x677/0xa20
 [<ffffffff8144fc13>] ? sock_sendmsg+0x123/0x150
 [<ffffffff8109eb00>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff8100988e>] ? __switch_to+0x26e/0x320
 [<ffffffff814d057a>] ? inet_recvmsg+0x5a/0x90
 [<ffffffff8144fa64>] ? move_addr_to_kernel+0x64/0x70
 [<ffffffff81451406>] ? __sys_sendmsg+0x406/0x420
 [<ffffffff81451629>] ? sys_sendmsg+0x49/0x90
 [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
CPU    2: hi:    0, btch:   1 usd:   0
CPU    3: hi:    0, btch:   1 usd:   0
CPU    4: hi:    0, btch:   1 usd:   0
CPU    5: hi:    0, btch:   1 usd:   0
CPU    6: hi:    0, btch:   1 usd:   0
CPU    7: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  52
CPU    1: hi:  186, btch:  31 usd: 161
CPU    2: hi:  186, btch:  31 usd:  31
CPU    3: hi:  186, btch:  31 usd:   0
CPU    4: hi:  186, btch:  31 usd:  34
CPU    5: hi:  186, btch:  31 usd: 190
CPU    6: hi:  186, btch:  31 usd: 121
CPU    7: hi:  186, btch:  31 usd:  24
Node 0 Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 163
CPU    1: hi:  186, btch:  31 usd:  50
CPU    2: hi:  186, btch:  31 usd:  61
CPU    3: hi:  186, btch:  31 usd:  35
CPU    4: hi:  186, btch:  31 usd:  41
CPU    5: hi:  186, btch:  31 usd: 103
CPU    6: hi:  186, btch:  31 usd: 159
CPU    7: hi:  186, btch:  31 usd: 131
active_anon:3504693 inactive_anon:496245 isolated_anon:0
 active_file:9239 inactive_file:9322 isolated_file:0
 unevictable:0 dirty:9508 writeback:2210 unstable:0
 free:33760 slab_reclaimable:5394 slab_unreclaimable:11120
 mapped:1713 shmem:0 pagetables:8675 bounce:0
Node 0 DMA free:15688kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15304kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 3246 16124 16124
Node 0 DMA32 free:64760kB min:13592kB low:16988kB high:20388kB active_anon:2344960kB inactive_anon:653348kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3324612kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:60kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:255 all_unreclaimable? no
lowmem_reserve[]: 0 0 12877 12877
Node 0 Normal free:54592kB min:53924kB low:67404kB high:80884kB active_anon:11673812kB inactive_anon:1331632kB active_file:36956kB inactive_file:37288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:13186560kB mlocked:0kB dirty:38032kB writeback:8840kB mapped:6852kB shmem:0kB slab_reclaimable:21516kB slab_unreclaimable:44480kB kernel_stack:1592kB pagetables:34700kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2112 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 2*4kB 2*8kB 1*16kB 1*32kB 2*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15688kB
Node 0 DMA32: 46*4kB 30*8kB 21*16kB 6*32kB 11*64kB 5*128kB 6*256kB 9*512kB 7*1024kB 18*2048kB 3*4096kB = 64760kB
Node 0 Normal: 2000*4kB 1303*8kB 963*16kB 320*32kB 133*64kB 12*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 54120kB
24388 total pagecache pages
5460 pages in swap cache
Swap cache stats: add 361658, delete 356198, find 541068/558694
Free swap  = 10144088kB
Total swap = 10289148kB
4194303 pages RAM
81248 pages reserved
20592 pages shared
4054912 pages non-shared
[ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
[  485]     0   485     2762        1   0     -17         -1000 udevd
[ 1110]     0  1110    23298       81   1     -17         -1000 auditd
[ 1126]     0  1126    62465     1229   4       0             0 rsyslogd
[ 1144]    32  1144     4744       53   2       0             0 rpcbind
[ 1376]     0  1376     1016        2   6       0             0 mingetty
[ 1378]     0  1378     1016        2   2       0             0 mingetty
[ 1380]     0  1380     1016        2   7       0             0 mingetty
[ 1382]     0  1382     1016        2   1       0             0 mingetty
[ 1385]     0  1385     2739        1   2     -17         -1000 udevd
[ 1386]     0  1386     1016        2   1       0             0 mingetty
[ 1387]     0  1387     2739        1   4     -17         -1000 udevd
[ 1389]     0  1389     1016        2   7       0             0 mingetty
[ 1390]     0  1390     1019        2   4       0             0 agetty
[14731]   496 14731  4121358  3939042   4       0             0 memcached
[32141]    29 32141     5837      112   0       0             0 rpc.statd
[32176]     0 32176    29302      204   5       0             0 crond
[32460]    38 32460     7684      215   4       0             0 ntpd
[17184]     0 17184    19762      247   0       0             0 master
[17187]    89 17187    19824      263   1       0             0 qmgr
[ 5230]     0  5230    16103      207   4     -17         -1000 sshd
[22617]     0 22617    49559     1313   0       0             0 snmpd
[ 5541]     0  5541    35441     9985   7       0             0 ruby
[12037]   497 12037    10325      166   5       0             0 nrpe
[ 8734]     0  8734    48576     2908   1       0             0 denyhosts.py
[10332]    89 10332    19782      374   4       0             0 pickup
[10534]     0 10534    35023      303   6       0             0 crond
[10535]     0 10535    26514      144   6       0             0 sh
[10536]     0 10536    58744    32371   7       0             0 puppet
[10871]     0 10871    64183    13033   0       0             0 yum
Out of memory: Kill process 14731 (memcached) score 595 or sacrifice child
Killed process 14731, UID 496, (memcached) total-vm:16485432kB, anon-rss:15755904kB, file-rss:264kB
★

Если мне не изменяет память - OOM Killer приходит не при переполнении свопа, а при заполнении RAM

крути swappiness

r0ck3r ★★★★★
()
Ответ на: комментарий от r0ck3r

Если мне не изменяет память - OOM Killer приходит не при переполнении свопа, а при заполнении RAM крути swappiness

Крутить swappiness как я понимаю имел бы смысл если система не успевает скидывать страницы на диск из-за медленного disk I/O.

В данном случае никакого disk I/O не было. memcached был запущен несколько месяцев назад и использование памяти оставалось стабильным на протяжение месяцов. Т.е. запрос на небольшое увеличение памяти вызвал OOM. Т.е. swappiness не имеет особого смысла.

http://linux-mm.org/OOM упоминает сходную ситуацию:

It is also possible for the system to find itself in a sort of deadlock. Writing data out to disk may, itself, require allocating memory for various I/O data structures. If the system cannot find even that memory, the very functions used to create free memory will be hamstrung and the system will likely run out of memory.

и предлагают увеличивать vm.min_free_kbytes.

Впрочем не понятно насколько vm.min_free_kbytes нужно увеличить vm.min_free_kbytes. Сейчас стоит 67584. Соответственно возникает вопрос. Исходя из вывода OOM killer можно ли установить на сколько увеличить vm.min_free_kbytes? Или увеличивать эмпрически и ждать покуда OOM killer убьет memcached снова.

tungus ★
() автор топика

Поиск в Google показывает что такие ситуации возможны.

Скорее всего происходит то, что описано по первой ссылке. Какой-то из процессов в процессе работы безбожно фрагментирует память (не обязательно memcached), размер максимально доступного непрерывного куска уменьшается, пока кто-то не попросит больший, чем есть в наличии (и опять это не обязательно сам memcached, а, скажем, вызов ядра, который он дёрнул) кусочек, а меры по выгрузке страниц не приводят к его немедленному появлению.
Общий объём свободной памяти на этот момент роли не играет: в наличии может быть сотня мегабайт кусочков по 4k, и ни одного на 256k.

Тюнинг OOM тут ничем не поможет: это уже следствие. Тюнинг свободной памяти тоже: будет просто больше свободных мелких кусочков.
Не исключаю, что высокий swappiness оттянет неминуемое.

Пора апгрейдиться до 64Гб, короче :)

aidaho ★★★★★
()

memcached избегает использовать swap. Попробуй запускать memcached с '-k'.
Также по хорошему memcached не должен брать под себя больше 75% реальной памяти. Хотя тут от количество памяти конечно зависит, и других процессов, но не нужно забывать что лучше чтобы ничто в swap не уходило лишний раз.

anonymous_sama ★★★★★
()
Последнее исправление: anonymous_sama (всего исправлений: 1)
Ответ на: комментарий от aidaho

Скорее всего происходит то, что описано по первой ссылке. Какой-то из процессов в процессе работы безбожно фрагментирует память (не обязательно memcached), размер максимально доступного непрерывного куска уменьшается, пока кто-то не попросит больший, чем есть в наличии (и опять это не обязательно сам memcached, а, скажем, вызов ядра, который он дёрнул) кусочек, а меры по выгрузке страниц не приводят к его немедленному появлению.

В таком случае как я понимаю достаточно запускать memcached с "-L" и установить sys.vm.oom_kill_allocating_task=1 как предположено выше.

  • "-L" - preallocate all memory up front. Так что memcached не будет делать аллокаций в процессе работы.
  • sys.vm.oom_kill_allocating_task=1 - в случае чего прибет процесс запрашивающий память, а не memcached
  • Так же возможно стоить увеличить vm.min_free_kbytes чтобы процессы быстрее уходили в swap
tungus ★
() автор топика
Ответ на: комментарий от anonymous_sama

memcached избегает использовать swap. Попробуй запускать memcached с '-k'.

Я так понимаю это не поможет. Memcached был прибит потому что закончилась RAM. Так что использование -k флага только увеличивает вероятность повторения ситуации.

Также по хорошему memcached не должен брать под себя больше 75% реальной памяти. Хотя тут от количество памяти конечно зависит, и других процессов, но не нужно забывать что лучше чтобы ничто в swap не уходило лишний раз.

Возможно. Но на данной системе есть 16Gb RAM, 10Gb swap. Memcached запущен с -m 14G. Т.е. в принципе для системы есть 2Gb RAM + 10Gb swap. Никаких существенных процессов на данном сервере не крутится.

Наверное второй процесс по потреблению памяти это puppet, но

  • Он запускается периодически через cron. Так что всякие memory leaks не существенны.
  • Тот же puppet работает на других машинах c 512-1024MB RAM без особых проблем.
tungus ★
() автор топика
Ответ на: комментарий от tungus

"-L" - preallocate all memory up front.

Звучит хорошо. Месиво возникает, когда постоянно malloc()/free() дёргается.
По остальным пунктам я бы ничего не делал.

aidaho ★★★★★
()
Ответ на: комментарий от tungus

memcached не должен выходить за 14Gb для object storage, если ему недостаточно места, то он просто удалит что-то из кэша, но за эти 14Gb не выйдет и c "-k" такое поведение будет происходить более стабильно. "-m" указывает количество памяти под object storage, реально потребление памяти будет немного больше, что в твоем случае и наблюдается, поэтому и приходит oom-killer.

anonymous_sama ★★★★★
()
Последнее исправление: anonymous_sama (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
General