Como Gerenciar Memória
Last updated
Last updated
O Docker oferece uma série de opções para limitar e monitorar o uso de memória dos containers, garantindo que eles não consumam mais recursos do que o necessário. Isso é crucial em ambientes de produção e multi-tenant, onde o gerenciamento eficiente de recursos é uma prioridade. Abaixo estão detalhadas as principais opções relacionadas ao monitoramento de memória no Docker, com exemplos de entrada e saída e cenários comuns de uso.
--memoryO parâmetro --memory define o limite máximo de memória física (RAM) que o container pode utilizar. Se o container tentar usar mais do que esse limite, o kernel do Linux poderá encerrar os processos do container com um erro "out of memory" (OOM).
Exemplo:
Neste exemplo, o container está limitado a usar 512MB de memória RAM.
Entrada:
--memory="512m"
Saída:
O container só poderá usar até 512MB de memória. Se tentar ultrapassar esse valor, ele poderá ser finalizado pelo sistema.
Uso comum: Esse parâmetro é usado para garantir que um container não consuma memória excessiva em um host, especialmente em ambientes com muitos containers em execução.
--memory-swapO parâmetro --memory-swap define o limite combinado de memória física (RAM) e swap que o container pode utilizar. O swap é uma área de disco usada para expandir a memória virtual, permitindo que o sistema armazene temporariamente partes da memória que não estão sendo ativamente usadas.
Exemplo:
Neste exemplo, o container pode usar até 512MB de RAM e até 1GB no total (RAM + swap).
Entrada:
--memory="512m"
--memory-swap="1g"
Saída:
O container poderá usar até 512MB de RAM e até 1GB de RAM + swap. O swap pode ser utilizado se a memória física se esgotar.
Uso comum: Em sistemas onde a memória RAM é limitada, mas o swap está disponível, esse parâmetro permite que o container use swap para evitar ser finalizado por falta de memória, embora o uso excessivo de swap possa afetar o desempenho.
--memory-swappinessO parâmetro --memory-swappiness ajusta a propensão do kernel do Linux a trocar a memória de um container para o espaço de swap. Ele aceita um valor entre 0 e 100. Um valor de 0 desativa a troca para swap (priorizando o uso de RAM), enquanto 100 permite que o kernel troque o máximo possível de dados para o swap.
Exemplo:
Aqui, o Docker ajusta o nível de swappiness para 10, o que significa que o kernel será bastante conservador em mover páginas de memória para o swap, priorizando o uso de RAM.
Entrada:
--memory="512m"
--memory-swap="1g"
--memory-swappiness="10"
Saída:
O container terá 512MB de RAM e 1GB de swap, com um baixo nível de swappiness, o que minimizará a troca de páginas de memória para o swap.
Uso comum: O ajuste de swappiness é útil em containers que executam workloads sensíveis à latência, onde o uso de swap pode prejudicar o desempenho da aplicação.
--oom-kill-disableEsse parâmetro desativa o mecanismo de Out of Memory (OOM) do kernel, que finaliza processos do container quando ele ultrapassa seu limite de memória. No entanto, mesmo com essa opção ativada, o container não poderá usar mais memória do que o limite definido.
Exemplo:
Neste exemplo, o OOM killer é desativado, o que significa que o container não será finalizado automaticamente ao atingir o limite de memória. No entanto, ele não poderá usar mais do que 512MB de memória.
Entrada:
--memory="512m"
--oom-kill-disable
Saída:
O container continuará funcionando, mas poderá ter suas operações bloqueadas ou degradadas caso atinja o limite de memória.
Uso comum: Esta opção é útil em cenários onde você prefere gerenciar manualmente o comportamento de falhas de memória, evitando o encerramento automático do container.
--oom-score-adjO parâmetro --oom-score-adj ajusta a pontuação de um processo para o OOM killer, que decide quais processos serão finalizados quando o sistema estiver com pouca memória. Esse valor pode variar entre -1000 (imune ao OOM) e 1000 (alta probabilidade de ser finalizado).
Exemplo:
Aqui, o container tem uma pontuação de 500, aumentando a chance de ser finalizado pelo OOM killer se o sistema estiver com pouca memória.
Entrada:
--oom-score-adj=500
Saída:
O container terá uma alta chance de ser finalizado pelo OOM killer se o sistema estiver em uma situação de pouca memória.
Uso comum: Essa opção é usada para ajustar a prioridade de finalização de containers em sistemas que rodam várias aplicações e onde o impacto da falta de memória precisa ser gerenciado.
--kernel-memoryEsse parâmetro define o limite de memória de kernel (memória usada pelo próprio kernel do sistema operacional para gerenciar recursos) que um container pode utilizar.
Exemplo:
Nesse caso, o container está limitado a usar 512MB de RAM e 50MB de memória do kernel.
Entrada:
--kernel-memory="50m"
Saída:
O container só poderá utilizar até 50MB da memória do kernel. Caso ultrapasse esse valor, ele poderá ser finalizado.
Uso comum: Esse parâmetro é mais avançado e utilizado em cenários onde há uma preocupação com a memória do kernel sendo consumida excessivamente por um container, o que pode impactar a estabilidade do sistema.
Esses parâmetros de controle de memória são cruciais em ambientes de produção, onde os recursos de memória precisam ser distribuídos com eficiência entre os containers para evitar esgotamentos de memória e maximizar o desempenho. Eles são especialmente úteis nos seguintes cenários:
Ambientes multi-tenant: onde vários containers compartilham os mesmos recursos de hardware, e é necessário garantir que nenhum container monopolize a memória.
Garantia de qualidade de serviço (QoS): onde diferentes containers têm diferentes necessidades de desempenho e sensibilidade a falta de memória.
Sistemas com restrições de memória: onde a quantidade total de memória RAM é limitada, mas o swap está disponível para uso temporário.
Neste exemplo, o container pode usar até 1GB de RAM e até 2GB no total, com uma política conservadora de uso de swap (swappiness de 15) e o OOM killer desativado para evitar encerramentos automáticos.
Esses parâmetros permitem controlar o uso de memória de containers de forma granular, oferecendo flexibilidade e previsibilidade na execução das workloads.
