Que limite de memória deve definir para o Home Assistant?

Não existe um limite de memória único e correto para o Home Assistant. Defina o limite com base no pico medido, deixe RAM utilizável para o anfitrião e para os outros contentores, e considere qualquer encerramento por falta de memória (OOM) como um indício de que o limite ou a carga de trabalho precisam de ser investigados.

Num servidor doméstico partilhado, uma leitura em inatividade não é suficiente: o trabalho do Recorder, as cópias de segurança, o recarregamento de integrações, os painéis e uma sequência de automação intensa para toda a casa podem produzir picos diferentes. A abordagem segura consiste em registar uma linha de base, escolher um limite reversível acima do pico de carga de trabalho verificado, confirmar que o anfitrião ainda dispõe de margem e repetir o período de maior atividade original antes de tornar a definição permanente.

Comece pela utilização máxima, não por um número genérico de RAM

Meça o contentor do Home Assistant e o anfitrião em simultâneo durante vários dias normais. Inclua um reinício, uma cópia de segurança, uma limpeza ou compactação da base de dados, se utilizar alguma, atividade nos painéis e o período de automação mais intenso que consiga reproduzir em segurança. Registe o pico do contentor, a memória disponível no anfitrião, a atividade de swap e eventuais alterações no tempo de resposta.

Um limite de memória é uma fronteira do cgroup, não um objetivo de desempenho. Quando um contentor ultrapassa uma fronteira rígida, o kernel pode terminar um processo; um código de saída 137 juntamente com um estado OOM-killed é o sinal relevante. É por isso que a utilização máxima observada é mais importante do que uma média ou uma recomendação copiada.

Se a memória aumentar durante uma tarefa e depois estabilizar, dimensione para esse pico repetível, acrescentando margem de funcionamento. Se a memória anónima aumentar durante horas sem diminuir depois de a carga de trabalho terminar, pare de ajustar o dimensionamento e investigue uma integração, um componente personalizado ou uma regressão de versão com fuga de memória. Um limite superior pode apenas atrasar a falha sem a corrigir.

Reserve memória para o anfitrião e para todos os serviços alojados em conjunto

Faça uma lista dos serviços que têm de continuar responsivos quando o Home Assistant estiver mais ocupado: o sistema operativo, o Docker, uma base de dados, o MQTT, o DNS, os painéis, os serviços multimédia e as tarefas de cópia de segurança. O limite deve proteger esses serviços, bem como o Home Assistant; atribuir a um contentor quase toda a RAM instalada apenas transfere a falha para o anfitrião.

Compare o pico do Home Assistant com a memória disponível no anfitrião durante o mesmo período. A cache que pode ser libertada não é equivalente à memória utilizada pelas aplicações, e a atividade de swap pode fazer com que o sistema pareça estar operacional enquanto o controlo dos dispositivos fica lento. Se o anfitrião perder margem antes de o Home Assistant atingir o pico, reduza as tarefas sobrepostas ou transfira um serviço antes de reduzir o limite do Home Assistant.

Esta é uma decisão de capacidade, não apenas uma definição do Docker. O guia relacionado da ZimaSpace sobre medir o Home Assistant para além da cache aquecida explica por que motivo uma carga de trabalho a frio e intensa, mas repetível, fornece uma linha de base mais fiável do que uma conveniente fotografia do sistema em inatividade.

Aplique um limite reversível e confirme que é aplicado

Adicione a definição de memória na configuração que recria efetivamente o contentor, como o seu ficheiro Compose ou a interface de orquestração. Evite depender de uma atualização temporária enquanto o contentor está em execução, se a implementação seguinte a for eliminar. Guarde a configuração anterior para a poder restaurar imediatamente.

Depois de recriar o contentor, inspecione-o enquanto está em execução e confirme que o limite configurado é visível. Em seguida, acompanhe a utilização do contentor, a memória disponível no anfitrião, a swap, o número de reinícios e a latência. Uma definição apresentada que não seja aplicada pelo cgroup do anfitrião cria uma falsa sensação de segurança, especialmente em ambientes de virtualização aninhada.

Se o contentor reiniciar, não aumente automaticamente o limite. Verifique se o ambiente de execução indica OOMKilled e o código de saída 137. Caso contrário, investigue outro motivo para o encerramento. Se indicar OOMKilled, compare o momento do evento com a carga de trabalho: um pico curto e repetível sugere margem de funcionamento insuficiente, enquanto um crescimento constante sugere uma fuga de memória ou uma integração descontrolada.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Repita o teste com a carga de trabalho doméstica intensa original do Home Assistant

Repita exatamente o cenário utilizado para a linha de base: recarregue as mesmas integrações, abra os mesmos painéis, execute a mesma sequência de controlo de toda a casa e inclua a mesma atividade de cópia de segurança ou do Recorder. Alterar a carga de trabalho apenas provaria que um sistema mais leve é suficiente.

Um resultado aprovado significa que o contentor permanece abaixo do limite sem eventos OOM, que o anfitrião mantém memória utilizável, que a swap não provoca atrasos no controlo e que as automações terminam à velocidade normal. Reinicie duas vezes e volte a verificar após a próxima tarefa de fundo agendada, para garantir que o resultado se mantém depois da recriação e das tarefas dependentes do tempo.

Reverta o novo limite se o controlo dos dispositivos se tornar pouco fiável, se o contentor entrar num ciclo de reinícios ou se a pressão sobre o anfitrião continuar grave. Passe ao isolamento de integrações ou à comparação de versões quando a memória continuar a aumentar depois de terminada a carga de trabalho que a desencadeou; nessa altura, ajustar o limite já não é a correção principal.

Perguntas frequentes

O Home Assistant deve ter sempre um limite rígido de memória? Num anfitrião Docker partilhado, um limite testado pode proteger os outros serviços. Uma máquina HAOS ou uma máquina virtual dedicada é dimensionada de forma diferente, por isso não copie um limite de contentor para a alocação de uma máquina virtual sem medir todo o sistema convidado.

Uma utilização elevada de memória significa automaticamente uma fuga? Não. A cache e os picos curtos de carga de trabalho podem ser normais. Procure memória anónima que continue a aumentar, eventos OOM, ciclos de reinício ou latência crescente depois de terminada a carga de trabalho.

Deve desativar a swap? Não como primeira medida. Primeiro descubra se a swap está a ocultar a pressão sobre o anfitrião ou a evitar uma falha abrupta; depois altere-a apenas com um plano de reversão testado e RAM física suficiente para toda a carga de trabalho.