Varför blir en Home Assistant-server varm eller låter mycket under inaktiva timmar?
En Home Assistant-server som blir varm eller bullrig under ”inaktiva” timmar utför vanligtvis bakgrundsarbete som inte syns i instrumentpanelen. Rensning eller ompackning av Recorder, databasfrågor, säkerhetskopieringar, uppdateringar, bullriga integrationer, kamerabearbetning, virtuella maskiner och andra containrar kan alla belasta CPU:n eller lagringen när ingen aktivt använder gränssnittet.
Diagnostisera inte fläkten. Diagnostisera arbetsbelastningen som höjer kapslingens effektförbrukning eller temperatur. Notera exakt när ljudet börjar, jämför det med CPU-, disk-, databas- och schemalagda jobb och ta sedan bort eller schemalägg om en arbetsbelastning i taget.
Använd tidsstämpeln för att hitta schemalagda jobb
En topp som uppstår nästan samma tid varje natt tyder starkt på en schemalagd underhålls- eller automationsprocess. Kontrollera Recorder, säkerhetskopieringar, uppdateringsjobb, databasunderhåll, statistikbearbetning samt eventuella cron-jobb på värdsystemet eller containeruppgifter som körs under samma tidsintervall.
Home Assistant-användare har spårat regelbundna CPU-toppar klockan 4 på morgonen till Recorder-rensning som sker vid samma tid varje dag. Exemplet är användbart eftersom temperatursymptomet följer ett schema även om hushållet betraktar systemet som inaktivt.
Flytta eller finjustera jobbet först efter att du har bekräftat sambandet. En orelaterad automation som också körs under natten kan skapa samma visuella mönster, så tidsöverensstämmelsen måste gå att upprepa.
Recorder kan förvandla bullriga entiteter till kontinuerlig bakgrundsbelastning
En integration som uppdateras för ofta kan hålla databasen sysselsatt långt efter att själva enheten verkar stabil. De extra skrivningarna ökar CPU-belastningen, lagringsaktiviteten och databasunderhållet.
En Home Assistant-installation kopplade en ihållande ökning av CPU-belastning och temperatur till Recorder efter att ha upptäckt flera Z-Wave-entiteter som genererade stora mängder databasrader. När onödiga högfrekventa data undantogs återgick CPU-beteendet mot det normala.
Använd Recorder-statistik eller databasinspektion för att hitta entiteterna som genererar flest tillståndsändringar. Inaktivera inte historik globalt om bara några få bullriga entiteter är orsaken.
Bakgrundsbelastningen kan komma från en annan container eller virtuell maskin
På en delad hemmaserver kan Home Assistant få skulden för värme som egentligen skapas av en databas, NVR, medieserver, lokal AI-process eller säkerhetskopieringsmotor. Mät CPU-belastningen på process- eller containernivå i stället för att tillskriva varje topp på värdsystemet till Home Assistant-containern.
Stora Recorder-arbetsbelastningar kan också skapa betydande I/O även när Home Assistant-gränssnittet ser inaktivt ut. Recorder rensar för närvarande varje natt klockan 04:12 som standard och kan automatiskt packa om databasen varannan söndag; ompackning är tyngre än vanlig registrering och kan förlänga bakgrundsbelastningen. Samma värmeproblem på värdsystemet kan därför komma från schemalagt databasarbete i stället för en enda automationsloop.
Pausa en närliggande tjänst under den period då systemet normalt blir varmt. Om värdsystemets temperatur och fläkthastighet sjunker medan Home Assistant förblir responsivt, är den delade arbetsbelastningen – inte enbart Home Assistant-konfigurationen – ett bättre mål för felsökningen.
Kylproblem är verkliga först när du har förstått arbetsbelastningen
En igensatt kylfläns, blockerad luftintagsöppning, felande fläkt, varm kapsling eller uttorkat värmeledande material kan höja temperaturen vid normal belastning. Men maskinvarans kylning bör undersökas först när du vet att servern inte helt enkelt utför mer arbete än tidigare.
Jämför temperaturen vid samma CPU-effekt eller CPU-användning över tid. Om samma arbetsbelastning nu körs märkbart varmare bör du undersöka luftflödet och maskinvaran. Om själva arbetsbelastningen har ökat bör du åtgärda programvaran eller schemat först.
ZimaSpaces guide för dimensionering av smarthem-servrar behandlar lagring, samlokaliserade tjänster och den fysiska plattformens begränsningar som en gemensam driftsram, i stället för att anta att en inaktiv Home Assistant-server saknar bakgrundsbelastning.
Använd en kontrollerad baslinje för inaktivitet
| Test | Vad det visar |
|---|---|
| Registrera CPU, temperatur och disk-I/O under 24 timmar | Om topparna är schemalagda |
| Pausa säkerhetskopiering eller underhåll under en cykel | Om ett bakgrundsjobb orsakar toppen |
| Inspektera Recorder-entiteter med hög uppdateringsfrekvens | Om tillståndsändringar driver databasarbetet |
| Pausa en kompletterande container | Om belastningen på den delade värden är orsaken |
| Upprepa samma arbetsbelastning efter rengöring av luftflödet | Om kylningen förändrades oberoende av programvaran |
En frisk period av inaktivitet bör återgå till en stabil termisk och akustisk baslinje när bakgrundsarbetet är klart. Om CPU-belastning, lagringsaktivitet eller temperatur aldrig stabiliseras bör du fånga den pågående processen och behandla den som en ihållande arbetsbelastning eller regression, inte som normalt schemalagt arbete.
Rekommenderade produkter
Support och tips
Mer att läsa
Bör du säkerhetskopiera Home Assistant medan det körs eller stoppa tjänsten först?
Inbyggda säkerhetskopieringar i Home Assistant kan köras live; vanliga filsystemkopior bör stoppa eller försätta Home Assistant i viloläge, såvida inte databasen säkerhetskopieras på ett...
När bör du bygga om i stället för att reparera Home Assistant?
Reparera först det minsta felande Home Assistant-lagret, återställ därefter ett känt fungerande tillstånd och bygg bara om när den beständiga konfigurationen inte längre går...
Hur mycket ledigt lagringsutrymme bör Home Assistant ha för bakgrundsjobb?
Dimensionera Home Assistants lediga utrymme utifrån Recorder-databasen, säkerhetskopieringarnas tillväxt, underhållstoppar och återställningsåtgärder – inte utifrån en universell procentsats.
