Vad får Home Assistants uppstartstid att öka med bibliotekets storlek?

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 Causes Home Assistant Startup Time to Increase With Library Size?

Home Assistant startar långsammare när dess bibliotek växer, eftersom fler databassidor, index, register, integrationer eller genererade tillstånd måste öppnas och valideras.

En större Recorder-fil innebär inte att varje byte läses in i minnet vid uppstart, och en extra mediefil behöver inte medföra någon uppstartskostnad alls. Fördröjningen uppstår när tillväxten utökar en uppstartskritisk sökväg: databasåterställning, schemakontroller, konfiguration av statistik, tolkning av register, upptäckt av integrationer eller inläsning av resurser för instrumentpanelen. Den användbara frågan är därför vilken växande samling som används innan systemet är klart.

Uppstart är en sekvens av grindar, inte en enda timer

Processstart, konfigurationsvalidering, öppning av databasen, kärninställning, initiering av integrationer, upptäckt av plattformar och frontendens tillgänglighet sker vid olika tidpunkter. En långsam grind kan hålla kvar statusen redo medan andra komponenter redan har slutförts.

En praktiker använde sensorer för integrationernas uppstart för att identifiera långsamma komponenter, vilket visar att tidsmätning av integrationernas uppstart bör delas upp per integration i stället för att behandlas som en enda ogenomskinlig varaktighet.

Mät både den totala uppstarten och när namngivna faser slutförs. Om bara webbläsaren förblir tom medan automatiseringar och tjänsteanrop redan fungerar har biblioteket inte nödvändigtvis gjort Core-uppstarten långsammare; klientresurser eller data för instrumentpanelen kan vara den återstående grinden.

Databastillväxt ökar kostnaden för öppning, återställning och migrering

Recorder kan kontrollera sitt schema, återställa en journal, skapa index, initiera statistik och hantera tidiga frågor. Större tabeller och en lång journal efter en felaktig avstängning kan göra dessa åtgärder dyrare, särskilt på lagring där svarstiden är viktig.

En undersökning av långsam uppstart rapporterar långvarig konfiguration av integrationer och databasrelaterade symtom, vilket visar hur databasrelaterad uppstartsfördröjning kan vara sammanflätad med uppstarten i stället för att synas som ett separat historikproblem.

Databasens storlek är fortfarande en ofullständig förutsägelsefaktor, eftersom indexerad åtkomst inte behöver genomsöka varje rad. En kompakt men skadad databas kan starta sämre än en stor och frisk, medan en stor databas på snabb lagring kan öppnas snabbt.

Integrationsinventeringen medför självständigt konfigurationsarbete

Varje konfigurerad integration kan läsa in kod, autentiseringsuppgifter, enheter, entiteter, översättningar och data från samordnare. Lokala integrationer kan slutföras snabbt, medan moln-API:er, otillgängliga enheter, DNS-fel eller hastighetsbegränsningar kan vänta på tidsgränser och nya försök.

Ett Core-ärende dokumenterar uppstartsfördröjning kopplad till långsamma integrationer, vilket stöder skillnaden mellan fördröjning i integrationskonfigurationen och den råa storleken på Recorder.

Att lägga till inaktiva medier eller gammal historik påverkar kanske inte denna sökväg, men att lägga till integrationer och entiteter kan göra det. Om inaktivering av en otillgänglig integration minskar uppstartstiden kraftigt medan databasens storlek är oförändrad är beroendet av integrationsinventeringen den starkare förklaringen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Stora bibliotek blottlägger gränser för lagring och korruption

Tillväxt ökar tiden som krävs för säkerhetskopieringar, integritetskontroller, migreringar och underhåll, vilket ger större utrymme för fulla volymer eller avbrutna skrivningar. Nästan full eller opålitlig lagring kan förvandla normal skalning till upprepat återställningsarbete.

Operatörer som kör mycket stora databaser beskriver behovet av att utvärdera backend- och underhållsbeteende, vilket gör att drift med stora databaser framstår som en arbetsbelastning med praktiska begränsningar snarare än ett harmlöst filstorlekstal.

Förklaringen med biblioteksstorlek håller inte när uppstartstiden förblir hög efter test med en ren kopia av databasen och samma konfiguration. Då bör integrationer, nätverkstidsgränser, anpassade komponenter eller belastning på värdsystemet prioriteras.

Genomför ett storlekskontrollerat uppstartsexperiment

Skapa en verifierad säkerhetskopia och registrera sedan databasstorlek, antal entiteter, antal integrationer, ledigt utrymme, lagringens svarstid och tidsstämplar för faser över tre normala omstarter. Testa en kopierad instans där en misstänkt samling har minskats, aldrig produktionskällan.

Testet av kapacitet i kallt respektive varmt tillstånd förklarar hur man skiljer cachevärme från verklig kapacitet, så att upprepade starter inte av misstag förvandlar en skillnad mellan kallt och varmt tillstånd till en slutsats om biblioteksstorlek.

Hänför fördröjningen till en samling först när en upprepad minskning av just den samlingen förkortar samma uppstartsfas. Om databasen spelar roll kan du justera kvarhållning eller backend; om en integration spelar roll kan du isolera dess konfiguration; om ingen av dem påverkar timern bör du undersöka väntan på lagring och nätverk innan du köper ny hårdvara.