Welke geheugenlimiet moet je instellen voor Home Assistant?

Er is geen enkele juiste geheugenlimiet voor Home Assistant. Stel de grens vast op basis van je eigen gemeten piek, laat bruikbaar RAM over voor de host en andere containers, en beschouw elke OOM-kill als bewijs dat de limiet of de werklast nader moet worden onderzocht.

Op een gedeelde homeserver is een meting in rust niet voldoende: Recorder-taken, back-ups, het opnieuw laden van integraties, dashboards en een drukke automatiseringsreeks voor het hele huis kunnen verschillende pieken veroorzaken. De veilige aanpak is om een baseline vast te leggen, een omkeerbare limiet boven de geverifieerde piekbelasting te kiezen, te controleren of de host nog voldoende ruimte heeft en de oorspronkelijke drukke periode opnieuw te testen voordat je de instelling permanent maakt.

Begin met piekgebruik, niet met een algemeen RAM-getal

Meet de Home Assistant-container en de host tegelijkertijd gedurende enkele normale dagen. Neem een herstart, een back-up, het opschonen of opnieuw verpakken van de database als je dat gebruikt, dashboardactiviteit en de drukste automatiseringsperiode die je veilig kunt reproduceren mee. Noteer de piek van de container, het beschikbare geheugen van de host, swapactiviteit en eventuele veranderingen in de responstijd.

Een geheugenlimiet is een cgroup-grens, geen prestatiedoel. Wanneer een container een harde grens overschrijdt, kan de kernel een proces beëindigen; een exitcode van 137 samen met een status OOM-killed is de kenmerkende indicatie. Daarom is waargenomen piekgebruik belangrijker dan een gemiddelde of een overgenomen aanbeveling.

Als het geheugen tijdens een taak stijgt en daarna weer stabiliseert, stel de limiet dan af op die herhaalbare piek plus werkruimte. Als anoniem geheugen urenlang blijft toenemen zonder na afloop van de werklast terug te lopen, stop dan met het verhogen van de limiet en onderzoek een lekkende integratie, aangepaste component of regressie in een versie. Een hoger plafond kan de crash uitstellen zonder het probleem te verhelpen.

Reserveer geheugen voor de host en elke gedeelde service

Maak een lijst van de services die responsief moeten blijven wanneer Home Assistant het drukst is: het besturingssysteem, Docker, een database, MQTT, DNS, dashboards, mediaservices en back-uptaken. De limiet moet die services én Home Assistant beschermen; één container bijna al het geïnstalleerde RAM geven verplaatst het probleem alleen naar de host.

Vergelijk de piek van Home Assistant met het beschikbare geheugen van de host tijdens hetzelfde tijdvenster. Cache die kan worden vrijgegeven is niet gelijk aan applicatiegeheugen, en swapactiviteit kan een systeem in leven laten lijken terwijl apparaatbediening traag wordt. Als de host al geheugenruimte verliest voordat Home Assistant zijn piek bereikt, verminder dan overlappende taken of verplaats een service voordat je de limiet van Home Assistant verder verlaagt.

Dit is een capaciteitsbeslissing, niet alleen een Docker-instelling. De gerelateerde ZimaSpace-gids over het meten van Home Assistant voorbij een warme cache legt uit waarom een herhaalbare koude en drukke werklast een betrouwbaardere baseline oplevert dan een handige momentopname in rust.

Pas een omkeerbare limiet toe en controleer of die wordt afgedwongen

Voeg de geheugeninstelling toe aan de configuratie waarmee de container daadwerkelijk opnieuw wordt aangemaakt, zoals je Compose-bestand of orkestratie-interface. Vertrouw niet op een eenmalige live-aanpassing als de volgende deployment die weer verwijdert. Bewaar de vorige configuratie zodat je die onmiddellijk kunt herstellen.

Controleer na het opnieuw aanmaken de actieve container en bevestig dat de geconfigureerde limiet zichtbaar is. Houd vervolgens het containergebruik, het beschikbare geheugen van de host, swap, het aantal herstarts en de latentie in de gaten. Een weergegeven instelling die niet door de cgroup van de host wordt afgedwongen, geeft een vals gevoel van zekerheid, vooral bij geneste virtualisatie.

Als de container opnieuw start, verhoog de limiet dan niet automatisch. Controleer of de runtime OOMKilled en exitcode 137 meldt. Zo niet, onderzoek dan een andere oorzaak van het afsluiten. Zo ja, vergelijk het tijdstip met de werklast: een korte, herhaalbare piek wijst op onvoldoende werkruimte, terwijl gestage groei wijst op een lek of een ontspoorde integratie.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Test opnieuw onder de oorspronkelijke drukke Home Assistant-werklast

Herhaal exact het scenario dat voor de baseline is gebruikt: laad dezelfde integraties opnieuw, open dezelfde dashboards, voer dezelfde bedieningsreeks voor het hele huis uit en neem dezelfde back-up- of Recorder-activiteit mee. Een gewijzigde werklast zou alleen aantonen dat een lichter systeem past.

Een geslaagd resultaat betekent dat de container onder de grens blijft zonder OOM-gebeurtenissen, dat de host bruikbaar geheugen overhoudt, dat swap geen vertraging in de bediening veroorzaakt en dat automatiseringen op normale snelheid worden voltooid. Start tweemaal opnieuw en controleer nogmaals na de volgende geplande achtergrondtaak, zodat het resultaat ook na opnieuw aanmaken en tijdgebonden werkzaamheden behouden blijft.

Maak de nieuwe limiet ongedaan als apparaatbediening onbetrouwbaar wordt, de container in een herstartlus terechtkomt of de druk op de host ernstig blijft. Ga over op het isoleren van integraties of het vergelijken van versies wanneer het geheugen blijft stijgen nadat de veroorzakende werklast is beëindigd; op dat moment is het afstellen van de limiet niet langer de belangrijkste oplossing.

Veelgestelde vragen

Moet Home Assistant altijd een harde geheugenlimiet hebben? Op een gedeelde Docker-host kan een geteste grens andere services beschermen. Een speciale HAOS-machine of VM wordt anders gedimensioneerd, dus kopieer een containerlimiet niet zomaar naar een VM-toewijzing zonder de volledige gastomgeving te meten.

Is veel gebruikt geheugen automatisch een lek? Nee. Cache en korte werkbelastingpieken kunnen normaal zijn. Let op anoniem geheugen dat blijft groeien, OOM-gebeurtenissen, herstartlussen of toenemende latentie nadat de werklast is beëindigd.

Moet je swap uitschakelen? Niet als eerste stap. Bepaal eerst of swap druk op de host verbergt of een plotselinge uitval voorkomt. Pas swap daarna alleen aan met een geteste terugdraaiprocedure en voldoende fysiek RAM voor de volledige werklast.