Onde está indo a memória do meu contêiner?

4

Eu tenho um contêiner vazando memória. Ou pelo menos, o consumo de memória relatado aumenta rapidamente. Se eu correr de cima, eu entendo isso:

top - 16:56:51 up 6 days, 17:25,  0 users,  load average: 0.16, 0.27, 0.31
Tasks:   4 total,   1 running,   3 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.3 us,  0.7 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   7676380 total,  4089380 used,  3587000 free,   675164 buffers
KiB Swap:        0 total,        0 used,        0 free.  2586496 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    1 root      20   0   46924  15196   6456 S   0.0  0.2   0:15.54 supervisord
    8 root      20   0 3526084  47976  29660 S   0.0  0.6   0:59.15 dotnet
  568 root      20   0   20364   3332   2728 S   0.0  0.0   0:00.09 bash
 2800 root      20   0   21956   2420   2032 R   0.0  0.0   0:00.00 top

O número que recebo neste momento é de 90M, o que não se soma. Tenho certeza de que /sys/fs/cgroup/memory/memory.usage_in_bytes é o que está sendo relatado:

> cd /sys/fs/cgroup/memory/
> cat cgroup.procs
1
8
568
2494

> cat memory.usage_in_bytes
92282880

> pmap -p 1 | tail -n 1
 total            46924K

> pmap -p 8 | tail -n 1
 total          3599848K

> pmap -p 568 | tail -n 1
 total            20364K

> ps 2494
  PID TTY      STAT   TIME COMMAND

Aos meus olhos há uma quantidade significativa de memória 'ausente' aqui ... se eu cat memory.usage_in_bytes de novo ao longo do tempo que eu tenho digitado isso:

> cat memory.usage_in_bytes
112291840

> pmap -p 1 | tail -n 1
 total            46924K

> pmap -p 8 | tail -n 1
 total          3452320K

> pmap -p 568 | tail -n 1
 total            20368K

Nada obviamente explica esse uso de memória. Se eu olhar para memory.stat , vejo isto:

# cat memory.stat
cache 89698304
rss 30699520
rss_huge 0
mapped_file 1552384
writeback 0
pgpgin 102007
pgpgout 72613
pgfault 115021
pgmajfault 8
inactive_anon 1519616
active_anon 30789632
inactive_file 417792
active_file 87654400
unevictable 4096
hierarchical_memory_limit 18446744073709551615
total_cache 89698304
total_rss 30699520
total_rss_huge 0
total_mapped_file 1552384
total_writeback 0
total_pgpgin 102007
total_pgpgout 72613
total_pgfault 115021
total_pgmajfault 8
total_inactive_anon 1519616
total_active_anon 30789632
total_inactive_file 417792
total_active_file 87654400
total_unevictable 4096

Então, um momento depois:

# cat memory.stat
cache 89972736
rss 30777344
rss_huge 0
mapped_file 1552384
writeback 0
pgpgin 102316
pgpgout 72836
pgfault 115674
pgmajfault 8
inactive_anon 1519616
active_anon 30867456
inactive_file 417792
active_file 87928832
unevictable 4096
hierarchical_memory_limit 18446744073709551615
total_cache 89972736
total_rss 30777344
total_rss_huge 0
total_mapped_file 1552384
total_writeback 0
total_pgpgin 102316
total_pgpgout 72836
total_pgfault 115674
total_pgmajfault 8
total_inactive_anon 1519616
total_active_anon 30867456
total_inactive_file 417792
total_active_file 87928832
total_unevictable 4096

Mas eu vou ser honesto; Eu realmente não sei o que estou vendo aqui. Estou procurando de forma suspeita active_file , mas novamente; Eu realmente não sei o que estou vendo.

Algumas notas e observações:

  • O contêiner é agendado pelo Kubernetes.
  • Este programa grava muitos dados no stdout.
  • A redução da quantidade de dados gravados no console para quase zero resolve o vazamento de memória relatado.
  • A implantação de um programa que somente grava muitos dados no stdout não parece exibir o mesmo vazamento de memória (!)

Então! Como devo saber onde esta memória está sendo consumida? Existe alguma coisa óbvia para qualquer um - talvez algo esteja me encarando na cara ou não estou olhando para algo que eu deveria estar?

Obrigado!

    
por ledneb 21.02.2017 / 18:59

1 resposta

2

Em resumo; memory.usage inclui caches de disco. Eu deveria estar medindo ( memory.usage - memory.cache ). O problema (e perda de memória percebida) era que o supervisord estava escrevendo o stdout do meu programa em um arquivo de log.

    
por 27.02.2017 / 10:10