Jak przeprowadzić test zapasu zasobów Home Assistant przy użyciu powtarzalnego obciążenia

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Benchmark Home Assistant Resource Headroom Under a Repeatable Workload - Zima Store Online

Test wydajności Home Assistant jest przydatny tylko wtedy, gdy odtwarza to samo obciążenie i określa, co oznacza „wystarczająco szybkie”, zanim przeanalizujesz wykresy zasobów. W przeciwnym razie dane dotyczące procesora, pamięci, pamięci masowej i sieci pozostają jedynie obserwacjami, bez wniosków dotyczących przepustowości.

Różni się to od diagnozowania jednej powolnej instalacji. Test celowo tworzy powtarzalną bazę odniesienia, zwiększa jeden wymiar obciążenia i określa, ile marginesu zasobów pozostaje, zanim wybrana automatyzacja, zapytanie do historii lub reakcja panelu wyjdzie poza akceptowalny zakres opóźnienia.

Zdefiniuj jedno obciążenie i jeden próg akceptacji

Wybierz obciążenie reprezentujące rzeczywisty szczyt aktywności w gospodarstwie domowym: na przykład lokalną automatyzację opartą na ruchu, trzy aktywne panele, standardowe zapisy komponentu Recorder, jeden okres pracy w tle bez tworzenia kopii zapasowej oraz stały zestaw integracji. Zapisz wersję Home Assistant, sprzęt hosta, pamięć masową, bazę danych, klienta, ścieżkę sieciową i czas trwania testu.

Widok Informacje systemowe Home Assistant udostępnia kontekst dotyczący instalacji, sieci, integracji i zasobów, który należy zapisać wraz z wynikiem testu wydajności. Bez szczegółów środowiska czasu reakcji jednej osoby nie można wiarygodnie porównać z wynikami innej maszyny.

Następnie zdefiniuj próg akceptacji. Automatyzacja oświetlenia może wymagać fizycznej reakcji poniżej sekundy, podczas gdy zapytanie do historii z pięciu lat może być akceptowalne przy czasie kilku sekund. Nie łącz tych przypadków w jeden ogólny wynik „szybkości Home Assistant”.

Dla każdego współdzielonego zasobu używaj wykorzystania, nasycenia i błędów

Samo średnie wykorzystanie zasobów jest słabym kryterium zakończenia testu. Dysk może być zajęty, ale działać prawidłowo, a procesor może wykazywać umiarkowane średnie użycie, podczas gdy krótkie skoki tworzą kolejkę odczuwalną przez użytkowników jako opóźnienie.

Metoda USE ocenia wykorzystanie, nasycenie i błędy dla każdego fizycznego lub ograniczonego zasobu. Zastosuj tę metodę do procesora, pojemności pamięci, operacji wejścia-wyjścia pamięci masowej i interfejsów sieciowych, zamiast wybierać wykres o najwyższym poziomie wykorzystania.

W przypadku Home Assistant uruchomionego w kontenerze uwzględnij również limity cgroup jako zasoby. Host z 60% wolnego czasu procesora może nadal ograniczać kontener, który osiągnął przydzielony mu limit.

Metryki presji pokazują czas tracony z powodu niedoboru zasobów

Linux Pressure Stall Information zapewnia dodatkową perspektywę zorientowaną na opóźnienia. Zamiast pytać wyłącznie, ile procesora, pamięci lub operacji wejścia-wyjścia jest używane, PSI mierzy część czasu, przez którą zadania są wstrzymane z powodu rywalizacji o zasoby.

Dokumentacja jądra Linux wyjaśnia, że presję procesora, pamięci i operacji wejścia-wyjścia można mierzyć jako rzeczywisty czas tracony z powodu rywalizacji, w tym krótkich skoków pogarszających opóźnienia, zanim średnie wykorzystanie osiągnie skrajne wartości.

Dzięki temu PSI jest przydatne na współdzielonym serwerze domowym. Jeśli opóźnienia Home Assistant rosną wraz ze wzrostem presji operacji wejścia-wyjścia podczas serii zapisów wykonywanych przez inny kontener, masz mocniejsze dowody na współdzielenie zasobów pamięci masowej niż stwierdzenie „dysk SSD był zajęty w 70%”.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

W każdym przebiegu zwiększaj tylko jeden wymiar obciążenia

Nie dodawaj jednocześnie użytkowników panelu, wyzwalaczy automatyzacji, strumieni z kamer, retencji danych i ruchu związanego z kopiami zapasowymi. Zwiększaj jedną zmienną, pozostawiając wszystkie pozostałe warunki bez zmian.

Przydatne testy stopniowe obejmują zwiększanie liczby zdarzeń automatyzacji na minutę, liczby jednoczesnych paneli, zakresu historii, liczby aktualizacji encji lub obciążenia jednego zdefiniowanego sąsiedniego usługodawcy. Po każdym kroku odczekaj wystarczająco długo, aby system osiągnął stabilne zachowanie, zamiast zbierać dane z pierwszych dziesięciu sekund rozgrzewania pamięci podręcznej lub skoku uruchomieniowego.

Analiza ZimaSpace dotycząca rywalizacji o kolejki współdzielonej pamięci masowej i opóźnień ogona pokazuje, dlaczego obciążenie musi być powiązane ze ścieżką zasobu: pamięć masowa ma znaczenie tylko wtedy, gdy testowane działanie bezpośrednio od niej zależy lub współdzieli tę samą kolejkę operacji wejścia-wyjścia.

Zmień jeden zasób i wymagaj zmiany wyniku

Test staje się diagnostyczny, gdy kontrolowana zmiana zasobu przesuwa krzywą opóźnień. Przypisz obciążonego sąsiada do innego procesora niż Home Assistant, wstrzymaj zadanie intensywnie zapisujące dane, zwiększ testowany limit pamięci cgroup, użyj bezpośredniej trasy w sieci LAN lub przenieś dane aplikacji na pamięć masową o mniejszych opóźnieniach.

Jeśli pierwotny próg opóźnienia poprawi się przy tym samym kroku obciążenia, zasób prawdopodobnie ograniczał zapas wydajności. Jeśli nic się nie zmieni, cofnij eksperyment i przetestuj kolejnego kandydata, zamiast utrwalać zmianę w konfiguracji.

Przedstaw wynik jako zakres możliwości

Wymiar obciążenia	Pomiar za pomocą	Zakończ, gdy
Częstotliwość automatyzacji/zdarzeń	Opóźnienie ogonowe od wyzwolenia do działania	Opóźnienie lub kolejki stale rosną
Klienci paneli	Odpowiedź serwera + renderowanie po stronie klienta	Powtarzające się opóźnienie interakcji przekracza cel
Obciążenie komponentu Recorder/historii	Opóźnienie zapytań + presja pamięci masowej	Presja operacji wejścia-wyjścia lub ogon zapytań gwałtownie się pogarsza
Obciążenie współdzielonego hosta	PSI / cgroup / wykorzystanie	Opóźnienie Home Assistant zmienia się wraz z rywalizacją o zasoby
Ścieżka sieciowa	RTT, utrata pakietów, DNS, czas odpowiedzi	Zdalna ścieżka nie spełnia zdefiniowanego celu

Końcowy wynik powinien brzmieć mniej więcej tak: „Ten sprzęt, baza danych, zestaw klientów i obciążenie w tle utrzymują wybraną ścieżkę sterowania w docelowym zakresie do kroku N”. Takie stwierdzenie można odtworzyć. „Home Assistant wykorzystuje tylko 20% procesora” — nie.