Så här mäter du Home Assistants resursmarginal under en repeterbar arbetsbelastning

Ett prestandatest för Home Assistant är bara användbart när det återskapar samma arbetsbelastning och definierar vad ”tillräckligt snabbt” innebär innan man granskar resursgrafer. Annars blir siffrorna för CPU, minne, lagring och nätverk bara observationer utan någon slutsats om kapaciteten.

Detta skiljer sig från felsökning av en enskild långsam installation. Ett prestandatest skapar medvetet en repeterbar baslinje, ökar en arbetsbelastningsdimension i taget och identifierar hur stor resursmarginal som återstår innan en vald automatisering, historikfråga eller instrumentpanelssvar lämnar sitt acceptabla latensintervall.

Definiera en arbetsbelastning och en acceptansgräns

Välj en arbetsbelastning som representerar en faktisk belastningstopp i hemmet: till exempel en lokal rörelseautomatisering, tre aktiva instrumentpaneler, normala Recorder-skrivningar, en fast period utan säkerhetskopiering i bakgrunden och en fast uppsättning integrationer. Anteckna Home Assistant-version, värddatorns maskinvara, lagring, databas, klient, nätverkssökväg och testets varaktighet.

Home Assistants systeminformationsvy visar installations-, nätverks-, integrations- och resursinformation som bör dokumenteras tillsammans med ett prestandatestresultat. Utan information om miljön kan en persons svarstid inte jämföras på ett meningsfullt sätt med en annan maskin.

Definiera sedan acceptansgränsen. En belysningsautomatisering kan behöva en fysisk svarstid på under en sekund, medan en historikfråga över fem år kan vara acceptabel på flera sekunder. Kombinera inte dessa till ett generellt poängtal för ”Home Assistant-hastighet”.

Använd utnyttjandegrad, mättnad och fel för varje delad resurs

Genomsnittlig utnyttjandegrad är ensam en dålig stoppunkt. En disk kan vara upptagen men fungera normalt, eller så kan en CPU visa måttlig genomsnittlig användning samtidigt som korta toppar skapar en kö som användarna upplever som latens.

USE-metoden utvärderar utnyttjandegrad, mättnad och fel för varje fysisk eller begränsad resurs. Tillämpa detta på CPU, minneskapacitet, lagrings-I/O och nätverksgränssnitt i stället för att välja den högsta utnyttjandegraden i en graf.

För containeriserad Home Assistant ska även cgroup-gränser räknas som resurser. En värddator med 60 % ledig CPU kan ändå strypa en container som har nått sin tilldelade kvot.

Tryckmätvärden visar tid som går förlorad på grund av resursbrist

Linux Pressure Stall Information ger ett latensorienterat perspektiv. I stället för att bara fråga hur mycket CPU, minne eller I/O som används mäter PSI hur stor andel av tiden uppgifter står stilla eftersom en resurs är konkurrensutsatt.

Linux-kärnans dokumentation förklarar att CPU-, minnes- och I/O-tryck kan mätas som faktisk tid som går förlorad på grund av konkurrens, inklusive korta toppar som försämrar latensen innan den genomsnittliga utnyttjandegraden ser extrem ut.

Det gör PSI användbart på en delad hemmaserver. Om Home Assistant-latensen försämras när I/O-trycket ökar under en annan containers skrivburst har du starkare belägg för konkurrens om delad lagring än att ”SSD:n var belastad till 70 %”.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Öka bara en arbetsbelastningsdimension per körning

Lägg inte samtidigt till användare av instrumentpaneler, automatiseringstriggers, kameraflöden, lagringsperioder och säkerhetskopieringstrafik. Öka en variabel medan alla andra förhållanden hålls konstanta.

Användbara stegtester omfattar fler automatiseringshändelser per minut, fler samtidiga instrumentpaneler, större historikintervall, fler entitetsuppdateringar eller en definierad belastning från en närliggande tjänst. Vänta efter varje steg tillräckligt länge för att systemet ska nå ett stabilt beteende i stället för att samla in de första tio sekunderna från en varm cache eller en starttopp.

ZimaSpaces analys av konkurrens om köer i delad lagring och svanslatens visar varför arbetsbelastningen måste kopplas till resursvägen: lagring är bara relevant när den testade åtgärden är direkt beroende av den eller delar samma I/O-kö.

Ändra en resurs och kräv att resultatet förändras

Ett prestandatest blir diagnostiskt när en kontrollerad resursförändring flyttar latenskurvan. Isolera en tung granne från Home Assistants CPU, pausa ett skrivintensivt jobb, höj den testade cgroup-minnesgränsen, använd en direkt LAN-väg eller flytta appdata till lagring med lägre latens.

Om den ursprungliga latensgränsen förbättras vid samma arbetsbelastningssteg var resursen sannolikt begränsande för marginalen. Om inget förändras återställer du experimentet och testar nästa kandidat i stället för att göra ändringen permanent.

Publicera resultatet som ett kapacitetsintervall

Det slutliga resultatet bör formuleras ungefär så här: ”Den här maskinvaran, databasen, klientblandningen och bakgrundsbelastningen håller den valda styrvägen inom målet genom steg N.” Det påståendet går att upprepa. ”Home Assistant använder bara 20 % CPU” gör det inte.