Hur mycket CPU-kapacitet bör du reservera för toppar i Home Assistant?
Reservera tillräcklig CPU-marginal för den värsta upprepningsbara arbetsbelastningen för att uppfylla målen för händelse-till-åtgärd och omstart; det finns ingen försvarbar universell procentsats för varje Home Assistant-stack.
En värd med fyra kärnor kan visa ett måttligt genomsnitt samtidigt som en kärna är överbelastad, eller verka CPU-begränsad när lagringsväntan, minnestryck eller termisk strypning egentligen är den verkliga begränsningen. Definiera den mest belastade realistiska överlappningen, mät styrfördröjning och beteende per kärna och behåll sedan den minsta resursmarginal som klarar upprepade tester utan att normala kompletterande tjänster behöver stoppas.
Definiera toppen och den användarsynliga gränsen
Bygg en arbetsbelastning som kombinerar den mest intensiva normala automationssatsen med användning av instrumentpanelen och planerade bakgrundsjobb som säkerhetskopiering, databasunderhåll, röstfunktioner eller utvald kamerabearbetning. Definiera acceptabel fördröjning från händelse till åtgärd, svarstid för instrumentpanelen och beredskap efter omstart innan du mäter resursutnyttjandet.
Använd inte ett artificiellt stresstest för alla kärnor som den enda toppen. Det mäter maskinvarans kapacitet, men inte den överlappning mellan schemaläggning, databas, integrationer och tillägg som användarna faktiskt upplever.
En giltig baslinje körs tre gånger med samma antal enheter, integrationer, databasläge och närliggande tjänster. Om arbetsbelastningen inte kan upprepas är ingen procentsats som härleds från den en tillförlitlig reserv.
Samla även in en körning under en lugn period som kontroll. Skillnaden mellan lugna och maximala tillstånd visar hur känslig arbetsbelastningen är; den maximala procentsatsen ensam kan inte visa om systemet startade nära mättnad.
Läs av mättnad per kärna och väntetid separat
Registrera resursutnyttjande per kärna, belastning, stjälptid för virtuella maskiner, I/O-väntan, frekvens, temperatur och Home Assistant-processen tillsammans med den användarsynliga fördröjningen. Synkronisera alla mätningar till samma tidsstämplar.
Eftersom en överbelastad kärna kan döljas bakom ett betydligt lägre genomsnitt för hela systemet bör du testa processens belastningsmönster i stället för att anta att det totala utnyttjandet visar den användbara marginalen.
Om en kärna når full belastning samtidigt som fördröjningen ökar tyder det på begränsad kapacitet för enkeltrådad CPU-bearbetning eller blockerande arbete. Om I/O-väntan ökar först bör du åtgärda lagring eller databasbeteende. Om frekvensen sjunker när temperaturen stiger bör du förbättra kylningen innan du reserverar mer nominell kapacitet.
Skapa marginal med schemaläggning och isolering
Flytta valfria jobb från det mest belastade styrfönstret, begränsa bullriga kompletterande containrar och förhindra att kamera-, AI- eller medieuppgifter förbrukar varje körbar kärna. Se till att Home Assistant och nödvändiga meddelandeförmedlare fortfarande kan göra framsteg under dessa toppar.
Jämför processorers arbetsbelastningsdrivna CPU-marginal först efter att den nuvarande systembegränsningen har mätts. Ett snabbare köp löser inte obegränsade jobb eller lagringsväntan.
Testa igen efter varje ändring av schemaläggning eller begränsningar. Om fördröjningen klarar målen utan maskinvaruändring är den återvunna marginalen operativ marginal; om samma kärna fortfarande är överbelastad bör du jämföra en kraftfullare CPU endast mot den identiska arbetsbelastningen.
Fastställ reserven utifrån upprepade godkända körningar
Använd den högsta observerade toppen från rena, upprepade körningar och behåll sedan ytterligare kapacitet för förväntad tillväxt av integrationer samt en överlappning med underhåll. Uttryck resultatet som ett testat tjänsteintervall, inte som ett universellt mål för låg belastning.
Proceduren i benchmarktestet av resursmarginal ger en gemensam baslinje för CPU, minne, lagring och nätverk.
Testet är godkänt när den ursprungliga toppen uppfyller målen för fördröjning och omstart i på varandra följande körningar utan termisk strypning eller tvingade tjänstestopp. Eskalera eller uppgradera när samma CPU-specifika mättnad kvarstår efter att orsaker inom schemaläggning, integrationer och I/O har uteslutits.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Immich-databasanslutningar för samtidiga containrar
Höj inte max_connections först. Mät Immich-sessionerna, summera alla containers behov, behåll utrymme för administratörsåtkomst och justera bara den flaskhals som har bevisats.
Så förhindrar du duplicerade jobb eller importer i Immich
Separera upprepade jobb från duplicerade resurser. Använd en enda kanonisk inläsningsväg, kontrollera omförsök och sökvägsändringar och testa sedan återinmatning på en liten grupp.
Så reparerar du Immich när dess databasvolym blir full
Ta aldrig bort PostgreSQL-WAL för att frigöra utrymme. Stoppa skrivningar till Immich, bevara databastillståndet, lägg till säker lagringskapacitet, återställ PostgreSQL och förhindra sedan att...
