zram: Aufhängen mit schwarzem Bildschirm bei langer Uptime

[hikaru]

Hallo,

ich betreibe ein Asus-EEE-1018p-Netbook mit Intel-GMA-3150-Grafik als HTPC/Fileserver/Torrentseeder/etc. mit Squeeze und Backports-Kernel. Das Gerät ist mit 2GB RAM ausgestattet und verträgt nicht mehr.
Um seine Aufgaben zu bewältigen ohne zu swappen fehlen ziemlich genau 300 MB RAM. Diese hole ich mir über ein 512MB-zram-Device was an sich auch gut funktioniert und die Performance merklich steigert.

Nach einer Uptime von 3-4 Wochen wird allerdings immer der Bildschirm schwarz (Signal liegt noch an) und der Rechner reagiert auf keinerlei Eingaben mehr (Ctrl+Alt+F1 geht auch nicht mehr), so dass nur noch ein harter Reboot hilft. In den Logs finden sich keine Einträge. Diese enden zu dem Zeitpunkt an dem ich vermute dass der Bildschirm schwarz wird (durch die langen Intervalle kann ich das schlecht reproduzieren - bisher war ich nie live dabei).
Ohne zram sind mehrmonatige Uptimes kein Problem.

Ich weiß zram ist noch im Staging-Bereich und bei Ubuntuusers gibt es eine vage Andeutung dass mein Problem bekannt sein könnte [1], daher erwarte ich (noch) keine wirkliche Lösung. Aber kann mir vielleicht jemand sagen was hier passiert? Ein Hinweis auf die bei Ubuntuusers erwähnten Artikel wäre z.B. hilfreich. Die Suche danach gestaltet sich etwas schwierig, denn "zram" scheint kein gutes Schlüsselwort zu sein und außerdem wechselt das Projekt ja seinen Namen öfter als ich meine Unterhosen.

[1] http://wiki.ubuntuusers.de/zRam#Problembehandlung

[pil]

Woher stammt der zram? (Er kann ja nicht aus dem Nichts gebildet werden.)

Generell würde ich zur Steigerung der Performance eine Ramdisk vorziehen, von denen ja nicht wenige standardmäßig angelegt werden (etwa /run, /run/lock, /run/shm). Hier kann man genau angeben, wieviel Ram maximal zur Verfügung stehen soll. Und er wird auch nicht 'reserviert', wenn er nicht benützt wird.

[hikaru]

Wie? "Woher stammt der zram?"? Das ist natürlich eine RAMdisk.
Angelegt habe ich sie indem ich das hier [1] als "Manuell" bezeichnete Script auf's Wesentliche reduziert habe. Ich habe das Gerät gerade nicht vor mir, aber wenn ich das aus dem Stehgreif rekonstriere müsste es so aussehen:

Code: Alles auswählen

modprobe zram num_devices=1
echo 536870912 > /sys/block/zram0/disksize # wobei ich mir bei der Zahl gerade nicht sicher bin. Ich meine mich zu erinnern dass zram hier eigentlich kB statt Byte erwartet. Auf jeden Fall sind es überprüfbar 512MB
mkswap /dev/zram0
swapon -p 100 /dev/zram0

Natürlich könnte man prinzipiell auch eine andere RAMdisk nehmen, aber der Clou von zram ist ja, dass die RAMdisk komprimiert wird und somit mehr Platz zur Verfügung stellt als nur den eigentlich von ihr eingenommenen RAM. Je nach Szenario kommt man so meist auf 50 bis 100% Gewinn gegenüber der ursprünglichen RAMdisk-Große.

Ich habe mich noch nicht damit beschäftigt wie man eine swap-Partition zu Fuß komprimiert. Genau das soll ja zram leisten. Ohne Kompression ist das Ganze witzlos, denn ich möchte ja "zusätzlichen" RAM haben.

[1] http://wiki.ubuntuusers.de/zRam#Manuell

[rendegast]

Als walkaround das ganze einfach mal, zBsp. als weekly-Job, erneuern?
(möglichst bei geringer Belegung)

Code: Alles auswählen

swapoff /dev/zram0
[[modprobe -vr zram; modprobe -v zram ; echo groesse > disksize]]
[mkswap /dev/zram0]
swapon /dev/zram0 --priority XX

Das Komprimieren des zram funktioniert ja auch nur, wenn es sich um komprimierbare Inhalte handelt.
Ansonsten belegt es ja wirklich 500MB vom Hauptspeicher.

Vielleicht darf es ja nicht voll werden? (naja, staging)
Dann könnte es auch mal anders verwendet werden, als Dateisystem mit einem angelegten swapfile beliebiger Größe.



Als Ursache vielleicht analog
unter win benutzte ich zwei Möglichkeiten, pagefiles zu "ramifizieren",
imdisk im Userspace und gavotte als echte ramdisk.
Auf beiden hatte ich pagefiles, aber mit imdisk gab es Probleme: Irgendwann hing das System.
Ich denke, daß, weil imdisk in gewissem Sinne "ungeschützt" war, irgendwann dieses in die swapfile auf die Platte ausgelagert wurde,
und das zum Kollaps führte.
(Mittlerweile nutze ich imdisk nur noch, um Platten- oder CD-Images zu mounten.)


Möglichkeiten für das Überwachen des Systemzustandes gibt es wohl etliche.
Als einfachstes ein batch-top u.a. auf ein Netzlaufwerk.
Komplexer wäre sowas wie munin.





--------------------------------------
Wenn ich mit dem device ein wenig herumspiele, läßt sich der Treiber nicht mehr entladen, Status "used".
Auch nach Beschreiben mit /dev/zero dann keine Benutzung mehr:

Code: Alles auswählen

# dd if=/dev/zero of=/dev/zram0 bs=1M
dd: writing `/dev/zram0': No space left on device
1025+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.06515 s, 1.0 GB/s

# mke2fs /dev/zram0 -m0
mke2fs 1.42.5 (29-Jul-2012)
/dev/zram0 is apparently in use by the system; will not make a filesystem here!

# mkswap /dev/zram0 
/dev/zram0: Device or resource busy

(staging?)

[hikaru]

Als walkaround das ganze einfach mal, zBsp. als weekly-Job, erneuern?

Werde ich mal probieren. Danke!

(möglichst bei geringer Belegung)

Kommt außer direkt nach dem Reboot nie vor, dadeluge viel von den Debian-ISOs die ich verteile in den RAM legt (stabilisiert sich bei ca. 700MB und auch noch eine VBox-VM mit 700MB läuft. Der Rest bis ca. 1,9GB ist dann Kleinzeug (inkl. ca. 300MB Cache).
Kritisch wird es dann wenn ich selbst noch interaktiv werde (Browser oder Video in smplayer starten dauert fast eine Minute, läuft dann aber problemlos). Aber irgendwann Nachts sollte das mit dem Ein- und Aushängen des Swap drin sein.

Das Komprimieren des zram funktioniert ja auch nur, wenn es sich um komprimierbare Inhalte handelt.

Richtig! Daher die in der Praxis schwankenden "Gewinnraten".

Vielleicht darf es ja nicht voll werden? (naja, staging)

Nochmal danke! Das klingt zumindest als Ursache plausibel.

Möglichkeiten für das Überwachen des Systemzustandes gibt es wohl etliche.
Als einfachstes ein batch-top u.a. auf ein Netzlaufwerk.

Alles Netzwerkartige fällt aus. Wenn nicht gerade mein Haupt-PC an ist oder das Notebook/Handy im Netz hängt ist das HTPC-Netbook die einzige IT die in meinem Haushalt läuft.
Für den Fall dass das mit dem Reinitialisieren nicht klappt werde ich aber mal was lokal auf die Platte schreiben (insbesondere zram-Füllstand).

[rendegast]

(Habe noch einen Zusatz gemacht,)
der Treiber kann irgendwann nicht mehr entladen werden,
und das device ist dann busy.
Gilt auch für den nur darauf mal verwendeten Dateisystemtreiber ext2.

Der Speicher kann aber wohl freigegeben werden durch "Nullen" (komprimiert gut).
Wenn ich dann den Dateicache entlade ('echo 3 > /proc/sys/vm/drop_caches'), zeigt sich das auch,
es wird wohl zumindest kein nennenswerter Speicherbereich geblockt.

Zumindest im jetzigen Entwicklungszustand (Kernel 3.2, 3.2.23-1) verhält sich dieses blockdevice also nicht so wie zBsp. eine Festplatte.

[hikaru]

der Treiber kann irgendwann nicht mehr entladen werden,
und das device ist dann busy.

Wenn man erst den Swap auf dem Device deaktiviert lässt sich auch das Modul entladen:

Code: Alles auswählen

root@htpc:/home/hikaru# swapoff /dev/zram0
root@htpc:/home/hikaru# modprobe -rv zram
rmmod /lib/modules/3.2.0-0.bpo.2-amd64/kernel/drivers/staging/zram/zram.ko
root@htpc:/home/hikaru# 

[rendegast]

@hikaru
Zuerst hat das auch schön funktioniert.
Aber dann, das swap war off, und das folgende e2fs war auch schon umountet.
Das device war einfach busy.



Das device läßt sich swapon auch gar nicht formatieren:

Code: Alles auswählen

# mkfs.ext2 /dev/zram0 
mke2fs 1.42.5 (29-Jul-2012)
/dev/zram0 is mounted; will not make a filesystem here!

[hikaru]

Über Nacht haben sich gut 300MB im Swap angesammelt. Aushängen und das zram-Modul ent- und neuladen funktionierte trotzdem.
Ich habe das jetzt mal für Sonntagnacht als Cron aufgesetzt. Mal sehen was dann passiert.