Żywotność msg w procesie, a zużycie pamięci podręcznej serwera

Witam.

W jednym z nakręconych tutorialii @artur wspomina, że w ramach procesu i wywołanego w nim zdarzenia które generuje msg, ono “ginie” po przejściu całej ścieżki procesu.
Podczas testów z Node-RED doszedłem do odmiennego wniosku lecz nie mam pewności czy prawidłowego, dlatego proszę skorygujcie jeśli macie wiedzę w tym temacie.

Wyjaśnię na przykładzie procesu rejestratora systemu centralnego ogrzewania:


Proces uruchamiany jest okresowo co 15 sekund i co 3 minuty.
Proces 15s ma obsługiwać docelowo obsługę kotła i całej związywanej z nim infrastruktury, a proces uruchamiany co 3 minuty rejestrować parametry pracy systemu.
SUB Proces “LM Dane” pobiera dane z Lan Kontroler’a w postaci pliku XML i przetwarza go na format JSON używany w nodach i przekazywany dalej w wiadomości (msg).
Ostatecznie jest tworzona i przetwarzana dość pokaźna struktura danych dla każdego z generowanych msg. Rejestracja pojedynczych parametrów odbywa się poprzez eksport do Home Asystanta i zapisywana w historii jego wewnętrznymi mechanizmami w sztucznie utworzonych do tego celu “Pomocnikach”.

Po 6 godzinach pracy skryptu zauważyłem iż zwiększyło się znacznie zużycie pamięci z 52% do 62% w RP 3B+, co mnie zaniepokoiło.
Z szczątkowych informacji które pamiętam z programowania w Java Scripcie pamiętam że jeśli nie usuniemy jakiejś zmiennej, to jest ona stale przechowywana w pamięci, a kolejna zajmuje kolejną przestrzeń i tym tokiem rozumowania doszedłem do wniosku że tak jest i w tym przypadku. Jeśli nie usuniemy zmiennej msg. przed zakończeniem procesu to będzie wisieć w pamięci do restartu HA. No i potwierdzenie moich przemyśleń dokonałem resetu HA. Po restarcie okazało się że faktycznie tak jest, bo zużycie pamięci spadło do poziomu z przed uruchomienia skryptu, czyli 52%.

Dodałem na zakończeniu każdej ścieżki proces usuwający dane z każdego msg. i od 16 godzinach pracy procesu, poziom zapisu danych w pamięci utrzymuje się na 52%-56%, a po restarcie HA zchodzi do 50%
image
pisząc ten post zauważyłem że nie zamknąłem jeszcze jednej ścieżki, może ona powoduje ten mniejszy, ale istotny wzrost zużycia pamięci - sprawdzimy rano.

Proces obecnie wygląda tak:


zostawiam go na noc w spokoju, rano podeśle kolejne screenshoty dla porównania.

Właśnie okazało się że moja teoria upadła.

image
Zastanawiam się czy nie lepiej usunąć wątek z forum by go nie zaśmiecać.

@Marcin_Domański nie ma potrzeby usuwać, może ktoś będzie miał podobne rozmyślania i znajdzie w tym wątku rozwiązanie.

Oj nie usuwaj, dobrze kombinujesz, możliwe że nastąpił restart automatyczny, wczoraj około 23ciej zauważyłem że jest aktualizacja supervisor, ale odłożyłem do rana, bo uruchomiłem snapshot, a dziś widzę że już nie ma tej aktualizacji, więc musiała sama się wykonać - czyli był restart. Co do ramu, to mam pi3 i walczę o każdy procent, bo mam ponad 400 nodów i znów przekroczyłem 60% ram, a co za tym idzie zaczynają się problemy, więc watek ciekawy…

Panowie. Jedna tylko kwestia do uściślenia. Mówiąc, że obiekt wiadomości ginie miałem na myśli, że nie ma do niego dostępu z poziomu procesu. Nie ma się to nijak do tego czy on zwalnia czy nie zwalnia pamięć. Możliwe, że sam obiekt przez jakiś czas jeszcze w pamięci się znajduje ze względów o których nie wiemy. Kolejna rzecz to przy tak dużej częstotliwości wywoływania procesu jak u Ciebie faktycznie może być sytuacja, że te dłużej żyjące obiekty ‘nakładają się na siebie’ dlatego wzrasta zużycie pamięci.
Pamiętajmy też że mówimy o systemie Linux gdzie zarządzanie pamięcią jest trochę inne niż na Windows.
Pamięć jest po to aby ją zajmować. Ważne aby była zwalniana gdy inne procesy jej potrzebują. Więc to że masz przyrost nie zawsze to coś złego bo może na ten moment nic innego jej nie potrzebuje i gdy będzie potrzebować to pamięć zostanie zwolniona.
Dlatego zwracam uwagę aby nie wpaść w ślepą gonitwę o zwalnianie pamięci bo nikomu nic dobrego nie przyjdzie z pustej nieużywanej pamięci.

O… Ktoś wyciąga dane z Lan Kontrolera do NR. Możesz zamieścić plik procesu?

[
{
    "id": "83fcee7a.a38ef",
    "type": "xml",
    "z": "b95268eb.3592a8",
    "name": "XML",
    "property": "payload",
    "attr": "",
    "chr": "",
    "x": 330,
    "y": 80,
    "wires": [
        []
    ]
},
{
    "id": "8b04c479.f23238",
    "type": "http request",
    "z": "b95268eb.3592a8",
    "name": "DANE LM2.5",
    "method": "GET",
    "ret": "txt",
    "paytoqs": "ignore",
    "url": "192.168.10.2/st0.xml",
    "tls": "",
    "persist": true,
    "proxy": "",
    "authType": "",
    "x": 190,
    "y": 80,
    "wires": [
        [
            "83fcee7a.a38ef"
        ]
    ]
}
]

image
Dane pobieram poprzez pobranie pliku xml z lokalizacji http://192.168.x.x/st0.xml i zamianę pliku xml na format JSON, dostęp do LM jest po http bez hasła wewnątrz z bunkrowanej wewnętrznej sieci LAN

Ja używam LM z dedykowanym softem, szczegóły w tym manualu.

@Marcin_Domański dziękuję. Od jakiegoś czasu mialem się zabrać za integrację LM. Może Twoje doświadczenia mnie zmobilizują.

Edit: Też używam LN z dedykowanym softem. Obsługuje dodatkowo zużycie własne energii w domu (falownik PV Fronius tego nie raportuje), zużycie gazu i kilka temperatur.

@Sierek Kontynuuje odpowiedz na Twoje pytanie, bo jest dość istotna sprawa.

W mojej integracji dodałem obsługę błędów związanych z LM. Proces się wykrzaczy jeśli taki napotka. Moje rozwiązanie to (proste i bez rozmieniania na drobne):
image
2020-07-25 - LM25.json (1,6 KB)

Zazwyczaj 30s potrzebuje LM na wstanie po resecie (który sam z siebie wykonuje od czasu do czasu) - ja odczytuje z niego dane (za pomocą tego podprocesu) w interwałach co 15s. Jeśli nie zrobię mu 30s. przerwy w trakcie resetu, to sam nie wstanie - nie wiem dla czego.

Nie będę tutaj kontynuował tematu LM, bo się robi off-topic, jak dopracuje proces do końca to podzielę się nim ze szczegółowym opisem w dedykowanym wątku.