Arbeitsspeicher: wo ist die Auslastung ersichtlich?

[Bluebrain]

Leider brachte mich die Suchfunktion nicht weiter.
Wo kann man denn die Arbeitsspeicher-Auslastung des Miniservers (v1) sehen?

Im Debug-Monitor finde ich "Heap" mit einem Wert von 43 MB.
Heap sollte doch eigentlich der freie Arbeitsspeicher sein.
Nur wie kann es dann sein, dass ich die Warnmeldung bekomme, dass nur noch sehr wenig frei ist???

[Gerrit]

Wie Loxone es intern handelt kann ich nicht sagen, aber Heap könnte bedeuten, dass es nur der allockierte Speicher ist oder aber der aktuell genutzte. Allgemein wird beim Miniserver aber der Heap dem Max Wert gegenübergestellt. Max liegt ca. bei 49-50 MB. Und 43 MB ist dann tatsächlich ein vergleichsweise hoher Wert. Ich hatte im Gateway Betrieb tw. höhere Heap Werte im Vergleich zum Einzelbetrieb, aber nie über 40 MB. Im Endeffekt musst du damit rechnen, dass es mal zu ungeplanten Reboots kommt oder ein Update mal nicht mehr geht.
Vielleicht hat ja einer einen Tipp, was viel RAM benötigt. Wie viele Objekte hat denn deine Programmierung? Ich hätte als RAM Verbraucher z.B. viele parallele HTTP Requests auf der Liste, falls du da was verringern kannst, im Endeffekt wirst du wahrscheinlich wie viele von uns nur auf wenig verzichten können und da wäre es natürlich das beste die größten Verbaucher zu kennen um gezielt möglich wenig deaktivieren zu müssen.
Ansonsten wenn du mit deiner Programmierung noch nicht am Ende bist oder gern die aktuellen Updates einspielen willst, um von Verbesserungen und Bugfixes zu profitieren, würde ich gedanklich schonmal einen 2. Miniserver einplanen. Mit Updates wird der RAM Verbrauch in der Regel größer. Gerade durch den Miniserver 2. Gen. wird man bei bestimmten Features in der Zukunft vllt nicht mehr so speicherschonend programmieren, was in der Regel auch immer mehr Aufwand und Fehleranfälligkeit bedeutet.

[Bluebrain]

Habe ich das evtl. falsch interpretiert?
Ist die "Heap" Angabe nicht der freie, sondern der belegte Heap-Speicher?
i.d.R. wird nämlich der noch verfügbare angegeben.

Hier mal der Output vom Monitor:


Und ja, ich habe doch einige virtuelle HTTP Ein- und Ausgänge.


Reboots hatte ich keine. Aufgefallen ist es mir nur, weil ich die Fehlermeldung bekam, dass wegen zu wenig freiem Arbeitsspeicher das Auto-Update nicht eingespielt werden konnte.
Aber zum Glück. Denn das wollte ich auch nicht machen.

[Bluebrain]

Nachtrag:
Ich habe das also nicht falsch verstanden.
Loxone selbst schreibt, dass die Angabe neben "Heap" der ungenutzte Speicher ist!

https://www.loxone.com/dede/kb/loxone-monitor/

Warum bekomme ich also bei rund 85% freiem Speicher eine Warnung???

[Gerrit]

zu 99,9% ist die Doku dort falsch, habe auch mit dem Endpunkt "dev/sys/heap" verglichen (gleiche Werte) und die Speicherauslastung bzw. Änderung hat immer auch zur Programmauslastung gepasst

[Gerrit]

btw. habs an Loxone gemeldet

[Christian Fenzl]

Was die einzelnen Bausteine brauchen, kann man schwer ausmachen, und hat Loxone auch nicht dokumentiert.

Aber rein aus der Sicht eines Entwicklers kann man sich ungefähr ausmalen, was (eher "unsichtbar") Speicher braucht:

• Merker -> Können seit V10(?) direkt durch Referenzen ersetzt werden.
• Merker mit Verzögerung -> Jeder Verzögerungs-Tick belegt wohl einmal den Wert im Speicher (Verzögerung 5 = 5 Werte)
• Gleitender Mittelwert -> Die Anzahl der Intervalle sind jeweils ein Speicherplatz
• Remanenz -> Die Werte eines remanenten Bausteins müssen zumindest bis zum nächsten Schreibzyklus (aktuell glaube ich eine Stunde) im RAM gehalten werden.
• Jeder virtuelle Eingang -> VI's sind "by Design" remanent
• Virtuelle Eingangs-Befehle (http/udp) -> Zumindest wenn in Verwendung oder visualisiert, müssen deren Werte gespeichert werden. Unklar ist, ob nicht verwendete Eingangsbefehle (also nichts angeschlossen und nichts visualisiert) überhaupt verarbeitet werden.
• Virtuelle HTTP-Eingänge -> Zumindest während der Abarbeitung der Befehlserkennungen dürfte der Response im Speicher gehalten werden.
• Statistik -> Auch Statistikdaten werden zur Schonung der SD nicht mehr direkt geschrieben, bleiben also zumindest eine Zeit lang im Speicher.
• PicoC -> Da man hier das Speichermanagement selbst über hat, kann man da auch einiges verballern, wenn man nicht aufpasst.
• Die Anzahl der Objekte an sich -> Da so gut wie jedes Objekt per REST direkt angesprochen werden kann, müssen wahrscheinlich zumindest die Bezeichnungen im RAM gehalten werden. Wenn man z.B. aus Vorlagen vom LoxBerry 50 Wetterdateneingänge importiert, aber nur 5 verwendet, belegen die anderen 45 vermutlich ziemlich sinnlos Speicher. Die sollte man löschen.
• Im Gateway-Konzentrator-Betrieb muss der Master alle Objekte kennen, von denen er Daten aller anderen MS empfängt/verarbeitet, sowie jene, die er visualisieren muss. Ist die Außentemperatur z. B. am Client, und wird in Logik am Master verwendet, gibt es das Objekt auf beiden MS im Speicher.

Ein paar Programmbausteine wie Regler (IRR, PID, PI) müssen auch ein paar Daten zwischenspeichern, wie auch Schaltuhren (IRR, Schaltuhr, Code Touch) dürften einige Arrays für Zeiten pro Wochentag/Betriebsmodi halten, aber die kann man eher schwer weg rationalisieren.

Die Speicherverwaltung der Miniserver-Firmware ist meiner Ansicht nach sehr effizient. Hoffentlich bleibt das auch trotz MSv2 so.

LG, Christian

[Clubsport]

Hallo zusammen,

ich muss diesen Thread mal entern....
Auch ich bekomme neuerdings beim Update-Versuch immer die Meldung, dass nicht genug freier Arbeitsspeicher verfügbar ist. Ein zeitlicher Zusammenhang mit der Markteinführung des Miniserver 2 ist natürlich rein zufällig.....

Gibt es irgendwie eine Schritt-für-Schritt-Anleitung wie man prüfen kann, WAS GENAU da den Arbeitsspeicher belegt, und wie voll "fast voll" ist....?
Mittel und Wege dies zu reduzieren?
Wenn ich Christians Ausführungen richtig interpretiere, wäre ja die Reihenfolge:

Merker: Mag ich ungern auf Direktverknüpfungen umstellen, da ich kein Freund davon bin dass wenn man die mal aus Versehen trennt, man rätseln muss wo er hergekommen ist. Wäre aber prinzipiell möglich.

Remanenzen: Hmm, Komforteinbußen

Statistiken: Okay, sind irgendwie eher "Nice to have" , könnte man reduzieren

Was mich insgesamt wundert: Ich habe schon deutlich ausgemistet, und mein Miniserver Go treibt "nur" eine 3-Zimmer-Wohnung. Ich hätte erwartet, das schüttelt der locker aus dem Ärmel.

Grüße, Martin

[Christian Fenzl]

Erster Schritt wäre für mich immer:
Miniserver stromlos machen.
Danach nochmal das Update probieren.