Das addiert sicht halt … die paar Variablen in deinem Screenshot addieren sich schon zu 1000 MB Speicherbedarf. Da fehlt nicht mehr so viel zu den 1.8 GB.
Inzwischen bietet IPS die Möglichkeit, ältere Archivdaten auszudünnen. Das wäre hier ein geeigneter Anwendungsfall, Sensordaten der der Vorjahre braucht man nicht unbedingt in voller Detailtiefe.
Gerade nochmal genauer geschaut. In dem DB Verzeichnis liegt noch eine Datei (loggin.old) aus dem Jahr 2016 mit knapp 500MB rum:
du -h logging.old
463.2M logging.old
An sonsten denke ich auch, dass sich die Werte einfach zusammenaddieren.
Klingt absolut vernünftig. Die Frage ist was hier praktikabel wäre und vor allem nachhaltig das Problem beseitigt. Da wäre ich wirklich für konkrete Tipps dankbar.
Gruß Marc
Die kannst du löschen. Ist aus 3.4 Zeiten.
paresy
Erstmal vielen Dank für die vielen Hilfestellungen hier! 
Die Datei habe ich gelöscht. Das löst das Problem arber nicht oder nur bedingt:
Mon Nov 27 19:25:22 CET 2023
19:25:22 up 162 days, 4:07, load average: 0.08, 0.24, 0.16
Linux SymBox 4.14.114-v7 #2 SMP Sun Sep 19 20:07:15 UTC 2021 armv7l GNU/Linuxtotal used free shared buff/cache availableMem: 996388 171044 487124 124940 338220 664568
Swap: 0 0 0Filesystem Size Used Available Use% Mounted on
devtmpfs 474.5M 0 474.5M 0% /dev
tmpfs 64.0M 0 64.0M 0% /dev/shm
tmpfs 128.0M 117.6M 10.4M 92% /tmp
/dev/mmcblk0p2 379.4M 214.0M 141.3M 60% /mnt/system
/dev/mmcblk0p3 3.0G 2.5G 303.2M 90% /mnt/data
/dev/loop0 40.3M 40.3M 0 100% /mnt/symupd
/dev/loop1 21.6M 21.6M 0 100% /mnt/symcon/dev/loop0: 0 /mnt/system/symupd/symupd_6.0-32.sqfs
/dev/loop1: 0 /mnt/system/symcon/symcon_6.0-122.sqfs
Gefühlt würde ich sagen, dass hier beim letzten Update auf die 6.0 irgend etwas schief gelaufen ist. Ich hatte früher immer genug Speicherplatz um z.B. min. drei Backups auf der Symbox liegen zu lassen. Jetzt ist selbst nach dem Löschen der alten Archivdatei gerade mal 300MB frei:
.
Neue Variablen, die geloggt werden, sind eigentlich auch schon seit langer Zeit (bestimmt ein Jahr und länger) keine mehr dazugekommen.
Irgendwie seltsam das Verhalten…
Gruß Marc
Es bleibt dir leider nur übrig per WinSCP zu schauen, wer genau so viel verbraucht - bzw. wie oben vorgeschlagen in der Archiv Instanz zu sehen, welche Variable viel benötigt und dort ausdünnen. Dafür haben wir seit der 6.4 die „Ausdünnen“ Funktion.
paresy
Okay, dass heißt das Ziel muss sein auf eine neuere Version upzudaten um die Logdaten dann komfortabel ausdünnen zu können. Aktuel schlägt die Symbox vor, direkt auf 7.0 upzudaten. Ist das okay? Ich hätte erwartet, dass da noch ein paar Zwischenschritte von Nöten sind.
Ab wieviel Prozent freien Speicher wäre es denn gefahrlos möglich das Update anzugehen?
Was ich noch nicht so richtig verstanden habe:
Für die Auslastung von /mnt/data sind die großen Archive verantwortlich.
Aber warum sind /mnt/symupd und /mnt/symcon auch zu 100% voll?
Gruß Marc
/dev/mmcblk0p3 3.0G 2.5G 303.2M 90% /mnt/data
/dev/loop0 40.3M 40.3M 0 100% /mnt/symupd
/dev/loop1 21.6M 21.6M 0 100% /mnt/symcon
Verstehe ich das richtig, du hast die logging.old mit 463MB gelöscht und trotzdem sind nach dem Löschen nur 300 MB frei?
Ja, genau. Da muss irgendwo ein kleiner Bitfresser in der Symbox leben, der die theoretisch freigewordenen weiteren 163MB aufgefuttert hat. 
Gruß Marc
Die sind real only. Für das OS ist der Speicherplatz auf /mnt/data auch egal. Alle Systemdateien liegen auf /mnt/system. D.h. das System sollte problemlos updaten 
paresy
Kannst Du bitte mal schauen, ob Dir das ArchiveControl eine Reaggregation von Variablen vorschlägt? Wenn ja, kannst Du diese durchführen und danach mal den Speicherplatz prüfen?
Das hatte ich bereits geprüft. Reaggregation wurde für ein paar Variablen vorgeschlagen. Habe dann allerdings alle Variablen reaggregiert. Brachte allerdings keine Besserung.
Als nächstes werde ich das Update auf die 7.0 dirchführen sobald ich etwas mehr Zeit finde (fals Nacharbeiten notwendig sind).
Ein Backup komnte ich Gestern bereits erstellen.
Gruß Marc
Kurze Rückmeldung. Habe soeben auf die 7.0 upgedated. Das System schaut und fühlt sich jetzt deutlich gesünder an:
Sun Dec 3 08:29:59 CET 2023 (Compute Module 3 Rev 1.0)
08:29:59 up 2 min, load average: 0.38, 0.30, 0.12
Linux SymBox 5.10.110-v8 #2 SMP PREEMPT Tue Aug 29 15:36:06 UTC 2023 aarch64 GNU/Linuxtotal used free shared buff/cache availableMem: 979256 141700 459776 47128 377780 774732
Swap: 0 0 0Filesystem Size Used Available Use% Mounted on
devtmpfs 436.1M 0 436.1M 0% /dev
tmpfs 64.0M 0 64.0M 0% /dev/shm
tmpfs 128.0M 372.0K 127.6M 0% /tmp
/dev/mmcblk0p2 379.4M 233.8M 121.6M 66% /mnt/system
/dev/mmcblk0p3 3.0G 1.7G 1.1G 60% /mnt/data
/dev/loop0 53.0M 53.0M 0 100% /mnt/symupd
/dev/loop1 40.0M 40.0M 0 100% /mnt/symcon/dev/loop0: 0 /mnt/system/symupd/symupd_7.0-112_arm64.sqfs
/dev/loop1: 0 /mnt/system/symcon/symcon_7.0-477_arm64.sqfs
Und für Backups ist jetzt auch wieder Speicher frei:
Nichts destotrotz werde ich mich mal dem Thema Archive widmen und für die Variablen, wo keine Langzeithistorie benötigt wird etwas ausdünnen bzw. die Einstellungen anpassen.
Besten Dank an den guten Support hier im Forum schon mal.
Gruß Marc
Ich hab das Problem nach sehr langer Zeit auch mal wieder:
Ich hab allerdings auch sehr viel Fehler im Log. Wo kann ich mir die ansehen?
Denn in den Logfiles in SymOS Oberfläche find ich nix.
Allerdings ist auf der Maschine seit 1 Woche TailScale. Dort steht jede Menge Zeug drin das ich nicht verstehe.
Hier was das System sagt.
Wo setze ich denn da am besten an?
Ah, dann fiel noch was auf. Hab mir auch das Archiv angesehen. 3 Variablen wollten aggregiert werden.
Danke und Gruss
Seppm
PS: Hab jetzt mal nicht neu gestartet, da IPSview läuft. Allerdings kommt mir das ganze Ding sehr langsam vor, werde also spätestens morgen starten da das Ding laufen muss.
Ich Reihe mich mal mit ein, denke das ist das identische Problem. Logfile wird schnell zu groß und aktuell habe ich alle 2Std. einen Neustart.
Regelmäßige ungewollte Neustarts - IP-Symcon - IP-Symcon Community
