SWAP: wie gross soll die Partition sein?

[Gnox]

Hallo Debianer

Brauche ich eine SWAP Partition? "Es kommt auf Deine Ansprüche an", werdet Ihr sagen. Nun, ich nutze Debian auf einem Desktop-Computer mit folgenden Spezifikationen:

Code: Alles auswählen

hugin@aorus:~/Downloads/Linux ISO$ inxi -F
System:    Host: aorus Kernel: 5.10.0-1-amd64 x86_64 bits: 64 Desktop: KDE Plasma 5.20.5 
           Distro: Debian GNU/Linux bullseye/sid 
Machine:   Type: Desktop System: Gigabyte product: X570 AORUS ULTRA v: -CF serial: <superuser required> 
           Mobo: Gigabyte model: X570 AORUS ULTRA serial: <superuser required> UEFI: American Megatrends 
           v: F11 date: 12/06/2019 
CPU:       Info: 6-Core model: AMD Ryzen 5 3600 bits: 64 type: MT MCP L2 cache: 3 MiB 
           Speed: 2204 MHz min/max: 2200/3600 MHz Core speeds (MHz): 1: 2204 2: 2185 3: 2195 4: 2193 
           5: 2178 6: 2196 7: 2195 8: 2195 9: 2675 10: 2149 11: 2184 12: 2194 
Graphics:  Device-1: NVIDIA TU116 [GeForce GTX 1650 SUPER] driver: nvidia v: 450.80.02 
           Display: x11 server: X.Org 1.20.10 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa 
           resolution: 3840x2160~60Hz 
           OpenGL: renderer: GeForce GTX 1650 SUPER/PCIe/SSE2 v: 4.6.0 NVIDIA 450.80.02 
Audio:     Device-1: NVIDIA TU116 High Definition Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.10.0-1-amd64 
Network:   Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi 
           IF: wlp4s0 state: up mac: 3c:f0:11:db:0d:03 
           Device-2: Intel I211 Gigabit Network driver: igb 
           IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: b4:2e:99:3e:1d:15 
Drives:    Local Storage: total: 5.01 TiB used: 830.03 GiB (16.2%) 
           ID-1: /dev/nvme0n1 vendor: Corsair model: Force MP600 size: 465.76 GiB 
           ID-2: /dev/sda vendor: Samsung model: SSD 860 EVO 1TB size: 931.51 GiB 
           ID-3: /dev/sdb vendor: Western Digital model: WD40EZRZ-00GXCB0 size: 3.64 TiB 
           ID-4: /dev/sdc type: USB vendor: Generic model: Flash Disk size: 3.75 GiB 
Partition: ID-1: / size: 27.84 GiB used: 8.83 GiB (31.7%) fs: ext4 dev: /dev/nvme0n1p2 
           ID-2: /boot/efi size: 511 MiB used: 30.7 MiB (6.0%) fs: vfat dev: /dev/nvme0n1p1 
           ID-3: /home size: 3.58 TiB used: 754.67 GiB (20.6%) fs: ext4 dev: /dev/sdb1 
Swap:      ID-1: swap-1 type: partition size: 14.9 GiB used: 0 KiB (0.0%) dev: /dev/nvme0n1p3 
Sensors:   System Temperatures: cpu: 42.5 C mobo: N/A gpu: nvidia temp: 37 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 23% 
Info:      Processes: 300 Uptime: 57m Memory: 31.37 GiB used: 3.21 GiB (10.2%) Shell: Bash inxi: 3.2.01 

Es ist ein aktuelles System mit 32GB RAM. Die vorhandene SWAP mit 15GB stammt aus einer Testinstallation und wird in meinem Hauptsystem, Debian Testing, (noch) nicht verwendet. Macht eine SWAP Partition bei solch einem System überhaupt noch Sinn und wie gross sollte die Partition denn ungefähr sein; stimmt die alte Regel 2xRAM immer noch?

[KP97]

Bei 32GB Ram brauchst Du keine Swap mehr, das ist verschenkter Platz.
Und nein, die alte Regel gilt nicht mehr.

Schönes Maschinchen...

[Lord_Carlos]

Macht eine SWAP Partition bei solch einem System überhaupt noch Sinn und wie gross sollte die Partition denn ungefähr sein; stimmt die alte Regel 2xRAM immer noch?

Da gibt es verschiedene Ansichten. Ich richte kein swap mehr ein.

[JTH]

Wenn du Ruhezustand/Hibernate/suspend to disk/wieauchimmer benutzen möchtest, brauchst du durchaus noch eine Swap-Partition, das funktioniert ohne nicht. Die sollte dann höchstens so groß wie der RAM sein, kann dank Kompression aber auch etwas kleiner sein.

[Gnox]

Da gibt es verschiedene Ansichten. Ich richte kein swap mehr ein.

Also wenn ich Suspend2Disk nicht brauche, was ich an meinem Desktop eh nie verwende, dann werde ich das bleiben lassen. Denn 32GB - 64GB Swap - Partition schmerzen mich zwar nicht vom Speicherplatz her, aber den einfach so brach liegen zu lassen ist ja auch schade. Passt nämlich gleich noch eine weitere Testinstallation drauf

Oder gibt es neben Suspend2Disk noch weitere Gründe, die bei 32GB FÜR eine SWAP sprechen?

[KP97]

Beim Laptop ja, wie @JTH schon geschrieben hat, sonst ist mir kein Grund auf einem Desktop bekannt.

[Lord_Carlos]

Oder gibt es neben Suspend2Disk noch weitere Gründe, die bei 32GB FÜR eine SWAP sprechen?

Manche sagen das wenn man ein Programm hat amok laeuft und den ganzen Ram fuehllt, dann hat man noch swap als Reserve.
Aber ich denke mir, wenn etwas ungewollte 32GB Ram wegnimmt, warum sollte es dann da stoppen und nicht auch noch ganzen swap fuellen?

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.

[wanne]

Oder gibt es neben Suspend2Disk noch weitere Gründe, die bei 32GB FÜR eine SWAP sprechen?

Am Ende ist die Idee hinter Swap, dass du selten genutzte Daten (GDM ist ein super beispiel) drauf auslagern kannst um mehr RAM zum Cachen und für Programme zu haben. 32GB musst du aber erst mal voll bekommen... Da ist die Gefahr groß dass du mehr kaputt machst, weil das System zu nutzlos frei räumt obwohl du eh noch genug RAM frei hast und das System eher ausbremst statt es zu beschleunigen. Am ende findest du nicht viel wirklich kalte Daten. Im Maximum kannst du vielleicht 1GiB sinnvoll auslagern. Und ob du 32GiB oder 31GiB RAM hast, macht den Kohl nicht fett...
Der zweite Vorteil ist, dass dein RAM schnell voll geschrieben ist, wenn ein Programm Ammok läuft. Swap ist langsamer. Da kannst du eventuell vor dem OOM-Killer eingreifen. Außerdem verhält der sich etwas intelligenter, wenn er SWAP hat.
Ich würde eher so 4GiB-8GiB nutzen. Bei letzterem dürfte auch noch suspend to disk funktionieren. Wichtig ist, dass du die Swapiness klein stellst und die Caches hoch stellst. Letzteres willst du so oder so machen, wenn du so viel RAM hast. Default ist, dass maximal die Hälfte für Caches genommen werden. Und du bekommst 16GiB selten mit Programmen voll. (Debian hat für solche Sytsteme nicht wirklich gute Defaults.)

[mcb]

Ich würde ev. doch eine Swappartition anlegen (32 GB) - Platz ist doch vorhanden.

[Gnox]

Ich würde eher so 4GiB-8GiB nutzen. Bei letzterem dürfte auch noch suspend to disk funktionieren. Wichtig ist, dass du die Swapiness klein stellst und die Caches hoch stellst. Letzteres willst du so oder so machen, wenn du so viel RAM hast. Default ist, dass maximal die Hälfte für Caches genommen werden. Und du bekommst 16GiB selten mit Programmen voll. (Debian hat für solche Sytsteme nicht wirklich gute Defaults.)

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

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. Swapfile ist bei Debian wohl kein Thema?

[MSfree]

Swapfile ist bei Debian wohl kein Thema?

Grundsätzlich kann man auch auf eine Swapdatei auslagern lassen, Raspbian macht das z.B. so.
Siehe dazu man swapon.

Swap ist allerdings ohnehin schon schnarchlahm. Mit dem Auslagern auf eine Datei statt einem raw Device kommt noch der Wasserkopf des Dateisystem dazu, auf dem die Swapdatei liegt. Schneller wird es dadurch jedenfalls nicht.

[Saxman]

Ich hab ein ganz ähnliches Setup. Eine SWAP Partition habe ich seit etwa 10 Jahren nicht mehr in meinem Rechner. So auch in diesem nicht. Suspend to Ram (S3) funktioniert wunderbar und mehr braucht man m.M.n. sowieso nicht.

Code: Alles auswählen

# inxi -F
System:    Host: morpheus Kernel: 5.10.0-7.1-liquorix-amd64 x86_64 bits: 64 Desktop: KDE Plasma 5.20.5 
           Distro: Debian GNU/Linux bullseye/sid 
Machine:   Type: Desktop Mobo: ASUSTeK model: TUF GAMING X570-PLUS (WI-FI) v: Rev X.0x serial: 200569711311064 
           BIOS: American Megatrends v: 3402 date: 01/13/2021 
CPU:       Info: 6-Core model: AMD Ryzen 5 3600 bits: 64 type: MT MCP L2 cache: 3 MiB 
           Speed: 3626 MHz min/max: 2200/3600 MHz Core speeds (MHz): 1: 3626 2: 3633 3: 3399 4: 3823 5: 4036 6: 3771 7: 3422 
           8: 3933 9: 3823 10: 3992 11: 3903 12: 4173 
Graphics:  Device-1: NVIDIA GP108 [GeForce GT 1030] driver: nvidia v: 455.45.01 
           Display: x11 server: X.Org 1.20.10 driver: nvidia unloaded: modesetting resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce GT 1030/PCIe/SSE2 v: 4.6.0 NVIDIA 455.45.01 
Audio:     Device-1: NVIDIA GP108 High Definition Audio driver: snd_hda_intel 
           Device-2: Advanced Micro Devices [AMD] Starship/Matisse HD Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.10.0-7.1-liquorix-amd64 
Network:   Device-1: Intel Wireless-AC 9260 driver: iwlwifi 
           IF: wlp3s0 state: up mac: e4:5e:37:bb:cd:da 
           Device-2: Intel Wireless-AC 9260 Bluetooth Adapter type: USB driver: btusb 
           IF-ID-1: virbr0 state: down mac: 52:54:00:17:c8:98 
RAID:      Device-1: md0 type: mdraid level: mirror status: active size: 931.51 GiB report: 2/2 UU 
           Components: Online: 0: sda 1: sdb 
Drives:    Local Storage: total: 5.74 TiB used: 1.6 TiB (27.8%) 
           ID-1: /dev/sda vendor: Western Digital model: WD10EZRX-00DC0B0 size: 931.51 GiB 
           ID-2: /dev/sdb vendor: Western Digital model: WD10EADS-00M2B0 size: 931.51 GiB 
           ID-3: /dev/sdc vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
           ID-4: /dev/sdd vendor: Western Digital model: WD40EZRX-22SPEB0 size: 3.64 TiB 
           ID-5: /dev/sde vendor: OCZ model: VERTEX2 size: 55.9 GiB 
Partition: ID-1: / size: 4.57 GiB used: 955 MiB (20.4%) fs: ext4 dev: /dev/dm-4 
           ID-2: /boot size: 227.7 MiB used: 56.1 MiB (24.6%) fs: ext2 dev: /dev/sdc1 
           ID-3: /home size: 150.95 GiB used: 64.41 GiB (42.7%) fs: ext4 dev: /dev/dm-7 
           ID-4: /usr size: 45.71 GiB used: 19.2 GiB (42.0%) fs: ext4 dev: /dev/dm-5 
           ID-5: /var size: 27.37 GiB used: 14.52 GiB (53.1%) fs: ext4 dev: /dev/dm-6 
Swap:      Alert: No Swap data was found. 
Sensors:   System Temperatures: cpu: 46.5 C mobo: N/A gpu: nvidia temp: 40 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 0% 
Info:      Processes: 386 Uptime: 4h 07m Memory: 31.34 GiB used: 7.81 GiB (24.9%) Shell: Bash inxi: 3.2.01 

[RobertS]

Kommt immer drauf an was man so treibt.
Versucht man Makroaufnahmen zu stacken können auch 32 GB Ram zu knapp sein.
Ich bin da bei einer Aufnahme mit 28 Bildern schon auf die Schnauze gefallen. Eine SSD dazugesteckt, die lag grad rum, warum weiß ich nicht mehr, 90GB Swap eingerichtet und nächster Versuch. Damit gings. Vorher, mit 8GB Ram und 16 GB Swap ist der Prozess immer abgebrochen.
Mag sein daß ich das mit den Raws angegangen bin, 50MPix können im Speicher schon groß werden. Aber 28 Bilder zum stacken sind auch eine eher überschaubare Menge.
Swap ist zwar langsamer als RAM, aber besser ein langsamer Prozess wie einer der wegen Speichermangel abgebrochen wird.

[MSfree]

Ich bin da bei einer Aufnahme mit 28 Bildern schon auf die Schnauze gefallen... Vorher, mit 8GB Ram und 16 GB Swap ist der Prozess immer abgebrochen.
Mag sein daß ich das mit den Raws angegangen bin, 50MPix können im Speicher schon groß werden.

Nunja, ein Bild zu 50MPix bläht sich im RAM bei 16Bit Farbtiefe zu 300MB auf. Für 28 solcher Bilder im RAM reichen also 8.4GB. Wenn das Programm dann mit 24GB nicht auskommt, ist es schlicht und ergreifen furchtbar uneffizient programmiert.

[wanne]

Wenn das Programm dann mit 24GB nicht auskommt, ist es schlicht und ergreifen furchtbar uneffizient programmiert.

Effizient ist relativ. Es gibt schnell und speichersparend. Oft genug ist das ein Gegenteil. Das bekannteste Beispiel sind 32Bit vs. 8Bit Integers. Auf Intel-CPUs rechnen erste schnell und letztere sind platzsparend. Während man bei dem Problem noch oft Mittelwege suchen kann, ist die nächst üblichere Variante Listen vs. Spase Arrays. Letztere sind flott und erstere meist deutlich schmaler. In Factorio sind Megabasen auch auf High-End CPUs defakto nicht spielbar, weil sie so hart darauf optimiert haben, dass das Spiel auch bei 4GiB RAM noch läuft. Dynamische Programmierung ist das nächste Lehrbuchbeispiel.
Und beim Thema Bildbearbeitung: 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.
So nein, das muss nicht dumm sein. Performance ist da meistens das kleinere Problem. Das Bild zumindest doppelt zu halten schadet aber schon um den Code sauberer zu halten nicht. (Gerade lokale Filter geben einen buggy Mess, wenn du die inplace implementierst.) Und dann platzt dir das halt bei 16GiB.

[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.