SWAP: wie gross soll die Partition sein?

[MSfree]

Früher mal haben die ganz gerne immer nur teile von Bildern in den RAM geladen um den zu bearbeiten und dann zurück zu schreiben. Spart RAM. Ist aber grauenhaft langsam.

Ja, es spart unter Umständen sogar extrem viel RAM, aber es muß nicht langsam sein, wenn man es richtig macht.

Wenn man das Problem so zerlegen kann, daß man jeden Bildausschnitt nur einmal lesen muß, ist es nicht unbedingt (signifikant) langsamer, das Bild in Häppchen abzuarbeiten als es zuerst komplett ins RAM zu befördern und dannn in einem Rutsch zu verarbeiten. Natürlich gibt es einen gewissen Overhead bei der partiellen Verarbeitung, aber der liegt im einstelligen Prozentbereich, wenn man sich nicht komplett dumm anstellt.

Und warum das genannte Stackingproblem mehr als den dreifachen Speicher benöigt, als Bilddaten vorhanden sind, deutet schon auf sehr ineffiziente Programmierung hin.

[RobertS]

Jetzt zieht euch mal nicht so an dem Beispiel hoch.
Beim Stacken sind ein paar Schritte mehr notwendig wie nur Bilder übereinander legen.
Ausrichten in 2 Ebenen, Drehung, Verzerrung, Ausschnitt anpassen, Schärfeebene isolieren, Störende Elemente ausblenden, ob die blöde Fliege die vors Blümchen fliegt oder schwebende Staubkörner, da kommt schon was zusammen.
Darum gehts hier aber nicht. Thema ist Swap oder nicht.
Unnötige Swappartition tut nicht weh, kann aber praktisch sein.

[wanne]

Wenn man das Problem so zerlegen kann, daß man jeden Bildausschnitt nur einmal lesen muß, ist es nicht unbedingt (signifikant) langsamer, das Bild in Häppchen abzuarbeiten als es zuerst komplett ins RAM zu befördern und dannn in einem Rutsch zu verarbeiten.

Du musst halt jedes mal neu decoden. (Ja man kann auch teildecoden. Dann wird es aber ugly.) Für alles was lokal läuft ist das meist mehr Arbeit als die eigentliche Funktion.
Die älteren Programme haben dann ganz gerne das decodete schrott als temporäre Dateien irgend wo hin geschmissen. Dann hast du halt das nach programmiert, was SWAP macht nur in ineffizient, weil der Seek auf der Platte oft nicht benötigt wird und bei einer schnellen CPU langsamer als der gesamte filter ist.

[wanne]

Damit meinst Du, dass Debian nicht so gute Defaults mitbringt für Systeme mit soviel RAM?

Ja. dirty_ratio und dirty_background_ratio willst du eigentlich hoch setzen. vfs_cache_pressure für Desktops runter.
Wenn du mutig bist, kannst du auch dirty_writeback_centisecs und dirty_expire_centisecshoch setzen.
Daneben kann man, wenn man swap hat overcommit_memory auf 2 und overcommit_ratio setzten auf 75 oder so setzen. (Dann läuft der oom-killer defakto nie los. Und das System wird halt lahm und du kannst mit sysresq-Tasten runterfahren.) Oder overcommit_memory auf 1 setzen wenn du wie Lord_Carlos den oom-killer liebst und willst, dass dir Prozesse abgeschossen werden, wenn RAM knapp wird. Die Heuristik (overcommit_memory = 0 ) die Debian mitbringt ist aber auch nicht dumm.
Länglichere Antworten Infos da:
https://unix.stackexchange.com/question ... em-caching
https://engineering.pivotal.io/post/vir ... vercommit/

Dann werde ich einen Mittelweg suchen. So ca. 12GB Swap auf dem NVMe, wo auch das Betriebssystem liegt. Dann sollte auch Suspend2Disk laufen, falls ich das in einem Zustand geistiger Umnachtung doch mal benutze.

Wie gesagt: Ich finde das keine schlechte Idee.

Swapfile ist bei Debian wohl kein Thema?

Kann man alles machen. Eigentlich™ sollte das mittlerweile zumindest auf ext4 keinen overhead mehr haben. (Der merkt sich wo das File liegt, sagt dem ext4, dass es das nicht bewegen darf und benutzt es wie ne Partition.) Kenne aber niemand der es nutzt.

Dazu kommt auch noch das der OOM kill der eigentlich unter Linux Prozesse toeten soll wenn ram + swap knap wird, einfach nicht gut funktioniert. Und wenn swap erstmal voll ist und der OOM nicht will, dann kannst du das System vergessen und musst hard reset machen.

Nochmal als Erklärung. NEIN. Die Idee von Linux ist eben das System am Leben zu erhalten. Klassisch: (overcommit_memory auf 2) können halt so lange keine neuen Programme mehr gestartet werden/speicher nutzen, bis ein älterer Prozess sich beendet und seine Ressourcen wieder frei gibt. Du kannst da mit SysResq Tasten manuell entweder alle Prozesse Beenden (e) oder killen (i) oder manuell einen (sinnvollen) per OOM-Killer (f) killen lassen.
Dafür bleibt ein kleiner Teil (overcommit_ratio) des RAMs+SWAP immer frei.
Um das nicht mehr zu müssen gehen moderne Linuxe (overcommit_memory auf 0) aggressiver vor und verschätzen sich aber vor allem bei wenig SWAP gerne mal. Dann läuft der OOM-Killer von selbst los.
Du kannst auch overcommit_memory auf 1 setzen. Dann läuft das System halt mit Vollgas gegen die Wand, bis der Arzt OOM-Killer kommt.

[MSfree]

Swapfile ist bei Debian wohl kein Thema?

Kann man alles machen. Eigentlich™ sollte das mittlerweile zumindest auf ext4 keinen overhead mehr haben. (Der merkt sich wo das File liegt, sagt dem ext4, dass es das nicht bewegen darf und benutzt es wie ne Partition.) Kenne aber niemand der es nutzt.

Dateien können fragmentiert sein, und das führt zu etwas mehr Overhead als ein rohes Diskdevice. Dramatisch ist das aber in der Regel nicht.

Wie schon oben gesagt, richtet Raspbian Swap als Datei ein. Das hängt aber mit dem "Installationsvorgang" zusammen, bei dem nur ein vorinstalliertes Raspbian-Image auf eine SD-Karte kopiert wird. Beim ersten Booten wird die Partition der Installattion auf die größe der SD-Karte ausgedehnt. Das Einrichten einer Swappartition ist auf diesem Weg nicht vorgesehen.

[wanne]

Dateien können fragmentiert sein,

Früher hat sich swapon einfach mit "invalid argument" vollständig geweigert solche Dateien zu nutzen. Jetzt hast du halt für n fragmente halt n swap-ranges. ext4 weiß dann, dass es die Blöcke nicht mehr verschieben darf, weil der Kernel da direkt auf den Blöcken rumfrimelt ohne übers Dateisystem zu gehen.
Hier ein Beispiel:

Code: Alles auswählen

# filefrag /boot/swap # Datei hat 9 Fragmente
/boot/swap: 9 extents found
# swapon /boot/swap
# e4defrag /boot/swap  # defrag scheitert weil SWAP
e4defrag 1.44.5 (15-Dec-2018)
ext4 defragmentation for /boot/swap
[1/1]/boot/swap:          0%    [ NG ]
 Success:                       [0/1]
# filefrag /boot/swap
/boot/swap: 9 extents found
# swapoff -a
# e4defrag  /boot/swap  # jetzt wird defragmentiert
e4defrag 1.44.5 (15-Dec-2018)
ext4 defragmentation for /boot/swap
[1/1]/boot/swap:        100%    [ OK ]
 Success:                       [1/1]
 # filefrag /boot/swap 
/boot/swap: 6 extents found # nur noch 6 Fragmente.

Ähnliche Hacks benutzte immer Grub 1, um seine Dateien wieder zu finden. Der hat auch kein ext4 verstanden sondern sich auch nur die Blöcke gemerkt und ext angewiesen, die nicht zu verschieben.

Raspbian-Image auf eine SD-Karte kopiert wird. Beim ersten Booten wird die Partition der Installattion auf die größe der SD-Karte ausgedehnt. Das Einrichten einer Swappartition ist auf diesem Weg nicht vorgesehen.

Swap auf der SD-Karte ist wahrscheinlich auch ein sicherer Weg, die ins Nirvana zu schicken und gleichzeitig nicht wirklich schön zu bedienen...

[mcb]

Na ja ob "sinnvoll" oder nicht ich würde einfach eine anlegen, dann fehlt sie im Zweifel nicht.

[The Hit-Man]

also ich nutze systemd-swap. das legt es dynamisch an.

[Noar]

Ich hatte auch noch so im Kopf, dass SWAP hauptsächlich noch bei Verwendung von den "suspend to..." Geschichten Sinnvoll ist. Daher habe ich zuletzt bei Installationen immer SWAP von etwa der Größe des RAM angelegt.
Interessant zu hören, dass das wohl nicht mehr zwingend notwendig ist. Muss in nächster Zeit eh mal ein System neu aufsetzten, ich glaube dann teste ich das mal ohne SWAP.

[MSfree]

Interessant zu hören, dass das wohl nicht mehr zwingend notwendig ist.

Wie du schon sagtest, für suspend to disk ist es erfordelich. Ohne Swap kannst du halt nur runterfahren und kalt starten, mit Swap kannst du die Kiste schlafen legen.

Swap ansich war aber noch nie zwingend nötig. Vorausgesetzt, man hat genug RAM, konnte man Linux schon immer ohne Swap betreiben, und das mache ich auch schon seit meiner ersten Linuxinstallation (SuSE 5.2) so. Damals halt noch mit 128MB RAM.

[Noar]

Ja, stimmt. Danke für die Klarstellung.

[TuxPeter]

Möchte noch eine Anmerkung zu "supend to disk" loswerden. Als ich das (vor 2 .. 3 Debian-Versionen) das letzte mal ausprobiert habe, konnte ich feststellen, dass es kaum schneller als ein kompletter Neustart ist. Und heute, mit SSD-HD auf der einen und ordentlich viel RAM auf der anderen Seite, dürfte dieser Vorteil komplett dahin sein.

Möglicherweise könnte es u.U. interessant sein, den aktuellen Zustand der Maschine damit zu "konservieren" - aber so zu arbeiten, halte ich für ziemlich unpraktisch.

[Lord_Carlos]

den aktuellen Zustand der Maschine damit zu "konservieren" - aber so zu arbeiten, halte ich für ziemlich unpraktisch.

Warum?

[MSfree]

Als ich das (vor 2 .. 3 Debian-Versionen) das letzte mal ausprobiert habe, konnte ich feststellen, dass es kaum schneller als ein kompletter Neustart ist.

Im Gegenteil, je mehr RAM man in der Kiste hat, desto lahmer wird das Aufwachen aus dem Suspend. Es dauert dann sogar länger als ein Kaltstart.

Aber, wenn du im Libreoffice ein Dokument offen hast und den Cursor hinterm dem "e" des vorletzten Worts stehen hast, ist der auch nach dem Aufwachen wieder hinter dem "e" des vorletzten Worts. Ob einem diese Bequemlichkeit die Sache wert ist, muß jeder für sich slebst entscheiden.