Raspberry Pi SD-Card verfügbarer Speicher nimmt offensichtlich kontinuierlich ab

Hallo Leute,

neulich hatte ich bemerkt, das meine 16GB Speicherkarte im Raspberry Pi 3+ fast voll war. In der Annahme, dass es sich hier um einen defekt handelt habe ich sie schnell ausgetauscht.
Neben dem aktuellen Raspbian Stretch sind installert:

  • IPS 5.0 stable
  • Logitech Media Server
  • PIGPIO (wobei PIGPIO schon in er Standard-Stretch dabei sind, habe ich aber auf die aktuelle Version gebracht)
  • S.USV Steuerungssoftware

Der Effekt hält aber dokumentiert an! Deswegen habe ich ihn aufgezeichnet:

  • Aufzeichnungsbeginn: 26.08.2018 ca. 11:00 Uhr mit ca. 43% Speicherkartennutzung (bei 16GB netto)
  • Aktuell schon bei 65% („schöner“ kontinuierlicher Anstieg in der grafischen Auswertung!)

Wie komme ich dem Verursacher auf die Schliche?

Joachim

Hallo Joachim,

kennst du vielleicht den Linux Befehl ‚top‘? Er gibt eine Übersicht über Speicherverbrauch und genutzte Prozessorzeit aus und verrät damit schon eine ganze Menge.

Grüße
Ralf

Hallo Ralf,

den Befehl kenne ich, meines Wissens geht es aber dabei doch eher um CPU und RAM Nutzung?

Joachim

Probier mal

du -sh /*

Damit bekommst du die Auslastung pro Verzeichnis.
Es wird zu ein paar Fehlern wegen /dev zb kommen. Das ist normal.

…werde das am späten Nachmittag mal testen - gleichwohl: Der auf der SD-Card genutzte Speicher ist seit heute 9:11 Uhr schon von 65% auf jetzt 67% angestiegen…:confused:

Joachim

schon mal das Log Unterverzeichnis von Symcon kontrolliert? Da liegen schnell einige Gigabytes an Daten.
Bei mir liegen da 34GB.
Kannst du bei den Systemschaltern verändern.

…habe zunächst mit dem letzten Hinweis angefangen - das war dann gleich ein Volltreffer!
Die Tages-Logs der letzten Tage seit Installation hatten jeweils alle ca. 1,5 GB.

Was könnte wohl die Ursache sein?

Da habe ich mal darüber nachgedacht, was in den letzten Tages neues hinzugekommen ist.
Mein neues IPS2LOGO-Modul! Also zunächst da den Fehler gesucht…
Meine Vermutung: Während der Testphase hatte ich einige „SendDebug“ in den Code eingebaut, bei diversen Ausgängen und Merkern die dann alle 250ms abgefragt wurden - und jedesmal ein „SendDebug“ enthielten - kam dawohl eine Menge Daten ins Log (kann die Datei mit dem kleinen Rechner hier nicht wirklich öffnen).
Ich habe jetzt einige der Log-Dateien seit Freitag gelöscht und diverse „SendDebug“ aus den „fertigen“ Modulen entfernt…:smiley:

Vielen Dank für die Unterstützung!

Joachim

Hi Joachim,

du musst dies aber den Spezialschaltern umstellen, ansonsten werden die wieder da sein.
Es werden dort alle Meldungen weggeschrieben, also ein ganz normaler Vorgang.

…es sind mit hoher Wahrscheinichkeit die Timerevents des IPS2LOGO-Moduls die mir die Logs so extrem anwachsen lassen:

29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: RunScript ~ Duration: 2 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: RunScript ~ Duration: 8 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 260 ~ Absender: RunScript
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 292 ~ Absender: RunScript
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: RunScript ~ Duration: 2 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: RunScript ~ Duration: 7 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 6 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 5 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 5 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 3 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 44 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 4 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 6 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 5 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 3 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 3 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 5 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 4 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 3 ms
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Skriptausführung (Text) - Länge: 36 ~ Absender: TimerEvent
29.08.2018 23:45:21 | 00000 | DEBUG   | ScriptEngine         | Executed Text (Length: 0) ~ Sender: TimerEvent ~ Duration: 4 ms

…letztendlich ja ohne richtigen Bezug…:confused:

Kann ich das in der Programmierung anders gestalten, so das nicht mit eingeht?

Joachim

Nein.
Michael

…irgendwie ist das unbefriedigend…

Zum einen nutze ich ja den gleichen Splitter, die IPS-Instanz müsste doch da nach meinen Tests sehr ähnlich vorgehen. Zum anderen ist der Nutzen dieser Information im Log doch arg eingeschränkt, da ja so doch nicht mal ersichtlich ist welcher Timer das ist und was er bewirkt?

Mein Tageslog ist um die 1,5 GB, kann ich das bei den Spezialschaltern irgendwie in den Griff bekommen?

Joachim

Ja kannst Du.

Variable und Scriptwatch

Ich bin da auch grad dran etwas zu ändern

Gesendet von iPad mit Tapatalk

Ich hatte das meine ich schon zu IPS 4.0 bemängelt das jeder Aufruf eines PHP-Moduls die RunScript Logs erzeugt.
Schätze mal das kommt erst weg, wenn paresy das Sandboxing der Module umsetzt (5.x 6.0 ? )
Michael

Ich hatte vor längerer Zeit auch das Problem mit den Logs.
Wie RWN bereits geschrieben hat, habe ich auch Script- und Variable-Watch deaktiviert.

Spezialschalter.PNG

Der Log-Ordner sieht jetzt so aus:

…habe jetzt mal ScriptWatch deaktiviert.

Wäre dann auch nicht böse, wenn die - aus meiner Sicht wenig hilfreichen - Logs der Timer zukünftig dann vielleicht im Standard nicht mehr auftauchen.
Ein Timer hat ja wahrscheinlich im Wesentlichen die Funktion ein Skript aufzurufen, dass dann u.U. eine Variable ändert…

Ich schaue dann mal wie sich die Dateigröße jetzt entwickelt.

Vielen Dank für die Unterstützung!

Joachim

…das war ein guter Tipp - auch wenn die Ursache etwas fragwürdig - wie auch immer…

Ein Auffälligkeit von der ich hoffte das sie damit behoben ist, ist die Tatsache das sich meine Konsole relativ häufig „abmeldet“ insbesondere wenn ich Objekte erstellen oder verschieben möchte. Dann kommt die Fehlermeldung das das Datenpaket zu groß war usw. IPS läuft durch, ein Neustart der Konsole ist gleich danach auch wieder möglich…

Wo könnte es einen Hinweis auf die Ursache geben?

Joachim

Hallo Joachim,

behoben ist es damit nicht. Du kannst aber nicht ändern was das System vorgibt. Im Moment ist es so, dass das System alles logt was anfällt und das ist so gewollt. Änderungen halt über die Spezialschalter möglich.

Ich hatte die Woche ein kurzes Gespräch mit paresy auch wegen meinem Modul.

Auf großen Systemen wie Win usw. mit reichlich Speicherplatz und entsprechenden Platten überhaupt kein Thema, nur bei Raspi, Symbox usw. bist Du da teilweise schnell am Ende.

Es kommt halt auch immer drauf an was das Modul macht. Hier sollte man dann wirklich überlegen was ist Sinnvoll oder nicht, grad bei Livedaten.:wink:

Schönes Wochenende noch und viele Grüße aus Nidda.

Hallo Rainer,

das Thema ist für mich erst mal abgeschlossen.

Hier ging es - ohne Threadwechsel - darin über, warum sich die Konsole regelmäßig „abschießt“. Ist ärgerlich beim Arbeiten und hat gewiss eine Ursache die zu beheben ist, wenn man nur weiß wo man suchen soll…:slight_smile:

Joachim

MessageQueue erhöhen (Spezialschalter)
Michael

Hallo Michael,

ich habe einen gefunden der heißt „Message Ring Buffer Size“.
Meinst Du den?
Habe den mal von 8192 auf 16384 hochgesetzt, Neustart gemacht, sieht aber nicht so aus als ob das hilft…[emoji17]

Joachim