Vilken minnesgräns bör du ange för Home Assistant?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

What Memory Limit Should You Set for Home Assistant? - Zima Store Online

Det finns ingen enda korrekt minnesgräns för Home Assistant. Sätt gränsen utifrån din egen uppmätta toppanvändning, lämna användbart RAM åt värden och andra containrar, och betrakta varje OOM-avslutning som ett tecken på att gränsen eller arbetsbelastningen behöver undersökas.

På en delad hemserver räcker det inte med en avläsning i inaktivt läge: Recorder-arbete, säkerhetskopieringar, omladdningar av integrationer, instrumentpaneler och en intensiv automatiseringssekvens för hela hemmet kan ge olika toppar. Den säkra vägen är att registrera en baslinje, välja en återställningsbar gräns över den verifierade arbetstoppen, bekräfta att värden fortfarande har marginal och testa den ursprungliga intensiva perioden igen innan inställningen görs permanent.

Börja med toppanvändningen, inte ett generiskt RAM-värde

Mät Home Assistant-containern och värden samtidigt under flera vanliga dagar. Ta med en omstart, en säkerhetskopiering, en databasrensning eller ompackning om du använder en sådan, aktivitet i instrumentpaneler och den intensivaste automatiseringsperiod du säkert kan återskapa. Registrera containerns toppanvändning, värdens tillgängliga minne, swapaktivitet och om svarstiden förändras.

En minnesgräns är en cgroup-gräns, inte ett prestandamål. När en container överskrider en hård gräns kan kärnan avsluta en process; en avslutningskod på 137 tillsammans med tillståndet OOM-killed är den användbara indikationen. Därför är observerad toppanvändning viktigare än ett genomsnitt eller en kopierad rekommendation.

Om minnet ökar under en uppgift och sedan stabiliseras, dimensionera för den återkommande toppen plus arbetsmarginal. Om anonymt minne ökar i timmar utan att minska efter att arbetsbelastningen upphört, sluta justera storleken och undersök en läckande integration, anpassad komponent eller versionsregression. Ett högre tak kan fördröja kraschen utan att åtgärda den.

Reservera minne för värden och alla samlokaliserade tjänster

Lista de tjänster som måste fortsätta vara responsiva när Home Assistant är som mest belastat: operativsystemet, Docker, en databas, MQTT, DNS, instrumentpaneler, medietjänster och säkerhetskopieringsjobb. Gränsen måste skydda dessa tjänster såväl som Home Assistant; om du ger en container nästan allt installerat RAM flyttas felet helt enkelt till värden.

Jämför Home Assistants toppanvändning med värdens tillgängliga minne under samma tidsfönster. Cache som kan frigöras motsvarar inte programminne, och swapaktivitet kan få systemet att verka fungera medan enhetsstyrningen blir långsam. Om värden förlorar marginal innan Home Assistant når sin topp, minska överlappande jobb eller flytta en tjänst innan du sänker Home Assistants minnestak.

Detta är ett kapacitetsbeslut, inte bara en Docker-inställning. Den relaterade ZimaSpace-guiden om att mäta Home Assistant bortom varm cache förklarar varför en upprepningsbar kall och intensiv arbetsbelastning ger en mer tillförlitlig baslinje än en bekväm avläsning i inaktivt läge.

Tillämpa en återställningsbar gräns och kontrollera att den verkställs

Lägg till minnesinställningen i den konfiguration som faktiskt återskapar containern, till exempel din Compose-fil eller ditt orkestreringsgränssnitt. Förlita dig inte på en tillfällig ändring i drift om nästa distribution kommer att ta bort den. Spara den tidigare konfigurationen så att du omedelbart kan återställa den.

Efter återskapandet ska du inspektera den körande containern och bekräfta att den konfigurerade gränsen visas. Övervaka sedan containerns användning, värdens tillgängliga minne, swap, antal omstarter och svarstid. En visad inställning som inte verkställs av värdens cgroup ger falsk trygghet, särskilt vid nästlad virtualisering.

Om containern startar om ska du inte automatiskt höja gränsen. Kontrollera om körmiljön rapporterar OOMKilled och avslutningskod 137. Om inte, undersök en annan avstängningsväg. Om ja, jämför tidsstämpeln med arbetsbelastningen: en återkommande kort topp tyder på otillräckligt arbetsutrymme, medan en stadig ökning tyder på en läcka eller en skenande integration.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Testa igen under den ursprungliga intensiva Home Assistant-arbetsbelastningen

Upprepa exakt det scenario som användes för baslinjen: ladda om samma integrationer, öppna samma instrumentpaneler, kör samma styrsekvens för hela hemmet och ta med samma säkerhetskopiering eller Recorder-aktivitet. Om du ändrar arbetsbelastningen bevisar det bara att ett lättare system får plats.

Ett godkänt resultat innebär att containern håller sig under gränsen utan OOM-händelser, att värden behåller användbart minne, att swap inte orsakar fördröjningar i styrningen och att automatiseringarna slutförs med normal hastighet. Starta om två gånger och kontrollera igen efter nästa schemalagda bakgrundsjobb så att resultatet kvarstår efter återskapande och tidsbaserat arbete.

Återställ den nya gränsen om enhetsstyrningen blir opålitlig, containern hamnar i en omstartsloop eller trycket på värden förblir allvarligt. Gå vidare till att isolera integrationer eller jämföra versioner när minnet fortsätter att öka efter att den utlösande arbetsbelastningen upphört; då är gränsjustering inte längre den primära åtgärden.

Vanliga frågor

Bör Home Assistant alltid ha en hård minnesgräns? På en delad Docker-värd kan en testad gräns skydda andra tjänster. En dedikerad HAOS-maskin eller virtuell maskin dimensioneras på ett annat sätt, så kopiera inte en containergräns till en virtuell maskins minnestilldelning utan att mäta hela gästen.

Är hög minnesanvändning automatiskt en läcka? Nej. Cache och kortvariga arbetstoppar kan vara normala. Leta efter anonymt minne som fortsätter att öka, OOM-händelser, omstartsloopar eller försämrad svarstid efter att arbetsbelastningen upphört.

Bör swap inaktiveras? Inte som första åtgärd. Ta först reda på om swap döljer tryck på värden eller förhindrar ett plötsligt fel, och ändra den sedan endast med en testad återställningsväg och tillräckligt med fysiskt RAM för hela arbetsbelastningen.