O que limita realmente as tarefas simultâneas do Home Assistant antes de o controlo local se degradar?
O Home Assistant não tem uma resposta única e significativa para “quantas tarefas concorrentes consegue processar?”. Dez tarefas assíncronas curtas podem ser menos exigentes do que uma integração que bloqueia o ciclo de eventos, enquanto cinquenta automações em fila podem continuar a ser inofensivas se passarem a maior parte do tempo à espera de E/S independente.
O limite útil é o ponto em que o trabalho adicional cria um atraso repetível no caminho de controlo relevante: um evento demora mais tempo a ser processado, uma fila de automações cresce, uma chamada de serviço falha o seu objetivo temporal ou um recurso partilhado de CPU, memória, armazenamento ou rede começa a ficar sob pressão. A concorrência é, por isso, primeiro um problema de latência e filas, e só depois um problema de contagem de tarefas.
A concorrência do Home Assistant começa no ciclo de eventos Asyncio
O Home Assistant Core foi concebido com base no Python asyncio. Os componentes agendam trabalho como tarefas e o código assíncrono cooperativo cede o controlo enquanto espera por E/S, permitindo que outras tarefas avancem em vez de dedicar uma thread do sistema operativo a cada integração.
A documentação atual para programadores do Home Assistant explica que o Core agenda tarefas dos componentes através de um ciclo de eventos central e depende de as tarefas suspenderem corretamente enquanto aguardam. É por isso que “concorrente” não significa que todas as tarefas executam instruções de CPU exatamente ao mesmo tempo.
Uma análise prática da concorrência faz a mesma distinção: as tarefas assíncronas podem sobrepor-se no tempo decorrido, enquanto a execução efetiva no ciclo de eventos permanece serializada entre pontos await. A capacidade depende do tempo que cada tarefa ocupa o ciclo e daquilo por que espera.
O trabalho bloqueante pode degradar muitas tarefas em simultâneo
A falha de concorrência mais prejudicial muitas vezes não é haver “demasiadas automações”. É uma operação que bloqueia o ciclo de eventos durante tempo suficiente para impedir a execução de atualizações de estado e callbacks não relacionados.
O Home Assistant avisa explicitamente que as operações bloqueantes no ciclo de eventos suspendem todo o sistema durante a chamada. Isto inclui E/S de ficheiros mal tratada, bibliotecas de rede, pausas ou trabalho síncrono pesado dentro de uma integração.
Isso altera a forma como um teste de capacidade deve ser interpretado. Se a latência do controlo local aumentar com uma integração específica ativa, apesar de a utilização geral da CPU permanecer baixa, o problema pode continuar a ser um bloqueio do ciclo de eventos e não uma capacidade de processamento insuficiente.
O modo da automação determina como os acionamentos repetidos se transformam em trabalho
As automações acrescentam outra camada de política de concorrência. Uma regra pode rejeitar um segundo acionamento, reiniciar a execução atual, colocar o trabalho em fila ou criar execuções paralelas. Essas escolhas alteram tanto a correção como a exigência de recursos.
A documentação atual dos modos de automação do Home Assistant define os modos single, restart, queued e parallel, com um máximo configurável de execuções em fila ou paralelas. O máximo predefinido para os modos em fila e paralelo é 10, mas esse valor de configuração não constitui uma classificação da capacidade de toda a plataforma.
Uma automação de um sensor de porta que espera dois segundos antes de enviar uma notificação e uma automação de iluminação que faz cinco chamadas de rede não são tarefas equivalentes. Defina primeiro o modo da automação com base na ordem e na correção; depois, observe se a fila ou a sobreposição resultante afetam a latência do controlo.
Meça o crescimento das filas e a latência da cauda, não apenas a percentagem de CPU
Use uma automação local crítica como sonda de latência. Registe a chegada do acionamento, o início da automação, a chamada de serviço e a resposta do dispositivo físico, aumentando apenas uma variável de concorrência de cada vez: acionamentos repetidos, clientes do painel, integrações em segundo plano ou serviços adjacentes.
O artigo da ZimaSpace sobre trabalho orientado por eventos e carga de servidores inativos fornece a referência correta: os sistemas orientados por eventos são eficientes quando o trabalho só é ativado quando necessário, mas os picos continuam a precisar de margem suficiente de agendamento e recursos para serem processados sem filas persistentes.
Observe a latência mediana e as execuções normais mais lentas. Um sistema pode apresentar uma média de 10% de CPU enquanto pequenos picos criam paragens de um segundo. O limite de capacidade útil surge quando as filas continuam a crescer, os avisos de número máximo de execuções aparecem repetidamente ou a latência da cauda deixa de regressar à linha de base depois de o pico terminar.
Separe a concorrência do Home Assistant da contenção no anfitrião
O Home Assistant pode estar a agendar corretamente enquanto outro contentor satura a CPU, a memória, o armazenamento ou a rede. Nesse caso, aumentar ou reduzir o max da automação pode não alterar a falha, porque o anfitrião partilhado já perdeu margem de recursos.
Repita o teste de concorrência uma vez com a carga de trabalho adjacente suspensa. Se a temporização do ciclo de eventos e a latência do controlo local recuperarem imediatamente, trate o limite como um problema de capacidade do anfitrião partilhado. Se isso não acontecer, investigue operações bloqueantes, o comportamento da integração ou o desenho da fila de automações dentro do Home Assistant.
Use uma condição de paragem em vez de publicar um número de tarefas
| Sinal observado | O que significa | Próximo teste |
|---|---|---|
| As execuções paralelas/em fila atingem o máximo configurado | Limite da fila ao nível da automação | Verifique o modo, a ordem e a frequência dos acionamentos |
| Aviso do ciclo de eventos ou bloqueio generalizado da interface/controlo | Possível trabalho bloqueante | Identifique a integração ou a chamada síncrona |
| A latência aumenta apenas quando outro serviço está ativo | Contenção no anfitrião partilhado | Meça a pressão sobre CPU, memória, E/S e rede |
| Um caminho de dispositivo está lento enquanto os outros permanecem rápidos | Limite específico da dependência | Inspecione essa integração ou esse caminho de rede |
| As filas esvaziam-se e a latência da cauda permanece dentro do objetivo | Continua a existir margem de concorrência útil | Pare de acrescentar carga no pico planeado |
A capacidade do Home Assistant deve, por isso, ser apresentada como uma carga de trabalho testada com um objetivo de latência, e não como um número universal de tarefas concorrentes. A pergunta certa é quanta sobreposição de trabalho a combinação atual de integrações e o anfitrião conseguem absorver antes de o caminho crítico do controlo local deixar de cumprir o seu prazo.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Estado em tempo de execução vs. estado persistente no Home Assistant: o que tem de sobreviver ao reinício?
O Home Assistant não persiste todos os valores em tempo real; a configuração, os registos, os estados restaurados selecionados, o histórico e os dados...
Como é que o Home Assistant autentica sessões locais e remotas?
As sessões locais e remotas do Home Assistant utilizam o mesmo modelo de identidade do lado do servidor; o acesso remoto altera a rota...
Porque é que as consultas ao histórico do Home Assistant podem ficar mais lentas à medida que os dados do Recorder aumentam?
O crescimento do gravador pode aumentar o custo das consultas do Histórico quando o intervalo solicitado abrange mais linhas, as falhas de cache aumentam...
