Docker “não pode alocar memória” - ajuste de memória virtual

Question

Estamos construindo ou executando contêineres do Docker em nossas instâncias do Jenkins criadas em cima do Centos7 no AWS EC2. Temos 2 instâncias de caixas t2.medium com 2 CPUs e 3,5 Gb de memória disponível.
Em um caso, estamos construindo os contêineres em outro, estamos apenas puxando-os e rodando (contêiner diferente).

Começamos a receber erros

open /var/lib/docker/overlay/<sha>-init/merged/dev/console: cannot allocate memory

e em journalctl obtemos

page allocation failure: order:4

O despejo de cache da página em execução resolve o problema por algum tempo

echo 1 > /proc/sys/vm/drop_caches

Então, percebi que, durante a execução da tarefa do docker,% de picos no bloco de memóriaDirty (como deveria) e Mapped saltam após ela. No entanto, o DirectMap4k é relativamente próximo desse salto.

Por exemplo:
Máquina ociosa

cat /proc/meminfo | grep -P "(Dirty|Mapped|DirectMap4k)"
Dirty:               104 kB
Mapped:            45696 kB
DirectMap4k:      100352 kB

Máquina ativa

cat /proc/meminfo | grep -P "(Dirty|Mapped|DirectMap4k)"
Dirty:             72428 kB
Mapped:            70192 kB
DirectMap4k:      100352 kB

Portanto, esta máquina leva algum tempo para começar a falhar, enquanto a máquina idêntica reporta DirectMap4k: 77824 kB e, portanto, falha regularmente (também precisa manipular a construção de um container mais complexo), mas sysctl vm é idêntico.

O problema subjacente que cria / boot do contêiner do docker gera um erro de falta de memória e a pergunta é o que precisa ser ajustado para o kernel para torná-lo estável.

Versão do Docker

Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:20:36 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:21:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

Kernel 3.10.0-327.10.1.el7.x86_64

sysctl vm

vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 30
vm.dirty_writeback_centisecs = 500
vm.drop_caches = 1
vm.extfrag_threshold = 500
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.max_map_count = 65530
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 4096
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.nr_pdflush_threads = 0
vm.numa_zonelist_order = default
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
vm.swappiness = 30
vm.user_reserve_kbytes = 108990
vm.vfs_cache_pressure = 100
vm.zone_reclaim_mode = 0

    

Answer 1

TL; DR

sudo su
sysctl -w vm.swappiness=10

Explicação

Eu criei um cenário de teste onde posso reproduzir esse erro 10/10 vezes. Isso é apenas criar uma imagem maior diretamente por meio da linha de comando, e não por meio do IC.

como mencionado solução que eu sabia que era

echo 1 > /proc/sys/vm/drop_caches

Então, tentei correlacionar com DirectMap valores. Como aprendi que esses valores representam a carga TLB e não podem ser ajustados diretamente, procurei o valor de preferência para usá-los e isso é swappiness.

RHLE 7 Docs explicam a permuta :

⁠swappiness

The swappiness value, ranging from 0 to 100, controls the degree to which the system favors anonymous memory or the page cache. A high value improves file-system performance while aggressively swapping less active processes out of RAM. A low value avoids swapping processes out of memory, which usually decreases latency at the cost of I/O performance. The default value is 60.

WARNING
Setting swappiness==0 will very aggressively avoids swapping out, which > increase the risk of OOM killing under strong memory and I/O pressure.

Portanto, reduzi-lo diminui a dependência de páginas de cache de memória. Por padrão, o EC2 Centos 7 Imagens que usamos, defini-lo como 30, então reduzi-lo a 10 fez com que a imagem grande fosse construída com sucesso 10/10 vezes.