Reserve capacidade suficiente de CPU para a carga de trabalho repetível mais exigente, de modo a cumprir os objetivos de tempo entre evento e ação e de reinício; não existe uma percentagem universal defensável para todas as configurações do Home Assistant.
Um anfitrião de quatro núcleos pode apresentar uma média moderada enquanto um núcleo está saturado, ou parecer limitado pela CPU quando o verdadeiro limite é a espera pelo armazenamento, a pressão sobre a memória ou a redução térmica da frequência. Defina a sobreposição realista mais exigente, meça a latência de controlo e o comportamento de cada núcleo e, em seguida, mantenha a menor margem de recursos que passe repetidamente sem interromper os serviços complementares normais.
Defina o Pico e o Limite Perceptível pelo Utilizador
Crie uma carga de trabalho que combine o pico normal mais exigente das automações com a utilização do painel e tarefas de fundo planeadas, como cópias de segurança, manutenção da base de dados, voz ou processamento selecionado de câmaras. Defina a latência aceitável entre evento e ação, a resposta do painel e a prontidão após o reinício antes de medir a utilização.
Não utilize um teste artificial de stress de todos os núcleos como único pico. Este mede a capacidade do hardware, mas não a sobreposição de agendamento, base de dados, integrações e complementos que os utilizadores realmente experienciam.
Uma linha de base válida executa três vezes a mesma quantidade de dispositivos, integrações, estado da base de dados e serviços adjacentes. Se a carga de trabalho não puder ser repetida, nenhuma percentagem dela derivada constitui uma reserva fiável.
Registe uma execução num período calmo como controlo. A diferença entre os estados calmo e de pico revela a sensibilidade à carga de trabalho; a percentagem de pico, por si só, não mostra se o sistema começou perto da saturação.
Leia Separadamente a Saturação de Cada Núcleo e a Espera
Registe a utilização de cada núcleo, a carga, o tempo de roubo das máquinas virtuais, a espera de E/S, a frequência, a temperatura e o processo do Home Assistant, juntamente com a latência percecionada pelo utilizador. Alinhe todas as medições com os mesmos carimbos temporais.
Como um núcleo saturado pode ficar oculto numa média de todo o sistema muito mais baixa, teste o perfil do processo em vez de presumir que a utilização total representa a margem disponível.
Se um núcleo atingir o limite enquanto a latência aumenta, está implicada a capacidade de processamento num só thread ou a existência de trabalho bloqueante. Se a espera de E/S aumentar primeiro, corrija o comportamento do armazenamento ou da base de dados. Se a frequência diminuir com a temperatura, corrija o arrefecimento antes de reservar mais capacidade nominal.
Crie Margem de Manobra Com Agendamento e Isolamento
Afaste as tarefas opcionais da janela de controlo mais exigente, limite os contentores complementares que geram mais atividade e impeça que tarefas de câmaras, IA ou multimédia consumam todos os núcleos executáveis. Mantenha o Home Assistant e os agentes essenciais capazes de progredir durante esses picos.
Compare a margem de processamento orientada pela carga de trabalho apenas depois de medir o fator limitante do sistema atual. Comprar um processador mais rápido não corrige tarefas sem limites nem a espera pelo armazenamento.
Volte a testar após cada alteração de agendamento ou de limites. Se a latência passar sem alteração do hardware, a margem recuperada é margem operacional; se o mesmo núcleo continuar saturado, compare uma CPU mais potente apenas com a mesma carga de trabalho.
Defina a Reserva a Partir de Execuções Repetidas com Sucesso
Utilize o pico máximo observado em execuções limpas e repetidas e, em seguida, mantenha capacidade adicional para o crescimento esperado das integrações e para uma sobreposição de manutenção. Expresse o resultado como um envelope de serviço testado, não como um objetivo universal de inatividade.
O procedimento descrito no teste de referência da margem de recursos fornece a linha de base entre métricas para CPU, memória, armazenamento e rede.
Considere aprovado quando o pico original cumpre os objetivos de latência e reinício em execuções consecutivas, sem redução térmica da frequência nem paragens forçadas de serviços. Escale ou atualize quando a mesma saturação específica da CPU persistir depois de excluídas as causas relacionadas com o agendamento, as integrações e a E/S.
Suporte e Dicas
Mais para Ler

Como otimizar as ligações à base de dados do Immich para contentores simultâneos
Não aumente primeiro o valor de max_connections. Meça as sessões do Immich, some a procura total de cada contentor, preserve margem para o administrador...

Como evitar trabalhos ou importações duplicados no Immich
Separe os trabalhos repetidos dos recursos duplicados. Utilize um único caminho de ingestão canónico, controle as novas tentativas e as alterações de caminho e,...

Como reparar o Immich depois de o volume da base de dados ficar cheio
Nunca elimine o WAL do PostgreSQL para libertar espaço. Pare as escritas do Immich, preserve o estado da base de dados, adicione capacidade de...

