Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?

Um contentor em execução mantém o antigo limite de memória quando a configuração Compose editada nunca foi aplicada ao cgroup ativo desse contentor.

A alteração do YAML não modifica, por si só, um contentor existente, e um reinício normal inicia o mesmo contentor com a mesma configuração definida no momento da criação. A confusão também surge ao comparar um limite máximo de memória com uma reserva, uma permissão de utilização de swap, um âmbito systemd principal ou uma definição de heap da aplicação. Diagnostique o valor efetivo do cgroup e o ID do contentor antes de concluir que o Docker ignorou a alteração.

Leia o limite do Cgroup ativo em vez de confiar no YAML

Registe o ID do contentor, a hora de criação, o resultado da inspeção do Docker, a versão do cgroup e os ficheiros de controlo de memória utilizados pelo processo em execução.

O kernel Linux define memory.max como o limite máximo do cgroup, enquanto memory.high aplica pressão de recuperação sem funcionar como o mesmo limite absoluto.

Se o cgroup ativo ainda contiver o valor antigo, a configuração não foi aplicada. Se contiver o novo valor mas a monitorização discordar, verifique as unidades, a contabilização da cache, a swap e as métricas ao nível da aplicação.

Distinguir reinício de recriação do contentor

Compare o ID do contentor antes e depois do comando utilizado para implementar a alteração. Registe se o comando foi restart, up, create, uma ação da interface de uma NAS ou uma atualização direta do Docker.

O Docker indica que o reinício do Compose não aplica alterações de configuração, pois reinicia os contentores de serviço existentes.

Utilize uma atualização controlada do Compose que recrie o serviço ou uma atualização de recursos ativa suportada, quando apropriado. Preserve o resultado da inspeção anterior para poder verificar o campo alterado.

Validar o modelo final do Compose e o campo de memória

Apresente a configuração efetiva do Compose depois de aplicar todos os ficheiros, perfis e substituições de variáveis de ambiente. Verifique se o limite pertence ao serviço ativo.

A especificação do Compose define mem_limit como um limite de memória do serviço e exige consistência quando também são declarados limites de implementação equivalentes.

Um valor num ficheiro de substituição não utilizado, num perfil inativo, num serviço com o nome mal escrito ou numa interface de Stack diferente não altera o modelo implementado. Compare a configuração apresentada com a inspeção do Docker.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separar limite máximo, reserva e swap

Registe o limite máximo de memória, a reserva ou o limite flexível, o limite de swap, a utilização atual, a utilização máxima e os eventos OOM. Não trate todos os valores relacionados com memória como um único limite.

A documentação de controlo de recursos do systemd distingue MemoryHigh de MemoryMax e mostra que os cgroups principais podem impor limites adicionais a serviços e contentores.

Um contentor pode aparentar exceder uma reserva porque uma reserva não é o mesmo que um limite máximo. Também pode utilizar swap ou cache de páginas que um painel exclui ou apresenta separadamente.

Verificar se o heap do runtime utiliza o seu próprio limite

Para aplicações Java, registe a deteção da JVM compatível com contentores, o heap máximo, a memória direta, o metaspace, as pilhas das threads e os parâmetros transmitidos pela imagem ou pela configuração da aplicação.

A Oracle documenta que a JVM dimensiona o heap a partir das restrições de memória disponíveis e permite que MaxRAMPercentage defina a fração do heap.

A alteração do limite do contentor pode não produzir o heap esperado da aplicação quando um -Xmx explícito ou uma percentagem continuam definidos. Além disso, a memória do heap não corresponde à utilização total de memória do processo.

Verificar os limites do Node.js e de outras aplicações

Inspecione os parâmetros do runtime, as variáveis de ambiente, o número de workers, as caches e os objetivos internos de memória. Compare-os com o limite do sistema operativo.

O Node.js documenta max-old-space-size como um limite do heap V8, que pode permanecer inalterado mesmo depois de o contentor receber uma permissão de utilização de cgroup maior ou menor.

Um limite do contentor protege o anfitrião; não ajusta automaticamente todas as aplicações. Defina o runtime abaixo do limite do contentor, deixando margem para alocações nativas e para a cache do sistema de ficheiros.

Aplicar uma alteração e verificar sob carga controlada

Apresente o modelo final do Compose, recrie apenas o serviço afetado, confirme o novo ID do contentor e o cgroup ativo e, em seguida, execute uma carga de trabalho limitada enquanto observa a utilização e os eventos OOM.

O artigo do ZimaSpace Tech & AI Hub explica o que acontece quando um contentor atinge o limite ativo; este artigo centra-se em provar que um limite alterado foi realmente implementado.

O problema fica resolvido quando a configuração apresentada, a inspeção do contentor, os ficheiros do cgroup, o heap do runtime e o limite de falha observado correspondem todos à política pretendida após o reinício.

Perguntas frequentes

Reiniciar um contentor aplica um limite de memória do Compose alterado?

Não. Normalmente, um reinício utiliza a mesma configuração do contentor existente. Recrie o serviço ou utilize uma atualização ativa suportada.

Um contentor pode exceder temporariamente o seu limite máximo de memória?

A contabilização do kernel e a recuperação podem apresentar brevemente valores próximos ou ligeiramente acima de um limite, mas a utilização não recuperável sustentada no limite máximo conduz ao tratamento OOM do cgroup.

Por que motivo a aplicação continua a indicar o tamanho antigo do heap?

O runtime da aplicação pode ter um parâmetro de heap explícito ou calcular uma percentagem apenas no arranque. Recrie ou reinicie a aplicação depois de validar o limite do contentor.