OOM apesar da memória disponível (cache)

Temos encontrado o OOM killer, apesar de quase metade da nossa memória estar sendo usada para o cache do FS. Registramos estatísticas de memória uma vez por minuto (conforme relatado na parte superior), mas parece haver muita disponibilidade.

...

Mem:  15339640k total, 15268304k used,    71336k free,     3152k buffers
Swap:        0k total,        0k used,        0k free,  6608384k cached

Mem:  15339640k total, 14855280k used,   484360k free,    13748k buffers
Swap:        0k total,        0k used,        0k free,  6481852k cached

[OOM killer: postgres killed]

Mem:  15339640k total,  8212200k used,  7127440k free,    32776k buffers
Swap:        0k total,        0k used,        0k free,  2394444k cached

...

Detalhes do OOM do syslog:

...
Jun 10 05:45:25 db kernel: [11209156.840462] wal-e invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:25 db kernel: [11209156.840469] wal-e cpuset=/ mems_allowed=0
Jun 10 05:45:25 db kernel: [11209156.840474] Pid: 7963, comm: wal-e Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:25 db kernel: [11209156.840477] Call Trace:
Jun 10 05:45:25 db kernel: [11209156.840498]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:25 db kernel: [11209156.840502]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:25 db kernel: [11209156.840506]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
Jun 10 05:45:25 db kernel: [11209156.840511]  [<ffffffff8111f823>] __alloc_pages_nodemask+0x8c3/0x8e0
Jun 10 05:45:25 db kernel: [11209156.840520]  [<ffffffff81216e00>] ? noalloc_get_block_write+0x30/0x30
Jun 10 05:45:25 db kernel: [11209156.840528]  [<ffffffff811566c6>] alloc_pages_current+0xb6/0x120
Jun 10 05:45:25 db kernel: [11209156.840534]  [<ffffffff81116637>] __page_cache_alloc+0xb7/0xd0
Jun 10 05:45:25 db kernel: [11209156.840539]  [<ffffffff81118602>] filemap_fault+0x212/0x3c0
Jun 10 05:45:25 db kernel: [11209156.840553]  [<ffffffff81138c32>] __do_fault+0x72/0x550
Jun 10 05:45:25 db kernel: [11209156.840557]  [<ffffffff8113c2ea>] handle_pte_fault+0xfa/0x200
Jun 10 05:45:25 db kernel: [11209156.840562]  [<ffffffff8100638e>] ? xen_pmd_val+0xe/0x10
Jun 10 05:45:25 db kernel: [11209156.840567]  [<ffffffff81005309>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Jun 10 05:45:25 db kernel: [11209156.840571]  [<ffffffff8113d559>] handle_mm_fault+0x269/0x370
Jun 10 05:45:25 db kernel: [11209156.840576]  [<ffffffff8100a56d>] ? xen_force_evtchn_callback+0xd/0x10
Jun 10 05:45:25 db kernel: [11209156.840581]  [<ffffffff8100ad42>] ? check_events+0x12/0x20
Jun 10 05:45:25 db kernel: [11209156.840589]  [<ffffffff8165b3cb>] do_page_fault+0x14b/0x520
Jun 10 05:45:25 db kernel: [11209156.840594]  [<ffffffff81160d64>] ? kmem_cache_free+0x104/0x110
Jun 10 05:45:25 db kernel: [11209156.840600]  [<ffffffff811ba2c8>] ? ep_remove+0xa8/0xc0
Jun 10 05:45:25 db kernel: [11209156.840604]  [<ffffffff811bb133>] ? sys_epoll_ctl+0xb3/0x3d0
Jun 10 05:45:25 db kernel: [11209156.840614]  [<ffffffff81658035>] page_fault+0x25/0x30
Jun 10 05:45:25 db kernel: [11209156.840617] Mem-Info:
Jun 10 05:45:25 db kernel: [11209156.840618] Node 0 DMA per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840622] CPU    0: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840624] CPU    1: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840627] CPU    2: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840629] CPU    3: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840631] Node 0 DMA32 per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840634] CPU    0: hi:  186, btch:  31 usd:  30
Jun 10 05:45:25 db kernel: [11209156.840637] CPU    1: hi:  186, btch:  31 usd:  47
Jun 10 05:45:25 db kernel: [11209156.840639] CPU    2: hi:  186, btch:  31 usd:  15
Jun 10 05:45:25 db kernel: [11209156.840641] CPU    3: hi:  186, btch:  31 usd:   2
Jun 10 05:45:25 db kernel: [11209156.840643] Node 0 Normal per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840646] CPU    0: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840648] CPU    1: hi:  186, btch:  31 usd:  14
Jun 10 05:45:25 db kernel: [11209156.840650] CPU    2: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840653] CPU    3: hi:  186, btch:  31 usd:   1
Jun 10 05:45:25 db kernel: [11209156.840658] active_anon:3616567 inactive_anon:4798 isolated_anon:0
Jun 10 05:45:25 db kernel: [11209156.840660]  active_file:98 inactive_file:168 isolated_file:20
Jun 10 05:45:25 db kernel: [11209156.840661]  unevictable:1597 dirty:73 writeback:0 unstable:0
Jun 10 05:45:25 db kernel: [11209156.840662]  free:16921 slab_reclaimable:17631 slab_unreclaimable:7534
Jun 10 05:45:25 db kernel: [11209156.840663]  mapped:1614529 shmem:1613928 pagetables:124012 bounce:0
Jun 10 05:45:25 db kernel: [11209156.840666] Node 0 DMA free:7888kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:7632kB 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
Jun 10 05:45:25 db kernel: [11209156.840681] lowmem_reserve[]: 0 4016 15112 15112
Jun 10 05:45:25 db kernel: [11209156.840686] Node 0 DMA32 free:48368kB min:4176kB low:5220kB high:6264kB active_anon:3776804kB inactive_anon:28kB active_file:0kB inactive_file:20kB unevictable:932kB isolated(anon):0kB isolated(file):0kB present:4112640kB mlocked:932kB dirty:0kB writeback:0kB mapped:1458536kB shmem:1458632kB slab_reclaimable:17604kB slab_unreclaimable:8088kB kernel_stack:1872kB pagetables:190616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:437 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840698] lowmem_reserve[]: 0 0 11095 11095
Jun 10 05:45:25 db kernel: [11209156.840703] Node 0 Normal free:11428kB min:11548kB low:14432kB high:17320kB active_anon:10689464kB inactive_anon:19164kB active_file:528kB inactive_file:652kB unevictable:5456kB isolated(anon):0kB isolated(file):80kB present:11362176kB mlocked:5456kB dirty:292kB writeback:0kB mapped:4999580kB shmem:4997080kB slab_reclaimable:52920kB slab_unreclaimable:22048kB kernel_stack:2584kB pagetables:305432kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1974 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840715] lowmem_reserve[]: 0 0 0 0
Jun 10 05:45:25 db kernel: [11209156.840720] Node 0 DMA: 2*4kB 3*8kB 1*16kB 3*32kB 3*64kB 3*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 0*4096kB = 7888kB
Jun 10 05:45:25 db kernel: [11209156.840752] Node 0 DMA32: 5813*4kB 2636*8kB 114*16kB 15*32kB 5*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 48372kB
Jun 10 05:45:25 db kernel: [11209156.840776] Node 0 Normal: 1888*4kB 10*8kB 46*16kB 4*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 11760kB
Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages
Jun 10 05:45:25 db kernel: [11209156.840790] 0 pages in swap cache
Jun 10 05:45:25 db kernel: [11209156.840801] Swap cache stats: add 0, delete 0, find 0/0
Jun 10 05:45:25 db kernel: [11209156.840803] Free swap  = 0kB
Jun 10 05:45:25 db kernel: [11209156.840805] Total swap = 0kB
Jun 10 05:45:25 db kernel: [11209156.909794] 3934192 pages RAM
Jun 10 05:45:25 db kernel: [11209156.909804] 99282 pages reserved
Jun 10 05:45:25 db kernel: [11209156.909809] 18899146 pages shared
Jun 10 05:45:25 db kernel: [11209156.909811] 2198511 pages non-shared
Jun 10 05:45:25 db kernel: [11209156.909817] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
Jun 10 05:45:25 db kernel: [11209156.909835] [  332]     0   332     4308      109   1       0             0 upstart-udev-br
Jun 10 05:45:25 db kernel: [11209156.909845] [  346]     0   346     5384      271   2     -17         -1000 udevd
Jun 10 05:45:25 db kernel: [11209156.909851] [  408]     0   408     5364      174   2     -17         -1000 udevd
...
Jun 10 05:45:25 db kernel: [11209156.910703] [ 7963]   111  7963    17456     2966   0       0             0 wal-e
Jun 10 05:45:25 db kernel: [11209156.910707] [ 7968]   111  7968  1639372     2351   3       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910711] [ 7969]   111  7969  1639371     1934   2       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910716] Out of memory: Kill process 12443 (postgres) score 418 or sacrifice child
Jun 10 05:45:25 db kernel: [11209156.910733] Killed process 12443 (postgres) total-vm:6555152kB, anon-rss:4600kB, file-rss:6396572kB
Jun 10 05:45:30 db kernel: [11209159.293083] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:31 db kernel: [11209159.293091] postgres cpuset=/ mems_allowed=0
Jun 10 05:45:31 db kernel: [11209159.293095] Pid: 6508, comm: postgres Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:31 db kernel: [11209159.293098] Call Trace:
Jun 10 05:45:31 db kernel: [11209159.293111]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:31 db kernel: [11209159.293115]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:31 db kernel: [11209159.293119]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
...

Podemos tentar aumentar a resolução destes para aproximadamente uma vez por segundo, mas haveria alguma razão para uma OOM aqui? (Vimos http://bl0rg.krunch.be/oom-frag.html, mas estamos trabalhando com quantidades absolutas de memória muito maiores, a maioria das quais é obtida pelo cache FS do kernel.)

Também incluindo partes relevantes da nossa postgresql.confabaixo:

shared_buffers = 6GB
effective_cache_size = 8GB

postgresql oom Yang
fonte

Discussão em bate-papo relacionado

Yang

Hum ... 3.2.0-43? Tempo de atualização. O assassino da OOM passou por muitas (demais) alterações ao longo do tempo. Algumas versões foram realmente muito mortíferas quanto à contabilização do uso de memória compartilhada ... como o PostgreSQL 9.2 e mais antigo shared_buffers.

Craig Ringer

@CraigRinger Infelizmente, existem outras considerações, incluindo manter o kernel na distribuição Ubuntu 12.04 para LTS, compatibilidade, atualizações de segurança, etc. Estamos interessados apenas se alguém souber explicar o que está acontecendo aqui - se ajudar, finja que estamos não está interessado em mudar o status quo / resolver o problema. BTW shared_buffersainda está na PG9.3.

Yang

Sim shared_buffersainda está na 9.3, mas não é mais a memória compartilhada POSIX na 9.3. Foi substituído por uma mmap()edregião anônima . Isso contorna alguns problemas nojentos de configuração do kernel e problemas de fixação, embora eu duvide que isso torne o assassino do OOM menos confuso.

Craig Ringer

Possivelmente uma duplicata de serverfault.com/questions/288319/… , que tem uma resposta em potencial.

richvdh

Respostas:

Parece que você (e eu, em um caso com sintomas muito semelhantes) realmente ficou sem memória e ficou confuso com o cachednúmero.

Aparentemente, existem casos em que o Linux não libera o cache de disco grande quando a demanda de memória aumenta

Em particular (eu realmente não entendo o porquê), o postgres ' shared_bufferspode ser relatado em "Em cache" (o cache da página). No seu caso, o 6481852k cachedin topcorresponde a esta linha no log do OOM-killer:

Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages

(1615243 * 4KB ~ = 6481852k) - o que significa que o cache da página não foi descartado antes de chamar o OOM-killer.

No entanto, existem poucas páginas com suporte a arquivos (presumo que active_file:98 inactive_file:168seja semelhante ao Ativo (arquivo) / Inativo (arquivo) ) do / proc / meminfo ), portanto não são as páginas descartáveis que conhecemos e amamos.

A postagem em https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/ demonstra uma sessão de exemplo em que o encerramento do postgres leva à redução de "cache" pelo tamanho de shared_buffers(role para "E a maioria saiu do cache do disco - como esperado, porque foi usado para compartilhados." ) - infelizmente não indica a versão do postgres nem o kernel que foi usado para o experimento.

Estou usando 3.13.0-67 x86_64 com PG 9.3. Na 9.3, eles deixaram de usar a memória compartilhada do Sys V ( shmget) para anônimammap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork() (na 9.4 isso se tornou configurável via dynamic_shared_memory_type ). Mas não consegui encontrar explicações sobre por que esses mmap () devem aparecer em "cache" e por que, apenas https://access.redhat.com/solutions/406773 que diz "Cache: Memória no pagecache (Diskcache e memória compartilhada) "

Dado que há muitos tipos de memória compartilhada, eu estou iluminado e confuso ...

Nickolay
fonte

Depois de vários anos, essa é uma resposta muito melhor, obrigado. Ainda há a questão de por que isso é contabilizado em cache, mas estou marcando isso como aceito por enquanto.

Yang

Pelo amor de tudo de bom no mundo, configure o espaço de troca em seus servidores .
Você realmente precisa de espaço de troca . Eu não sou o único que diz isso , é praticamente uma verdade universal por aqui . (<- Esses são três links)
É claro que você deve ter RAM suficiente para que o servidor do banco de dados não troque regularmente - se a solução não for dinheiro (o que você leva seu fornecedor e usa para adquirir mais RAM) .
Como agora você tem RAM adequada e troca para usar se algo der errado, você pode desativar o killer do OOM (desativando a confirmação de memória excessiva), como as pessoas do Postgres recomendam .
(Você também pode aplicar a solução alternativa e dizer ao OOM-Killer para nunca matar o Postgres - mas você está jogando Roleta Russa com o restante dos processos do seu sistema ...)
(opcional) Escreva uma resposta no Server Fault detalhando por que o comportamento padrão na maioria das distribuições Linux é Ruim, Errado e viola a especificação POSIX de como o malloc () deve se comportar . Repita até que todo mundo esteja cansado de ouvir sobre isso.

Observe também que a memória em cache do kernel está disponível para o postgres (ou qualquer outro aplicativo) a ser usada - você deve considerá-la como memória livre / disponível em seus cálculos.

Se eu precisasse adivinhar o que está acontecendo aqui, diria que você tem uma consulta complexa, o Postgres está solicitando a RAM para executá-la e, em vez de dizer "Não tenho essa RAM", o Linux diz ao Postgres: "Claro, você pode ter. "
Então, quando Postgres realmente tenta usar a memória RAM era (supostamente) dada Linux percebe que não TEM o RAM que prometeu Postgres (porque está sobrecarregada) - o assassino OOM é dito para liberar a memória RAM, e obedientemente mata o programa usando mais memória - seu servidor de banco de dados.

O Postgres é um programa bem projetado. Se for dito que não pode ter a RAM que está solicitando, ele lidará com isso normalmente (ou se contentando com menos ou abortando com uma mensagem para o usuário).

voretaq7
fonte

Obrigado pela elaboração do swap, mas isso não responde à minha pergunta de por que isso está acontecendo em primeiro lugar . Sim, eu entendo a premissa básica de que o Linux é supercomprometido por padrão e que o OOM é quando estamos sem memória RAM - eu poderia ter dito isso na minha pergunta original. Mas a pergunta é por que está entrando quando eu ainda tenho bastante RAM (grande parte dela apenas no cache do FS)? Suponha que eu nem esteja interessado em mudar nada - que o assassino do OOM está bem, desde que eu entenda por que está sendo acionado.

Yang

Depois de revisar os links, infelizmente existem várias afirmações sem evidências de apoio ou explicações técnicas concretas. Certamente, há muitos ambientes Linux nos quais o swap nem sequer é uma opção (exemplo: não procure mais do que um Live CD onde ainda não existe uma partição local de swap para reutilização). Além disso, não estamos interessados em permitir a troca com base em nossas próprias experiências e ambiente - preferimos ter o OOM. Uma resposta à pergunta original seria apreciada.

Yang

@ Yang Presumo que, se você estiver construindo um servidor para o Postgres, siga as recomendações do projeto Postgres. Minha resposta é fazer o que eles dizem (desligue o assassino do OOM). Se você gostaria de esperar e ver se alguém lhe oferece uma resposta diferente, você certamente está livre para fazê-lo, mas não me sinto confortável em oferecer outra solução - Na minha opinião, o assassino do OOM é Ruim, Errado e viola o POSIX. Pode ser aceitável em uma área de trabalho / pior, mas desabilitá-la em servidores é: IMO, a coisa certa a fazer.

voretaq7

Eu deparei com essa situação em um servidor que possui swap e, após saturar a memória disponível + swap, o killer OOM foi usado em vez do kernel recuperar a memória "em cache", que obviamente estava de alguma forma bloqueada. Eu nunca resolvi o problema, mas a pergunta original de @ Yang não é respondida aqui.

Patrick

Swap não é a resposta, apenas faz com que o problema apareça mais tarde. Você precisa trocar quando a RAM está cheia e precisa do OOM Killer quando a RAM + troca fica cheia. Se a quantidade de troca for zero, você precisará do OOM Killer mais cedo, mas não poderá evitar o OOM Killer com troca.

Mikko Rantalainen 10/10