Frage zu SWAP | Sie ist permanent voll | Muss das sein?

foofoobar schrieb:
Das ändert nicht viel an der Sache. Es dauert nur länger. Das Ergebnis ist im Endeffekt das Selbe.
Code:
top - 22:39:50 up 1 day,  6:42,  1 user,  load average: 0,03, 0,05, 0,04
Tasks: 199 total,   1 running, 198 sleeping,   0 stopped,   0 zombie
%CPU(s):  1,0 us,  0,7 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   7947,8 total,   3772,2 free,   1917,5 used,   2542,7 buff/cache
MiB Swap:  18432,0 total,  14368,4 free,   4063,6 used.   6030,3 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   1733 privat    20   0 5319592 665144  12828 S   0,3   8,2   6:39.13 granian asginl
 
AGB-Leser schrieb:
Auch auf meinem normalen System kann ich da nicht reinschauen, da wird also irgendeine Art von Verschlüsselung existieren

Was meinst du mit reinschauen? Swap ist die Erweiterung vom RAM.
Mit verschlüsselt meinte ich wenn dann verschlüsselt auf der HDD Ebene.
 
@AlphaKaninchen
Die Sache mit zRAM kann man machen, wenn man generell sehr viel RAM hat.
Ich bin da in der VM etwas eingeschränkt, was den RAM angeht.

Swap ist generell nicht problematisch, wenn da nicht alle Nase lang etwas daraus gelesen oder geschrieben werden muss. HDD ist halt deutlich langsamer, als RAM.

Wobei Paperless bei mir, so geplant, nicht tagtäglich mit neuen Daten gefüttert wird.
Wenn ich später mal alte Dokumente einscannen werde, wird die Belastung deutlich höher sein.

Mich wundert hier nur die RAM-Nutzung von granian. Das die so hoch ist. obwohl nichts gemacht wird.
 
@DHC Ich sehe keinen Grund es bei kleinen Systemen nicht zu nutzen, ist halt einfach ein weiteres Level zwischen Unkomprimiert und Disk. (Sofern man nicht auf Disk komplett verzichtet, was bei zram im Gegensatz zu zswap möglich ist...)

Und mal eine weitere Frage in die Runde laut Arch Wiki werden seiten wenn sie vom zswap zum in disk swap verschoben werden dekomprimiert, warum werden sie nicht komprimiert abgelegt?

Und warum liegt dein Swap auf HDD? Das ist ja wohl das erste das auf eine SSD sollte.
 
Zuletzt bearbeitet:
wenn zwei fast identische Instanzen von VM oder anderen großen Prozessen im RAM laufen, wäre es möglich per Deduplikation den Speicher-Verbrauch massiv zu reduzieren.

In diesem Fall KSM oder UKSM und https://codeberg.org/pf-graveyard/uksmd

Der cachyos Kernel und/oder ein paar andere custom Kernel sollten das (uksm, modifiziertes KSM) an Bord haben.

Standard KSM sollte auch gehen, ist aber nicht so mächtig.

Eventuell kann /proc/sys/vm/vfs_cache_pressure noch auf 1000 oder höher eingestellt werden, damit das Host-System möglichst wenig an inodes, etc. im pagecache vorhält und somit mehr für die VM übrig bleibt.

Ein NAS System ist aber wahrlich nicht für sowas optimiert bzw. ideal

Dafür sind unter anderem die Guest Tools da. Das funkltioniert wie ein Ballon der mal größer oder kleiner wird.
aber podman kann das nicht, das ist ja der springende Punkt bzw. der Nachteil von dem genannten Setup
 
Sensei21 schrieb:
Dafür sind unter anderem die Guest Tools da. Das funktioniert wie ein Ballon der mal größer oder kleiner wird.
Guest Tools sind nicht aktiviert.
Im NAS ist da die Rede von Windows. Ich kann das ja mal aktivieren und schauen, was dann passiert.
Sensei21 schrieb:
aber podman kann das nicht, das ist ja der springende Punkt bzw. der Nachteil von dem genannten Setup
Das wusste ich nicht.
Man liest halt, das Podman besser sein sollte, als Docker. Vor allem, da rootless.

Wie schon gesagt.
Zur Not könnte ich mir noch einen Mini-PC (Erweiterbar) zulegen. Das wollte ich aber eigentlich vermeiden.

Vom Prinzip her tut ja bis jetzt alles.
Ich konnte "noch" keine Einschränkungen feststellen. Aber das kommt vielleicht noch.
 
Cool Master schrieb:
Jup, sehe ich selbst bei mir und 96 GB, dass der da auslagern will unter Win.
Dein Windows lagert halt immer das aus, was aktuell im Speicher gar nicht benötigt wird, damit Speicherengpässe erst gar nicht entstehen können. Linux wird das nicht anders machen und unbenötigte Speicherseiten auslagern, damit die aktiven Inhalte genug Speicher zur Verfügung haben.

In beiden Fällen gilt, dass Speicherseiten aus der Swap schneller in den Ram geholt sind, als diese Daten erst wieder aus dem Dateisystem zu holen. Eine gut ausgelastete Auslagerung ist deshalb eher ein Kennzeichen von Effektivität im Speichermanagement, als ein Manko, weil die Auslagerung nur dann zum Problem werden kann, wenn das System sie tatsächlich dazu nutzen muss um einen Speichermangel zu kompensieren.
 
  • Gefällt mir
Reaktionen: Ja_Ge und JumpingCat
DHC schrieb:
Guest Tools sind nicht aktiviert.
Korrektur. Die sind wohl schon aktiv. Die wurden wohl standardmäßig bei der Installation mit eingebunden.

Code:
@Paperless:~$ systemctl status qemu-guest-agent
● qemu-guest-agent.service - QEMU Guest Agent
     Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; static)
     Active: active (running) since Mon 2026-01-26 00:37:37 CET; 3min 30s ago
 Invocation: c90f57f33b6241f5af7ca192d8a907d4
   Main PID: 729 (qemu-ga)
      Tasks: 2 (limit: 9466)
     Memory: 2.6M (peak: 2.9M)
        CPU: 51ms
     CGroup: /system.slice/qemu-guest-agent.service
             └─729 /usr/sbin/qemu-ga

Warning: some journal files were not opened due to insufficient permissions.
Ohne laufenden Pod-Container sieht es aktuell wie folgt aus.
Code:
top - 00:44:18 up 10 min,  1 user,  load average: 0,00, 0,03, 0,01
Tasks: 123 total,   1 running, 122 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,0 us,  0,2 sy,  0,0 ni, 99,8 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   7947,8 total,   7586,1 free,    395,4 used,    192,2 buff/cache
MiB Swap:   2048,0 total,   2048,0 free,      0,0 used.   7552,5 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
    424 root      20   0   67056  28632  27360 S   0,0   0,4   0:00.34 systemd-journal
    961 root      20   0   95100  26548  22960 S   0,0   0,3   0:00.17 smbd
    949 root      20   0   87776  22224  18852 S   0,0   0,3   0:00.22 winbindd
    760 root      20   0  336872  19844  16880 S   0,0   0,2   0:00.14 NetworkManager
    842 root      20   0   82116  19012  16024 S   0,0   0,2   0:00.15 nmbd
    732 root      20   0  404960  17468  14764 S   0,0   0,2   0:00.15 udisksd
    954 root      20   0   88012  16136  12692 S   0,0   0,2   0:00.01 wb[PAPERLESS]
      1 root      20   0   23944  14568  10724 S   0,0   0,2   0:01.74 systemd
    969 root      20   0   20200  13032  11040 S   0,0   0,2   0:00.04 sshd-session
    782 root      20   0  317180  12568  10652 S   0,0   0,2   0:00.16 ModemManager
Cockpit gestartet
Code:
top - 01:06:42 up 33 min,  2 users,  load average: 0,02, 0,01, 0,00
Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,0 us,  0,3 sy,  0,0 ni, 99,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   7947,8 total,   7454,6 free,    446,1 used,    274,2 buff/cache
MiB Swap:   2048,0 total,   2048,0 free,      0,0 used.   7501,7 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   1423 root      20   0  417772  36572  19360 S   0,0   0,4   0:02.33 packagekitd
   1379 xxxxxxxx  20   0  267320  32876  12260 S   0,0   0,4   0:01.16 cockpit-bridge
   1395 root      20   0   44788  30704  12048 S   0,0   0,4   0:00.62 cockpit-bridge
    424 root      20   0   67056  29268  27952 S   0,0   0,4   0:00.38 systemd-journal
    961 root      20   0   95100  26548  22960 S   0,0   0,3   0:00.17 smbd
    949 root      20   0   87776  22312  18940 S   0,0   0,3   0:00.29 winbindd
    760 root      20   0  336872  19848  16880 S   0,0   0,2   0:00.15 NetworkManager
    842 root      20   0   82116  19012  16024 S   0,0   0,2   0:00.19 nmbd
    732 root      20   0  404960  17468  14764 S   0,0   0,2   0:00.21 udisksd
    954 root      20   0   88012  16144  12692 S   0,0   0,2   0:00.04 wb[PAPERLESS]
      1 root      20   0   24076  14768  10724 S   0,0   0,2   0:02.21 systemd
    969 root      20   0   20200  13032  11040 S   0,0   0,2   0:00.04 sshd-session
    782 root      20   0  317180  12568  10652 S   0,0   0,2   0:00.16 ModemManager
Eine Instanz von Paperless gestartet, die nicht so viel Ressourcen frisst.
Code:
top - 01:10:43 up 37 min,  2 users,  load average: 0,59, 0,50, 0,21
Tasks: 175 total,   1 running, 174 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,7 us,  0,8 sy,  0,0 ni, 98,2 id,  0,0 wa,  0,0 hi,  0,2 si,  0,2 st
MiB Spch:   7947,8 total,   6092,1 free,   1270,6 used,    847,9 buff/cache
MiB Swap:   2048,0 total,   2048,0 free,      0,0 used.   6677,2 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   2053 firma     20   0  444060 160952  31480 S   0,0   2,0   0:10.13 granian asginl
   2019 firma     20   0  348720 152596  33736 S   0,3   1,9   0:14.11 [celeryd: celer
   2109 firma     20   0  376456 152344   5232 S   0,0   1,9   0:00.36 [celeryd: celer
   2025 firma     20   0  346708 150608  33176 S   0,0   1,9   0:12.49 [celery beat] -
   2018 firma     20   0  260408 138340  31528 S   0,0   1,7   0:10.74 python3
   1908 35002     20   0 4672664 122888  25820 S   0,3   1,5   0:07.09 java
   1711 35002     20   0 4664488  88556  24932 S   0,3   1,1   0:03.09 java
   1476 root      20   0 2470724  66200  45300 S   0,7   0,8   0:02.05 podman
   1489 xxxxxxxx  20   0 1879644  52676  38804 S   0,3   0,6   0:00.80 exe
   1477 xxxxxxxx  20   0 1869948  47592  36352 S   0,0   0,6   0:00.14 podman
   2034 firma     20   0  136132  40036  12680 S   0,0   0,5   0:01.44 granian asginl
   1423 root      20   0  417772  36572  19360 S   0,0   0,4   0:02.34 packagekitd
   1379 xxxxxxxx  20   0  267784  33712  12260 S   0,0   0,4   0:02.04 cockpit-bridge
   1395 root      20   0  489252  33048  12064 S   0,0   0,4   0:02.02 cockpit-bridge
    424 root      20   0   67480  31828  30344 S   0,0   0,4   0:00.52 systemd-journal
Nun eine Instanz gestoppt und danach die andere Instanz gestartet.
Code:
top - 01:52:56 up  1:19,  2 users,  load average: 0,04, 0,22, 0,26
Tasks: 174 total,   1 running, 173 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,7 us,  0,5 sy,  0,0 ni, 98,5 id,  0,2 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Spch:   7947,8 total,   3828,3 free,   1263,1 used,   3133,3 buff/cache
MiB Swap:   2048,0 total,   2047,7 free,      0,3 used.   6684,8 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   3258 privat    20   0  437916 155556  28120 S   0,0   1,9   0:10.05 granian asginl
   3382 privat    20   0  375496 151436   5228 S   0,0   1,9   0:00.36 [celeryd: celer
   3224 privat    20   0  348720 148956  30092 S   0,3   1,8   0:15.12 [celeryd: celer
   3230 privat    20   0  347788 146312  28808 S   0,0   1,8   0:12.39 [celery beat] -
   3223 privat    20   0  334140 134508  27696 S   0,0   1,7   0:10.72 python3
   3138 35002     20   0 4672664 115804  24724 S   0,7   1,4   0:09.92 java
   2858 35002     20   0 4664488  87204  24244 S   0,7   1,1   0:05.83 java
   1476 root      20   0 2470724  68424  46064 S   1,0   0,8   0:22.06 podman
   1489 xxxxxxxx  20   0 1879644  52776  38860 S   0,3   0,6   0:12.45 exe
   1477 xxxxxxxx  20   0 1869948  47648  36352 S   0,0   0,6   0:00.25 podman
   3239 privat    20   0  136132  38280  10912 S   0,0   0,5   0:01.45 granian asginl
   1379 xxxxxxxx  20   0  268200  34592  12244 S   0,0   0,4   0:16.65 cockpit-bridge
    424 root      20   0   67480  33448  31920 S   0,0   0,4   0:00.89 systemd-journal
   1395 root      20   0  489252  33388  12048 S   0,0   0,4   0:21.13 cockpit-bridge

Was auffällt ist, dass buff/cache stärker in Anspruch genommen wird. Hat wahrscheinlich sein Gründe.
So wie es ausschaut, gibt es nur Probleme, wenn beide Instanzen gleichzeitig laufen.
Ich werde das weiter beobachten.

Nun laufen beide Instanzen gleichzeitig ohne das die Weboberfläche aufgerufen wurde.
Code:
top - 02:40:23 up  2:06,  1 user,  load average: 0,02, 0,05, 0,08
Tasks: 201 total,   2 running, 199 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,8 us,  0,5 sy,  0,0 ni, 98,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   7947,8 total,   2857,3 free,   1940,2 used,   3450,6 buff/cache
MiB Swap:   2048,0 total,   2047,7 free,      0,3 used.   6007,7 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   4362 firma     20   0  437740 158944  31204 S   0,0   2,0   0:10.01 granian asginl
   3258 privat    20   0  437916 155556  28120 S   0,0   1,9   0:10.05 granian asginl
   4531 firma     20   0  378596 153236   5112 S   0,0   1,9   0:00.37 [celeryd: celer
   4324 firma     20   0  348732 152156  33292 S   0,0   1,9   0:15.44 [celeryd: celer
   4331 firma     20   0  347956 151820  33028 S   0,0   1,9   0:12.38 [celery beat] -
   4530 privat    20   0  375512 151440   5264 S   0,0   1,9   0:00.37 [celeryd: celer
   3224 privat    20   0  348720 148960  30092 S   0,3   1,8   0:22.00 [celeryd: celer
   3230 privat    20   0  347788 147728  28808 S   0,0   1,8   0:12.49 [celery beat] -
   4325 firma     20   0  334140 139492  31768 S   0,0   1,7   0:10.74 python3
   3223 privat    20   0  334140 134508  27696 S   0,0   1,7   0:10.72 python3
   4181 35002     20   0 4672664 131836  25748 S   0,3   1,6   0:11.22 java
   3138 35002     20   0 4672664 120236  24724 S   0,3   1,5   0:24.99 java
   4000 35002     20   0 4664488  87676  24864 S   0,3   1,1   0:04.94 java
   2858 35002     20   0 4664488  87488  24244 S   0,3   1,1   0:19.70 java
   4339 firma     20   0  136132  40240  12836 S   0,0   0,5   0:01.47 granian asginl
   3239 privat    20   0  136132  38280  10912 S   0,0   0,5   0:01.45 granian asginl
    424 root      20   0   67612  34032  32464 S   0,0   0,4   0:01.21 systemd-journal
 
Zuletzt bearbeitet:
foofoobar schrieb:
Allein der Firefox nutzt swap wo immer er kann, pulseaudio funktioniert nicht ohne, viele Anwendungsprogramme nutzen swap.

Und meine Vermutung ist das die Swap Partition nur 2 GB groß ist.

Ich nutze daher gern eine Swap Datei die hat dann eine dynamische Größe.
 
  • Gefällt mir
Reaktionen: Ja_Ge
areiland schrieb:
Linux wird das nicht anders machen und unbenötigte Speicherseiten auslagern, damit die aktiven Inhalte genug Speicher zur Verfügung haben.
Naja. Es wird schon versucht auch alten Kram im RAM zu halten. Wobei das auch Sache der Konfiguration ist. Du hast bei Linux halt mehrere Möglichkeiten ins Verhalten einzugreifen, was Du bei Windows eher nicht hast. Schon allein daher ist der Vergleich mit Windows schwierig.

areiland schrieb:
Eine gut ausgelastete Auslagerung ist deshalb eher ein Kennzeichen von Effektivität im Speichermanagement, als ein Manko
Naja. Kommt drauf an. Denn ausgelagerte Pages sind natürlich bei Zugriff immer langsamer als in-RAM-Pages.
Wenn man also vorsorglich auslagert mit etwaige neue Speicheranforderung schnell erfüllen zu können, dann bringt das halt nur was wenn diese neuen Speicheranforderungen tatsächlich kommen. Ansonsten sind sie eher nachteilig.

Und dann spielen natürlich noch andere Sachen rein. In der Regel hat man ja auch sowas wie Cache. Auch der belegt RAM aber der muss eben nicht zwingend sein. Den kannst Du auch mal ausdrücken, ohne Swap zu belasten aber auch das geht natürlich (je nach Anforderung) auf die Performance.

Wie so häufig gilt halt, das man pauschale Aussagen eben nicht so treffen kann, sondern es immer ein "kommt drauf an" ist.
 
andy_m4 schrieb:
Naja. Kommt drauf an. Denn ausgelagerte Pages sind natürlich bei Zugriff immer langsamer als in-RAM-Pages.
Wenn man also vorsorglich auslagert mit etwaige neue Speicheranforderung schnell erfüllen zu können, dann bringt das halt nur was wenn diese neuen Speicheranforderungen tatsächlich kommen. Ansonsten sind sie eher nachteilig.
Dadurch wird Platz für Plattencache frei, und wenn eine Page "ewig" nicht angefasst wurde kann man das für anderes nutzen.
 
@foofoobar Ja. Das steckte aber alles in meinem Posting mit drin.

Insofern bin ich mir jetzt unsicher, ob Du mir widersprechen wolltest oder einen einzelnen Punkt klarer rausstellen.
 
Im Regelfall hat man nur ein Problem wenn pro Zeiteinheit "viel" geswappt wird.
Das kann man sich mit "sar -W 5" anschauen.
 
foofoobar schrieb:
Im Regelfall hat man nur ein Problem wenn pro Zeiteinheit "viel" geswappt wird.
Vielleicht solltest Du Dich ausführlicher äußern. Nur einzelne Sätze fallen zu lassen, trägt nicht gerade zur Verständnis bei.
Insbesondere da ja mein Posting eine implizite Frage enthielt. Da machts ja erst mal Sinn darauf einzugehen, bevor man sich weitergehend äußert.
 
foofoobar schrieb:
Im Regelfall hat man nur ein Problem wenn pro Zeiteinheit "viel" geswappt wird.

Das war doch schon ein Thema auf Seite 1 hier im Thread. Du holst das jetzt auf Seite 3 wieder hoch weil?
Ergänzung ()

Linuxfreakgraz schrieb:
Allein der Firefox nutzt swap wo immer er kann, pulseaudio funktioniert nicht ohne, viele Anwendungsprogramme nutzen swap.

Das Thema hatten wir auch schon. Da war es angeblich Legacy Software die explizit die Festplatte anstatt RAM nutzt. Hast du Details dazu?!
 
Zuletzt bearbeitet:
Boah das liegt so lange zurück bei meinem Beobachtungen, ich kann dir nichtmal eine Jahreszahl nennen.
 
JumpingCat schrieb:
Das war doch schon ein Thema auf Seite 1 hier im Thread. Du holst das jetzt auf Seite 3 wieder hoch weil?
Um zu posten wie man das abfragen kann.
 
Also @DHC dann will ich mal versuchen etwas Licht reinzubringen.😉

Wenn dir Debian bei der Installation nur eine 2GB Swap macht, dann hast du der VM wahrscheinlich auch nur 2GB Ram zugestanden, den Debian versucht Standardmäßig immer ein Swap in Größe des Ram zu erstellen.

Das ist eindeutig zu wenig, wenn du dann auch noch Container in Debian nutzen willst.
Das verursacht IMO die max. Nutzung des Swap!

Weise der VM mal mehr Ram zu, und schaue ob er dann immer noch so stark auslagert.

Ich nutze schon seit ich 32GB Ram nutze kein Swap mehr (auch schon seit gut 10 Jahren!), und habe keine Probleme.

Der Grund warum mein System jetzt 96GB hat waren meine Experimente mit LLMs (KI), um sicher zu gehen das die genügen Ram haben! (Ja ich weis das LLMs hauptsachlich VRam nutzen.)
Und 96GB war halt das max. was das System verwalten kann.😏

Ich hoffe das hilft ein bisschen beim Verständnis der Linux Swap.😊
 
Zurück
Oben