Hohe CPU Auslastung

[saeft2003]

Hallo,

Wenn ich zwei Instanzen (die ich beide brauche) vom vedirect adapter laufen lassen, steigt die CPU Auslastung von 10% auf ca. 17% an. Mein System ist soweit aktuell.

Ich vermute, dass das daran liegt das sehr viele states im Sekundentakt geschrieben werden. Mir würden alle 30 Sekunden auch langen, es gibt im Adapter nur eine Einstellung die sich „expiretime“ nennt.

Könnt ihr mir sagen ob die expiretime mir weiter helfen könnte, oder nicht. Falls nicht gibt es noch eine andere Möglichkeit?

[heckmic]

Gleiches Problem bei mir. Ich habe sogar zwei Instanzen laufen und die Last die damit im Sekundentakt erzeugt wird ist wirklich hoch. Eine einstellbare Zeit in Sekunden für den Abruf wäre super. 1 Minute ist ausreichend.

[DutchmanNL]

im gründe ist es so das wir kein polling machen und die daten 1:1 von der serial Verbindung reinkommen.
Wir könnten einen buffer implementieren das er es nicht bei jeder Nachricht schreibt sondern nur alle x Sekunden wen das gewuesncht ist

[heckmic]

Wäre klasse!

[saeft2003]

im gründe ist es so das wir kein polling machen und die daten 1:1 von der serial Verbindung reinkommen.
Wir könnten einen buffer implementieren das er es nicht bei jeder Nachricht schreibt sondern nur alle x Sekunden wen das gewuesncht ist

Das fände ich auch wirklich super 👍 Hab im Moment sogar einen extra iobroker laufen der die Daten nur bei Änderung an den Haupt iobroker schickt. Weil bei 4 Instanzen wäre die Last zu hoch.

Kurz gesagt die Änderung würde mir sehr helfen und Strom/Hardware sparen 😊

[DutchmanNL]

@heckmic @saeft2003

na dan mal bitte die 0.3.1 von git probieren :)

Ich habe in der admin config eine option hinzugefuegt "Puffer in Sekunden, um Nachrichten zu ignorieren", wen ihr den auf 0 lässt kommen immer alle Nachrichten rein vom serial.

Stellt man hier z.b. 10 ein, werden nur alle 10 Sekunden daten geschrieben. Default = 0 (also kein buffer)

[saeft2003]

Alles klar teste ich nachher 👍

[heckmic]

@heckmic @saeft2003

na dan mal bitte die 0.3.1 von git probieren :)

Ich habe in der admin config eine option hinzugefuegt "Puffer in Sekunden, um Nachrichten zu ignorieren", wen ihr den auf 0 lässt kommen immer alle Nachrichten rein vom serial.

Stellt man hier z.b. 10 ein, werden nur alle 10 Sekunden daten geschrieben. Default = 0 (also kein buffer)

Irgendwas passt da nicht... Ich würde die Option nennen: "Zustände alle X Sekunden aufzeichen" oder ähnlich...

[DutchmanNL]

ups ... mein Fehler, bitte mit 0.3.2 von git nochmal probieren :)

[saeft2003]

Ich hab jetzt auch die 0.3.2 getestet und es funktioniert bei mir nicht.

1. Mit 30 Sekunden ändern sich bei mir keine Werte mehr auch die die sich sekündlich ändern. Stelle ich auf 0 geht es wieder wie gewohnt.
2. Die CPU Auslastung hat sich nicht verringert. Kann das sein weil die Werte gepuffert werden?

@heckmic wie verhält sich das bei dir?

[heckmic]

Die Versionsnummer ändert sich nach Installation aus git aber nicht...

[DutchmanNL]

Die Versionsnummer ändert sich nach Installation aus git aber nicht...

Ups 🫣 stimmt der Text jetzt im Admin und was passiert wen du dort zb 5sekunden einstellst ?

[heckmic]

Bei mir keine Veränderung. Die Werte kommen im Sekundentakt. - Ich installiere via Katze von Github.

[saeft2003]

Ich installiere auch per katze. Ich bekomme die 0.3.1 angezeigt es ist aber die 0.3.2 drauf. Ablauf der Zustände ist bei mir leer. Wenn ich bei Puffer in Sekunden 30 eingebe kommen gar keine Werte mehr. Nur wenn ich dort 0 eingebe kommen die Werte wie vorher wieder im Sekundentakt.

Aber selbst wenn gar keine Werte kommen sinkt bei mir die CPU Last nicht. Was für mich eigentlich das ausschlaggebende ist.

[saeft2003]

Die Versionsnummer ändert sich nach Installation aus git aber nicht...

Ups 🫣 stimmt der Text jetzt im Admin und was passiert wen du dort zb 5sekunden einstellst ?

Wenn ich 1 Sekunde eingebe kommen noch Werte, bei 2 Sekunden kommen noch gelegentlich Werte und was größer gleich 3 ist passiert gar nichts mehr bei mir. Getestet bei einem DP der sich jede Sekunde ändert. Bei dem wird die Zeit seit der letzten vollen Ladung hochgezählt.

[DutchmanNL]

Aber selbst wenn gar keine Werte kommen sinkt bei mir die CPU Last nicht. Was für mich eigentlich das ausschlaggebende ist.

hmm, sehr seltsam den im Grunde machen ich keinen buffer im ram sondern schmeisse die nachrichten einfach weck/verarbeite sie nicht wodurch ich die annähme hatte das dies die CPU last drücken sollte

Code technisch sehe ich weiter nichts was man sonst machen könnte, das verhalten das er bei > 3 Sekunden gar keine daten mehr schreibt finde ich auch sehr seltsam kan das aber leider nicht weiter debuggen ohne Zugang zu einer installation (ich habe selber kein Redirect um es local zu debuggen :()

[saeft2003]

@DutchmanNL

soll ich mal auf 30 Sekunden stellen mit debug log und dann den Adapter starten? Würde dann heute am späten Abend das log posten…

[DutchmanNL]

@DutchmanNL

soll ich mal auf 30 Sekunden stellen mit debug log und dann den Adapter starten? Würde dann heute am späten Abend das log posten…

gerne, ich werde dan noch eine neue version vorbereiten mit ein bissl mehr debug logging

[DutchmanNL]

@saeft2003 ich habe eine version 0.3.3 hochgeladen mit extra debug Informationen.
es würde helfen den adapter mal :

• buffer einstellen auf 0, 30 Sekunden laufen lossen und debug log teilen
• buffer einstellet auf 2, 30 Sekunden laufen lossen und debug log teilen
• buffer einstellet auf 15, 30 Sekunden laufen lossen und debug log teilen

Ich glaube das problem bereits zu sehen, Redirect schickt immer nachrichten fuer einen Datenpunk da ich jetzt alles andere in der Zwischenzeit ignorieren fehlen wohl werte.

Das wiederum bedeutet das ich es zwischen speichern muss, auch kein problem aber ob dadurch die CPU last runtergeht ist fragwuerdig

[heckmic]

Bei mir wird auch mit der neusten Version jede Sekunde aktualisiert. Die Zeitstempel aller Werte aktualisieren sich jede Sekunde, was eben zu einer relativ hohel Last am redis führt.

[saeft2003]

@DutchmanNL

log15sek.txt
log2sek.txt
log0sek.txt

hier die entsprechenden logs. Und ich will nochmal darauf hinweisen das ich keine neue Daten mehr bekomme mit z.B. 30 Sekunden. Der DP H9 wird jede Sekunde geändert d.h. es müsste alle 30 Sekunden eine Änderung kommen, aber selbst nach mehreren Minuten passiert nichts und das bei allen DPs.

[DutchmanNL]

@DutchmanNL

log15sek.txt

log2sek.txt

log0sek.txt

hier die entsprechenden logs. Und ich will nochmal darauf hinweisen das ich keine neue Daten mehr bekomme mit z.B. 30 Sekunden. Der DP H9 wird jede Sekunde geändert d.h. es müsste alle 30 Sekunden eine Änderung kommen, aber selbst nach mehreren Minuten passiert nichts und das bei allen DPs.

Danke fürs log, meine Vermutung hat sich bestätigt ich muss den Puffer anders aufbauen

Wie sieht es jetzt mit der CPU Last aus wen zb auf 15 eingestellt?

Ist diese Dan niedriger oder bleibt hoch? Wen letzteres ist der Puffer auch nicht die Lösung

[saeft2003]

@DutchmanNL

das ist der Unterschied den ich mit 30 Sekunden feststellen konnte. Es wäre nett wenn du es anpassen könntest ich würde es gerne testen.

[saeft2003]

@DutchmanNL

Bist du an dem Thema noch dran?

[PiXasCoding]

Das Problem was hier vorliegt ist folgendes.
Das Victron Gerät schickt über die VE.Direct Schnittstelle jede Sekunde Daten, welche dann auch an den Adapter hier weitergeleitet werden. Deshalb wir auch im Sekundentakt aktualisiert.
Die von DutchmanNL eingebaute Routine, welche diese Daten nur nach X-Sekunden verarbeiten soll, funktioniert deshalb nicht wie gewünscht, weil der dafür gesetzte Warteschleifen-Timer eben nach diesen X-Sekunden gleich wieder neu gesetzt wird. Dies führt allerdings dazu, dass gerade mal ein eingehender Datensatz verarbeitet werden kann, weil es danach gleich wieder in die Warteschleife geht.
Denn, die Daten kommen nicht in einem kompletten Paket, sondern werden einzeln geschickt.

Ich habe bei mir das Script "main.js" insoweit angepasst, dass in jedem Fall zuerst mindestens 37 mal Datensätze eingelesen werden, bis es wieder in die Warteschleife geht. Das ist auch die Anzahl die der Adapter maximal auswertet. Dies funktioniert nun erstmal soweit. Kommen weniger Datensätze, wird doppelt eingelesen, hier gibt es also noch Optimierungspotenzial.

Was zusätzlich Rechenzeit kostet ist, dass der Adapter trotz eingestellter Bufferzeit weiterhin jede Sekunde unnötige Aufgaben erledigt. Z.B. den Datenpunkt "connection" auf "true" oder false" zu setzen. Sieht man auch wenn man den Mauszeiger draufhält.
Da bin ich auch noch dran und werde es entsprechend optimieren. Danach dürfte auch die CPU-Last sinken.

Stelle die Tage meine optimierte "main.js" hier zur Verfügung.

[saeft2003]

@PiXasCoding das wäre echt super und wäre mir eine rießen Hilfe.

@DutchmanNL kannst du dann daraus ein offiziellen release machen?

[PiXasCoding]

Da bin ich wieder.
Habe mich nochmal genauer mit den VE.Direct Protokoll beschäftigt und meine vorab genannten Änderungen verworfen und die "main.js" nun an das hinzugelernte Wissen angepasst.
Das Protokoll sendet Blöcke, welche mit dem Datensatz "PID" beginnen und mit "Checksum" enden. "PID" steht dabei für den Gerätenamen und "Checksum" ist halt eine Checksumme des Datenblocks, welchen ich aber nicht auswerte.

Diese Blöcke könnten, je nach Gerät, evtl. auch aus mehr als nur 37 Datensätze bestehen. Daher ist es wichtig, dass der gesamte Block ausgewertet wird.
Deshalb geht es nun erst dann in die Wartschleife, wenn "PID" und "Checksum" empfangen und ausgewertet wurden, was ja innerhalb einer Sekunde geschieht. Vorher wird der Warteschleifen-Timer nicht gesetzt.
Während der Wartezeit, werden die Daten zwar weiterhin an den Adapter geschickt, aber nicht mehr ausgewertet.
Dennoch reagiert der Adapter natürlich kurz, hier könnte man sicherlich noch optimieren. DutchmanNL wäre hier wieder an der Reihe.

Die Aktualisierung des Datensatzes "connection" habe ich auch so abgeändert, dass er nur beim Start des Adapters aktualisiert.
Also der Wert dafür wird nicht mehr jede Sekunde aktualisiert, somit weniger CPU-Last.
Für den Fehlerfall greift die enthaltene Routine von DutchmanNL. welche sowieso alle 10 Sekunden den Status prüft.
Diese könnte man auch etwas höher setzen.

Ich habe mir mit dem Linux Command "top" die CPU-Last des Adapters "io.vedirect.0" angeschaut und dieser liegt nun beim RPi 4 zwischen 0,3-1% während der Warteschleife und während der Datenauswertung etwa bei 2%.
Der "Puffer in Sekunden, um Nachrichten zu ignorieren" steht dabei bei mir auf aktuell "30", später gehe ich auf "60".
Ohne Puffer liegt die CPU-Last bei dauerhaft etwa 6-8%.

Nun lasse ich das ganze erstmal ein paar Stunden so laufen und wenn nichts auffällig wird, stelle ich die angepasste "main.js" nachher zur Verfügung.

VG
Thomas

[PiXasCoding]

@saeft2003
Die Datei ist nun online, siehe:
#553

[saeft2003]

@PiXasCoding

danke werde es nachher testen…