Riserva sufficiente capacità CPU per il carico di lavoro ripetibile peggiore, così da rispettare gli obiettivi di latenza tra evento e azione e di riavvio; non esiste una percentuale universale difendibile per ogni stack Home Assistant.
Un host a quattro core può mostrare una media modesta mentre un core è saturo, oppure sembrare limitato dalla CPU quando il vero limite è l’attesa dello storage, la pressione sulla memoria o la limitazione termica. Definisci la sovrapposizione realistica più intensa, misura la latenza di controllo e il comportamento di ciascun core, quindi mantieni il margine minimo di risorse che supera ripetutamente il test senza interrompere i normali servizi complementari.
Definisci il picco e il limite percepito dall'utente
Crea un carico di lavoro che combini il picco abituale più intenso delle automazioni con l'uso della dashboard e i lavori in background pianificati, come backup, manutenzione del database, voce o l'elaborazione selezionata delle telecamere. Definisci la latenza accettabile tra evento e azione, la reattività della dashboard e la prontezza dopo il riavvio prima di misurare l'utilizzo.
Non usare uno stress test artificiale su tutti i core come unico picco. Misura la capacità dell'hardware, ma non la sovrapposizione tra pianificazione, database, integrazioni e componenti aggiuntivi che gli utenti sperimentano realmente.
Una baseline valida esegue tre volte lo stesso test con lo stesso numero di dispositivi, le stesse integrazioni, lo stesso stato del database e gli stessi servizi adiacenti. Se il carico di lavoro non può essere ripetuto, nessuna percentuale derivata da esso costituisce una riserva affidabile.
Acquisisci anche un'esecuzione durante un periodo di quiete come controllo. La differenza tra lo stato tranquillo e quello di picco rivela la sensibilità al carico; la sola percentuale di picco non mostra se il sistema fosse già vicino alla saturazione.
Leggi separatamente la saturazione dei singoli core e l'attesa
Registra l'utilizzo di ciascun core, il carico, il tempo di steal delle macchine virtuali, l'attesa I/O, la frequenza, la temperatura e il processo Home Assistant insieme alla latenza percepita dall'utente. Allinea tutte le misurazioni agli stessi timestamp.
Poiché un core saturo può nascondersi dietro una media dell'intero sistema molto più bassa, analizza il comportamento del processo invece di presumere che l'utilizzo totale rappresenti la capacità realmente disponibile.
Se un core raggiunge il 100% mentre la latenza aumenta, è probabile che siano coinvolti la capacità single-thread della CPU o attività bloccanti. Se l'attesa I/O aumenta per prima, intervieni sullo storage o sul comportamento del database. Se la frequenza diminuisce con l'aumento della temperatura, correggi il raffreddamento prima di riservare ulteriore capacità nominale.
Crea margine con pianificazione e isolamento
Sposta i lavori facoltativi fuori dalla finestra di controllo più intensa, limita i container complementari rumorosi e impedisci alle attività relative a telecamere, IA o contenuti multimediali di consumare ogni core disponibile. Assicurati che Home Assistant e i broker essenziali possano continuare a operare durante questi picchi.
Confronta il margine del processore determinato dal carico di lavoro solo dopo aver misurato il fattore limitante del sistema attuale. Un acquisto più potente non risolve i lavori senza limiti o l'attesa dello storage.
Ripeti il test dopo ogni modifica alla pianificazione o ai limiti. Se la latenza rientra nei valori previsti senza cambiare hardware, il margine recuperato è capacità operativa; se lo stesso core rimane saturo, confronta una CPU più potente solo con lo stesso identico carico di lavoro.
Imposta la riserva sulla base di test ripetuti superati
Usa il picco massimo osservato in esecuzioni pulite e ripetute, quindi conserva ulteriore capacità per la crescita prevista delle integrazioni e una sovrapposizione con un'attività di manutenzione. Esprimi il risultato come un intervallo operativo testato, non come un obiettivo universale di inattività.
La procedura descritta nel benchmark del margine di risorse fornisce la baseline incrociata per CPU, memoria, storage e rete.
Il test è superato quando il picco originale soddisfa gli obiettivi di latenza e riavvio in esecuzioni consecutive, senza limitazione termica né arresti forzati dei servizi. Valuta un aumento delle risorse o un aggiornamento quando la stessa saturazione specifica della CPU persiste dopo aver escluso le cause legate a pianificazione, integrazioni e I/O.
Supporto e consigli
Altro da leggere

Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...

Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...

Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...

