Speicher voll?

Hallo @paresy ,

bei mir kam es auch jetzt in letzter Zeit öfters vor, dass sich Symcon aufhängt (Konsole nicht erreichbar, ssh und ping gehen). Erst ein kompletter Neustart der gesamten Symbox hat geholfen. loop0, loop1 und tmpfs sind voll ausgelastet. Zur Konfiguration, ich habe eine Symbox im Metallgehäuse, ca 3-5 Jahre alt.

Nach dem Neustart sind die Logdateien natürlich klein, aber vorher kam ich nicht mehr bis zu den Logdateien durch.

Welche Ursachen könnte die hohe Auslastung haben und wie bekomme ich sie runter?

Schöne Grüße

Stefan

Hi Stefan,

kannst du mal vor dem Neustart im SymOS schauen welche Logfiles denn den Platz belegen? Wir rotieren diese nämlich immer bevor der Platz zu voll wird. Am Ende sollte eine zu volle Logfile Partition aber trotzdem keinen Absturz verursachen.

paresy

Ich kam leider nicht mehr rein, beim nächsten mal probiere ich es.

Aktuell sieht es bei mir so aus:

Ist es normal dass loop0 un 1 mit 100% belegt sind?

Sind natürlich ein paar Backups geworden, da könnte ich auch ein paar aussortieren.

Schöne Grüße

Ja, das passt. Die loop Devices sind nur die gemounteten read-only Partitionen von SymOS und IP-Symcon. Schau gerne mal per SSH nächstes mal - das sollte eigentlich immer gehen, auch wenn die SymOS Oberfläche mal nicht erreichbar ist.

paresy

So sah es jetzt aus:

Mittlerweile stürzt Symcon mehrmals täglich ab. @paresy hast du hier eine Idee?

Komisch ist, dass diesmal die Logdatei nicht mal groß ist:

Ich denke, dass es eine andere Ursache haben muss.

Magst du mir mal deine Lizenz E-Mail Adresse per PM senden? Dann schau ich mal, ob wir irgendwas an Crash Reports bekommen haben.

paresy

Hallo, ich reihe mich hier mal ein, weil ich scheinbar ein ähnliches/das selbe Problem habe:
Ich wollte Gestern ein Update meiner Symbox auf die Version 7.0 durchführen (aktuell läuft das System noch auf der 6.0).
Dabei ist mir aufgefallen, dass kein Platz für Backups vorhanden ist. Also schnell die vorhandenen Backups von der Symbox runterkopiert um Platz zu schaffen. Leider ohne Erfolg. Genervt aufgegeben und bis heute Morgen abgewartet.
Seit letzter Nacht ist der verfügbare Speicher für Backups sogar auf Null runter gegangen:
image

Hier noch ein Auszug aus dem System:

Mon Nov 27 08:52:24 CET 2023
08:52:24 up 161 days, 17:34, load average: 0.04, 0.03, 0.01
Linux SymBox 4.14.114-v7 #2 SMP Sun Sep 19 20:07:15 UTC 2021 armv7l GNU/Linux

  •          total        used        free      shared  buff/cache   available*
    

Mem: 996388 133472 53780 78908 809136 749276
Swap: 0 0 0

Filesystem 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 72.7M 55.3M 57% /tmp
/dev/mmcblk0p2 379.4M 214.0M 141.3M 60% /mnt/system
/dev/mmcblk0p3 3.0G 3.0G 0 100% /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

Und hier die Logdateien:

Bislang habe ich noch keinen Reboot der Symbox durchgeführt.
Kann mir jemand bei dem Fehler helfen?

Gruß Marc

Magst du mal bitte http://symbox.local/#resize aufrufen?

paresy

Hallo paresy,

Danke für die schnelle Rückmeldung. Hier der output nach dem „#resize“:

Gruß Marc

Ich kann genau das gleiche Verhalten bei einem Kunden feststellen. Allerdings sind wir hier noch auf einer älteren SymOS Version untewegs.
300 MB für Backups belegt. 200 MB Speicher frei. Backups gelöscht, immer noch 200 MB frei. Ein #resize liefert ebenfalls die Meldung, dass die Datenpartition den gesamten Speicher verwendet.

Kannst du dich per SSH einloggen und dies hier starten?

du -sh /mnt/data/*

paresy

Natürlich:

du -sh /mnt/data/
4.0K /mnt/data/backup
16.0K /mnt/data/lost+found
1.8G /mnt/data/symcon
#

Gruß Marc

Und dann bitte noch mal

du -sh /mnt/data/symcon/*

Ich vermute deine Datenbank nutzt den ganzen Speicherplatz.

Kein Thema. Hier der outpus:

du -sh /mnt/data/*

4.0K /mnt/data/backup
16.0K /mnt/data/lost+found
1.8G /mnt/data/symcon

du -sh /mnt/data/symcon/*

4.0K /mnt/data/symcon/backup
4.0K /mnt/data/symcon/cams
4.0K /mnt/data/symcon/cert
1.8G /mnt/data/symcon/db
16.0K /mnt/data/symcon/media
4.0K /mnt/data/symcon/minidump
5.0M /mnt/data/symcon/modules
4.0K /mnt/data/symcon/php.ini
956.0K /mnt/data/symcon/scripts
4.0K /mnt/data/symcon/session
1.1M /mnt/data/symcon/settings.json
12.2M /mnt/data/symcon/webfront

Gruß Marc

Die Datenbank scheint bei dir den Speicher komplett zu nutzen. Was sagt denn das Archiv, wenn du reaggregierst?

paresy

Habe alle Variablen neu reaggregiert. Lief ohne Probleme durch.
Ergebnis sieht allerdings noch nicht gut aus:

du -sh /mnt/data/*

4.0K /mnt/data/backup
16.0K /mnt/data/lost+found
1.8G /mnt/data/symcon

du -sh /mnt/data/symcon/*

4.0K /mnt/data/symcon/backup
4.0K /mnt/data/symcon/cams
4.0K /mnt/data/symcon/cert
1.8G /mnt/data/symcon/db
16.0K /mnt/data/symcon/media
4.0K /mnt/data/symcon/minidump
5.0M /mnt/data/symcon/modules
4.0K /mnt/data/symcon/php.ini
956.0K /mnt/data/symcon/scripts
4.0K /mnt/data/symcon/session
1.1M /mnt/data/symcon/settings.json
12.2M /mnt/data/symcon/webfront

Gruß Marc

Hast du mal in der Archivverwaltung geschaut und die Variablen nach Größe sortiert? Da müsste man gut erkennen was die Datenmengen verursacht.

1 „Gefällt mir“

Habe ich gemacht. Da sind ein paar Variablen drin, die relativ viel (keine Ahnung ob normal) Speicher verbrauchen. Richtige Ausreißer gibt es da aber nicht:

Gruß Marc

das sieht dann aber eher nach Datei-Leichen in den Verzeichnissen aus hast du früher mal Variablen mit viel Daten rausgeworfen ?
Denn die ~100MB sind jetzt nicht sonderlich auffällig.
Ich würde erstmal eine Sicherung der DB machen. Evtl kannst aber die Sicherung schon checken auf Auffälligkeiten