Dziś chciałbym zainicjować na Forum sekcję poświęconą optymalizacji konfiguracji HA i niektórych jego najpopularniejszych dodatków, której jedynym celem jest przyspieszenie pracy automatyzacji, mimimalizacja lagów zarówno po stronie backendu (compute) jak i sekcji odpowiedzialnych za prezentację wyników i komunikację z użytkownikiem (UI).
Mam w tej materii swoje przemyślenia, wiele prób za sobą (w tym kilka nie do końca udanych), więc może to być ciekawa lektura dla tych z Was, którzy mają podobne problemy. Zachęcam także do prezentacji własnych pomysłów i ich skutków w tym obszarze…
Jeszcze do niedawna mój HA stał na zwykłym NUC (Intel Core 5i, 8GB, SDD 420GB), zainstalowany jako bare metal. Uznałem bowiem, że każda inna instalacja (na Proxmox, czy pod jakimkolwiek innym supervisorem) to czysta strata mocy maszynki i dodatkowo problemy z update’ami… Taką instalację można traktować wyłącznie jako środowisko testowe, gdzie wszelkie nasze programistyczne niepowodzenia, straty na wydajności sprzętu, czy wręcz utrata jakichś danych nie będą frustrowały i zniechęcały do dalszych infromatycznych peregrynacji…
Zatem bare metal na typowym, technologicznie leciwym sprzęcie był dla mnie opcją docelową.
W międzyczasie minęły już ponad 4 lata, HA szybko się rozwinął, przybyły potrzeby i możliwości, a z nimi cała masa nowych integracji i rozwiązań. Obciążający moją instację HA jest tu także fakt, że wszystkie swoje automatyzacje robię w Node-RED, który jest niestety dość pazerny na zasoby sprzętowe w porównaniu z natywnym edytorem automatyzacji HA. Stąd od pewnego czasu obserwowałem postępującą degradację instalacji, coraz większe lagi w backendzie i coraz bardzej widoczną niewyróbę bazy danych.
Postanowiłem coś z tym zrobić i… dziś chciałem podrzucić Wam kilka swoich wdrożonych i chyba udanych pomysłów.
1. W serwerze podwoiłem RAM do 16GB.
Dzięki temu mogłem zmigrować swoją bazę do MariaDB w wersji in_memory, co spowodowało dramatyczne przyspieszenie pracy serwera.
In‑Memory MariaDB to jedna z tych zmian, które nie wyglądają spektakularnie na papierze , ale w praktyce potrafią odmienić Home Assistanta tak samo, jak przejście z HDD na SSD albo z 4 GB na 16 GB RAM. To jest po prostu inna liga działania recorder’a . Przy takim wypasie RAMu kluczowy parametr tmpfs mogłem ustawić aż na 4g, więc cała moja baza danych natychmiast znalazła się w pamięci RAM. Co to dało?
- zapis i odczyt historii jest natychmiastowy,
iowaitspada praktycznie do zera,- dysk przestaje być wąskim gardłem,
- HA działa szybciej i płynniej,
- UI nie laguje przy otwieraniu historii,
- automatyzacje reagują szybciej,
- dysk żyje dłużej (mniej zapisów).
To jest jak turbo‑doładowanie dla Home Assistanta.
Dodatkowo, podniesienie RAM do 16GB spowodowało bak potrzeby korzystania z dramatycznego spowalniacza, jakim jest swap, i którego nie sposób wyłączyć.
Zauważyłem więc ogromny wzrost prędkości recordera. Recorder to najbardziej obciążająca część HA, bo:
- zapisuje każdy stan każdej encji,
- generuje statystyki,
- aktualizuje wykresy,
- obsługuje historię.
Na SSD to działa OK.
Na HDD — dramat.
W RAM — po prostu rakieta.
Efekt: historia otwiera się 5–10× szybciej.
In‑Memory MariaDB zapisuje wszystko w RAM, a dysku dotyka tylko przy backupie lub restarcie.
Efekt: dysk jest praktycznie bezczynny.
Gdy recorder nie blokuje dysku, to:
- UI się nie przycina,
- interfejs UI ładuje się szybciej,
- historia nie zamraża interfejsu,
- automatyzacje reagują natychmiast.
To wszystko prowadzi do znacznego wzrostu responsywność automatyzacji.
Automatyzacje - zależne od historii - (np. „jeśli czujnik nie zmienił stanu od 10 minut”) działają szybciej, bo:
- zapytania SQL są natychmiastowe,
- nie ma opóźnień w odczycie stanu,
- HA nie czeka na dysk (
iowait = 0).
Zatem wnioski są następujące:
In‑Memory MariaDB usuwa największe wąskie gardło Home Assistanta — zapis i odczyt historii — przenosząc go do RAM, dzięki czemu HA działa szybciej, płynniej i stabilniej, a dysk przestaje być obciążony. A brak swapowania pamięci to już w ogóle najsłodsza wisienka na torcie.
2. Posprzątałem Node-RED
W jaki sposób? Otóż ze wszystkich swoich flowów (pierwotnie flows.json zajmował 7MB) pousuwałem dokładnie wszystkie inne msg.* oprócz msg.payload’ów, pod które podstawiam jedynie entity_state i paru innych msg.* kluczowych dla wykonania określonej ścieżki automatyzacji. Dokładnie wszystkie typy zmiennych na wyjściach z nodów zamieniłem na string, co wymusiło jedynie drobne poprawki edytorskie na niektórych nodach odczytujących te wartości. Nie mam już ani jednego msg typu event, data, topic, itp. śmieci.
Po takim zabiegu nowy plik flows.json zajął… niecałe 4MB. Takie odchudzenie kodu o prawie 50% spowodowało, że automatyzacje Node-RED wykonują się w mgnieniu oka (przynajmniej takie mam wrażenie).
Okazało się, że odchudzenie kodu w Node‑RED ze zbędnych msg.* to jedna z tych optymalizacji, które wyglądają niepozornie, a w praktyce potrafią drastycznie zmniejszyć zużycie CPU, RAM i liczbę operacji wykonywanych przez każdy flow. To jest dokładnie ten typ „mikro‑poprawek”, które w środowisku z dużą liczbą integracji, Zigbee2MQTT, Whisperem, serwerem VSCode, automatyzacjami i intensywnym ruchem zdarzeń — robią ogromną różnicę. Trzeba bowiem pamiętać, że każdy msg to obiekt, który:
- jest kopiowany między node’ami,
- jest serializowany i deserializowany,
- jest przetwarzany przez każdy nod po drodze,
- może być logowany,
- może być zapisywany do HA.
Jeśli msg zawiera tylko to, co potrzebne, to Node‑RED wykonuje minimalną pracę.
To tyle na dziś z mojego podwórka…
Napiszcie proszę, jakie są Wasze doświadczenia i osiągnięcia w zakresie optymalizacji procesów lub samego środowiska HA. Bo przecież na pewno są także inne metody i pomysły godne uwagi wszystkich…