Hoe je de beschikbare systeemruimte van Home Assistant onder een herhaalbare werklast benchmarkt

Een prestatiebenchmark voor Home Assistant is alleen nuttig wanneer deze dezelfde werklast reproduceert en vooraf vastlegt wat “snel genoeg” betekent, voordat je naar resourcegrafieken kijkt. Anders worden CPU-, geheugen-, opslag- en netwerkcijfers slechts observaties zonder conclusie over de capaciteit.

Dit verschilt van het oplossen van problemen met één trage installatie. Een benchmark creëert doelbewust een herhaalbare basislijn, verhoogt één dimensie van de werklast en bepaalt hoeveel reservecapaciteit overblijft voordat een gekozen automatisering, geschiedenisquery of dashboardreactie buiten het aanvaardbare latentie bereik valt.

Definieer één werklast en één acceptatiedrempel

Kies een werklast die een daadwerkelijke piek in het huishouden vertegenwoordigt: bijvoorbeeld een lokale bewegingsautomatisering, drie actieve dashboards, normale Recorder-schrijfbewerkingen, één periode zonder back-ups op de achtergrond en een vaste set integraties. Noteer de versie van Home Assistant, hosthardware, opslag, database, client, netwerkpad en testduur.

De weergave Systeeminformatie van Home Assistant toont installatie-, netwerk-, integratie- en resourcecontext die naast een prestatieresultaat moet worden vastgelegd. Zonder omgevingsdetails kan de responstijd van de ene persoon niet zinvol worden vergeleken met die van een andere machine.

Definieer vervolgens de acceptatiedrempel. Een verlichtingsautomatisering kan een fysieke respons binnen één seconde vereisen, terwijl een geschiedenisquery van vijf jaar met meerdere seconden nog acceptabel kan zijn. Combineer deze niet tot één algemene score voor de “snelheid van Home Assistant”.

Gebruik benutting, verzadiging en fouten voor elke gedeelde resource

Alleen gemiddelde benutting is een slechte stopconditie. Een schijf kan druk bezig maar gezond zijn, terwijl een CPU een bescheiden gemiddeld gebruik toont en korte pieken toch een wachtrij veroorzaken die gebruikers als latentie ervaren.

De USE-methode beoordeelt benutting, verzadiging en fouten voor elke fysieke of beperkte resource. Pas dit kader toe op CPU, geheugencapaciteit, opslag-I/O en netwerkinterfaces, in plaats van simpelweg de grafiek met de hoogste benutting te kiezen.

Neem voor Home Assistant in containers ook cgroup-limieten op als resources. Een host met 60% vrije CPU kan een container nog steeds afremmen zodra die zijn toegewezen quotum heeft bereikt.

Drukmetingen tonen tijdverlies door schaarse resources

Linux Pressure Stall Information biedt een latentiegerichte blik. In plaats van alleen te vragen hoeveel CPU, geheugen of I/O wordt gebruikt, meet PSI welk deel van de tijd taken geblokkeerd zijn omdat er concurrentie om een resource is.

De documentatie van de Linux-kernel legt uit dat CPU-, geheugen- en I/O-druk kunnen worden gemeten als realtimeverlies door concurrentie, waaronder korte pieken die de latentie verslechteren voordat de gemiddelde benutting extreem lijkt.

Daarom is PSI nuttig op een gedeelde thuisserver. Als de latentie van Home Assistant verslechtert wanneer de I/O-druk toeneemt tijdens een schrijfpiek van een andere container, heb je sterker bewijs van concurrentie om gedeelde opslag dan met de constatering “de SSD was voor 70% actief”.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verhoog per run slechts één dimensie van de werklast

Voeg niet tegelijkertijd dashboardgebruikers, automatiseringstriggers, camerastreams, bewaartermijnen en back-upverkeer toe. Verhoog één variabele terwijl alle andere omstandigheden gelijk blijven.

Nuttige stapsgewijze tests zijn onder meer meer automatiseringsevenementen per minuut, meer gelijktijdige dashboards, grotere geschiedenisbereiken, meer entity-updates of één gedefinieerde werklast van een aangrenzende service. Wacht na elke stap lang genoeg totdat het systeem stabiel gedrag vertoont, in plaats van alleen de eerste tien seconden van een warme cache of opstartpiek te verzamelen.

De ZimaSpace-analyse van concurrentie om wachtrijen op gedeelde opslag en staartlatentie laat zien waarom de werklast aan het resourcepad moet worden gekoppeld: opslag is alleen relevant wanneer de geteste actie er rechtstreeks van afhankelijk is of dezelfde I/O-wachtrij deelt.

Wijzig één resource en eis dat het resultaat verandert

Een benchmark wordt diagnostisch wanneer een gecontroleerde wijziging aan een resource de latentiecurve verandert. Wijs een zware buur weg van de CPU van Home Assistant, pauzeer een schrijfzware taak, verhoog de geteste cgroup-geheugenlimiet, gebruik een directe LAN-route of verplaats appgegevens naar opslag met een lagere latentie.

Als de oorspronkelijke latentiegrens bij dezelfde workloadstap verbetert, beperkte de resource de reservecapaciteit waarschijnlijk. Als er niets verandert, draai de test terug en onderzoek de volgende kandidaat, in plaats van de wijziging tot permanente configuratie te maken.

Publiceer het resultaat als capaciteitsbereik

Het uiteindelijke resultaat moet bijvoorbeeld luiden: “Deze hardware, database, clientmix en achtergrondwerklast houden het gekozen besturingspad tot en met stap N binnen de doelwaarde.” Die uitspraak is reproduceerbaar. “Home Assistant gebruikt slechts 20% CPU” is dat niet.