Linux-Kernel Swap-Management (Relikte aufsammeln)

[CyborgBeta]

Hi, ich habe einen Prozess, den in periodisch ausführe (einmal am Tag), und der ziemlich viel Speicher braucht. Zur Verfügung stehen 4gb + 4gb Swap-Speicher. Wenn dieser Prozess ausgeführt wird, muss also viel geswappt werden.

Gibt es eine Möglichkeit, nachdem der Prozess fertig ist, den Swap "zurückzuholen", also in das Swap-Management/Paging Einfluss zu nehmen?

Folgende Möglichkeit habe ich gefunden: sudo swapoff -a; sudo swapon -a https://askubuntu.com/questions/1357/how-to-empty-swap-if-there-is-free-ram

und das funktioniert auch, wie ich vorhin kurz getestet hatte ... Aber gibt es eine andere Möglichkeit, als den Swap vorübergehend komplett zu deaktivieren? Also, so eine Art "empty", "free", "clear" oder "flush" Command?

 

[Marco01_809]

Gibt es denn irgendein Problem damit dass der Kernel die geswappten Pages erst wieder reinlädt wenn sie gebraucht werden? Liegt der Swap noch auf einer HDD?

In der Praxis haben die meisten Prozesse einigen Speicher auf den quasi nie zugegriffen wird, so dass der permanent geswapped bleiben kann. Den lohnt es gar nicht wieder reinzuladen vor der nächsten Ausführung deines Tasks, sorgt nur dafür dass du jedes mal unnütze Schreibzugriffe durch das erneute Swapping hast.

 

[Krik]

Gibt es eine Möglichkeit, nachdem der Prozess fertig ist, den Swap "zurückzuholen"

Wozu? Das macht doch das System bei Bedarf von alleine.

 

[Methylherd]

Vielleicht kannst du ja eine Swap Datei nutzen., die kann sogar gelöscht werden wenn sie nicht aktiv ist. Den Sinn verstehe ich zwar nicht aber das Arch & Gentoo Wiki sind für solche Infos immer top:
Archwiki zu Swap

 

[oicfar]

Gibt es eine Möglichkeit, nachdem der Prozess fertig ist, den Swap "zurückzuholen", also in das Swap-Management/Paging Einfluss zu nehmen?

Wieso willst du das machen?

Beendet sich das Program ach dem dem Lauf? Wenn ja, dann wird der SWAP wieder freigegeben.

Hast du irgendwelche Nachteile wg. dem Swapping?

 

[konkretor]

Du kannst versuchen den Kernel etwas Beine machen

echo 100 | sudo tee /proc/sys/vm/swappiness

Danach wieder zurück stellen
echo 60 | sudo tee /proc/sys/vm/swappiness

Oder mal versuchen den Cache dropen
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

drop_caches

Writing to this will cause the kernel to drop clean caches, as well as
reclaimable slab objects like dentries and inodes. Once dropped, their
memory becomes free.

To free pagecache:
echo 1 > /proc/sys/vm/drop_caches
To free reclaimable slab objects (includes dentries and inodes):
echo 2 > /proc/sys/vm/drop_caches
To free slab objects and pagecache:
echo 3 > /proc/sys/vm/drop_caches

This is a non-destructive operation and will not free any dirty objects.
To increase the number of objects freed by this operation, the user may run
`sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the
number of dirty objects on the system and create more candidates to be
dropped.

This file is not a means to control the growth of the various kernel caches
(inodes, dentries, pagecache, etc...) These objects are automatically
reclaimed by the kernel when memory is needed elsewhere on the system.

Use of this file can cause performance problems. Since it discards cached
objects, it may cost a significant amount of I/O and CPU to recreate the
dropped objects, especially if they were under heavy use. Because of this,
use outside of a testing or debugging environment is not recommended.

You may see informational messages in your kernel log when this file is
used:

cat (1234): drop_caches: 3

These are informational only. They do not mean that anything is wrong
with your system. To disable them, echo 4 (bit 2) into drop_caches.

 

[oicfar]

Ist aber ungewöhnlich, dass dein SWAP = RAM ist.

Ergänzung (8. Oktober 2024)

Oder mal versuchen den Cache dropen
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Meinst du das?

https://linux-mm.org/Drop_Caches

Ergänzung (8. Oktober 2024)

Also, dass SWAP benutzt wird, ist nicht schlimm. Linux macht es aus einem bestimmten Grund.

Ergänzung (8. Oktober 2024)

Du kannst versuchen den Kernel etwas Beine machen

echo 100 | sudo tee /proc/sys/vm/swappiness

Je höher der Wert desto eher wird geswappt.

Mein Mini-Server hat 32GB RAM und 6GB SWAP. Und trotz vm.swappiness = 5 wird nach 1-2 Tagen geswapt.

$ mem
               total        used        free      shared  buff/cache   available
Mem:           31713        2968         495        1120       28249       27459
Low:           31713       31218         495
High:              0           0           0
Swap:           6143        1247        4896
Total:         37857        4215        5392

Ergänzung (8. Oktober 2024)

@CyborgBeta dein aktuelles Setup macht das ganze Linux Caching unbrauchbar. So ein Aufbau des Cachings kann schon 1-2 Tage dauern. Und wenn dein Prozess jeden Tag den ganzen RAM und auch SWAP sich nimmt, dann würde ich überlegen mal mehr RAM einzubauen. Und wenn das nicht geht, entweder andres System oder sich eine andere Lösung überlegen.

Interessant wäre, was das für ein Prozess ist, der sich 8GB nimmt. Und welche Hardware hast du? Und dein SWAP muss sicher > 4 GB groß sein. Macht irgendwie kein Sinn.

 

[nutrix]

Swapping ist immer ungünstig für die Performance und sollte an sich für kritische Anwendungen vermieden werden. Sobald so viel wie bei Dir über den gesamten Bereich ausgelagert wird wie blöde, sollte unbedingt erst nach mehr RAM dazugegeben werden. Kannst mehr über den konkreten Anwendungsfall verraten?

 

[JumpingCat]

Ich werfe noch zswap in die Runde.

Ansonsten halt erst drop caches und dann swapoff & swapon. Ist aber nicht so förderlich für alles was danach läuft.

 

[Methylherd]

Ich werfe noch zswap in die Runde.

Falls mehr RAM keine Option ist, eine mögliche Lösung. Interessant wäre um welche Hardware es sich handelt. Mit 4GB RAM vermutlich eher was mit begrenzter CPU Power und weniger Features in Hardware um die Kompression zu erledigen.

Je nach Anwendungsszenario könnte auch mit zram der Speicherverbrauch gesenkt werden. Nutz ich unter Gentoo gerne für diverse Dinge, aber vorwiegend um "lahme" SSD Zugriffe zu vermeiden. RAM Menge ist da selten mein Problem.

 

[CyborgBeta]

@CyborgBeta dein aktuelles Setup macht das ganze Linux Caching unbrauchbar. So ein Aufbau des Cachings kann schon 1-2 Tage dauern. Und wenn dein Prozess jeden Tag den ganzen RAM und auch SWAP sich nimmt, dann würde ich überlegen mal mehr RAM einzubauen. Und wenn das nicht geht, entweder andres System oder sich eine andere Lösung überlegen.

Interessant wäre, was das für ein Prozess ist, der sich 8GB nimmt. Und welche Hardware hast du? Und dein SWAP muss sicher > 4 GB groß sein. Macht irgendwie kein Sinn.

Ne ne, der Prozess, der kurz einmal pro Tag läuft, braucht ungefähr 2gb RAM. Da ungefähr 2gb schon vom System und anderen Prozessen belegt sind, wird der Swap aktiv ... und irgendwie bleiben dann 23,9 Stunden lang (ungefähr) Swap-Reste übrig. Das ist doch nicht sinnvoll?

 

[Krik]

Wenn die Daten nicht aus dem Swap geholt werden, werden sie nicht gebraucht. Im RAM wären sie den aktiven Programmdaten im Weg. Sie liegen da, wo sie sind, richtig.

Und sollte der Swap-Space gebraucht werden, wirft Linux irgendwann die alten, nicht mehr benötigten Daten eh von alleine raus, um Platz zu schaffen. Du als User musst da gar nicht eingreifen.

 

[CyborgBeta]

Du kannst versuchen den Kernel etwas Beine machen

echo 100 | sudo tee /proc/sys/vm/swappiness

Danach wieder zurück stellen
echo 60 | sudo tee /proc/sys/vm/swappiness

Oder mal versuchen den Cache dropen
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Hier auch eine Diskussion dazu: https://askubuntu.com/questions/103915/how-do-i-configure-swappiness

Meine Swappiness ist momentan 60:

cat /proc/sys/vm/swappiness -> 60

Diese kann ich zum "Swap out" vorübergehend auf 100 setzen:

sudo sysctl vm.swappiness=100

Das würde aber auch nicht zu einem sofortigen und vollständigen "Swap out" führen, da das nur so etwas wie ein Richtwert darstellt. Aber es wäre zumindest mal ein Versuch wert.

Wichtig noch: Das Ganze ist aber nicht Reboot-persistent, was es aber auch nicht sein muss für meinen Anwendungsfall ...

Wenn die Daten nicht aus dem Swap geholt werden, werden sie nicht gebraucht. Im RAM wären sie den aktiven Programmdaten im Weg. Sie liegen da, wo sie sind, richtig.

Vor der besagten Prozessausführung war der Swap aber auch so gut wie leer. Also kann das schon Sinn machen.

Ergänzung (9. Oktober 2024)

hm, sudo sysctl vm.swappiness=100 bewirkt, dass aggressiv geswappt wird (also der Swap verwendet wird)

und sudo sysctl vm.swappiness=1 bewirkt, dass der Swap möglichst gar nicht genutzt wird.

Das Setzen auf 1, bevor der Prozess gestartet wird, könnte also sinnvoll sein. Kurze Zeit später kann der Wert wieder auf 60 gesetzt werden.

 

[oicfar]

Wie schon oben geschrieben. Der eine Prozess macht am Ende das ganze buff/cache kaputt. Auch wenn du den SWAP versuchst zu manipulieren, macht es nicht besser.

Die Frage wurde schon oben gestellt. Hast du wg. dem SWAPPing irgendwelche "Probleme"? Merkst du was? Dass du das so wie du geschrieben hast, machen willst?

 

[CyborgBeta]

Gibt es denn irgendein Problem damit dass der Kernel die geswappten Pages erst wieder reinlädt wenn sie gebraucht werden? Liegt der Swap noch auf einer HDD?

Es geht um clamscan -r <...>, das ich periodisch ausführe und das sehr "ressourcenhungrig" ist.

HDD nicht, schon (M.2) SSD vermute ich.

Das Problem ist, dass das System denkt, dass clamscan in absehbarer Zeit wieder ausgeführt wird, und so den anderen Prozessen den Swap "aufzwingt". Was aber natürlich ein Irrtum ist.

Deshalb möchte ich "manuell eingreifen". ... Geschwindigkeitsnachteile konnte ich aber bislang gar nicht feststellen.

 

[Uridium]

Man könnte schauen, ob ein deaktivieren des Memory 'overcommit' in diesem Fall hilfreich ist. Zumindest sollte das Swapping dadurch reduziert werden.

sysctl:

vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.page-cluster = 0

 

[JumpingCat]

Aus Erfahrung zu clamav: Die hohe RAM Auslastung kommt durch die Signaturen zustande. Hast du hier eine Auswahl getroffen oder scannst du auf alles was möglich ist?

 

[CyborgBeta]

Hast du hier eine Auswahl getroffen oder scannst du auf alles was möglich ist?

Ich scanne auf alles ...

 

[JumpingCat]

@CyborgBeta Das heißt auch mit allen unoffical?

https://www.google.com/search?q=clamav+unofficial

Darf man fragen was für einen Use Case du hast wenn du auf alles scannst?

 

[CyborgBeta]

Ja, darfst fragen. Ich sichere alle (Medien-)Dateien von meinem Smartphone auf dem Server (.jpg, .mp4, .zip usw.), und nach dem Upload möchte ich schauen, ob die alle ok sind. Bisher wurde nix gefunden.

Zudem läuft da noch ein Mailserver (wobei ich aber nicht weiß, wie schlau rspamd schon ist, ggf. ist da eine manuelle Prüfung redundant).

Ergänzung (9. Oktober 2024)

Das heißt auch mit allen unoffical?

Ne, sieht nicht danach aus ...

$ clamscan --debug 2>&1 /dev/null | grep -v "not loaded" | grep "loaded"
LibClamAV debug: daily.info loaded
LibClamAV debug: daily.cfg loaded
LibClamAV debug: daily.fp loaded
LibClamAV debug: daily.cdb loaded
LibClamAV debug: daily.ign loaded
LibClamAV debug: daily.msb loaded
LibClamAV debug: daily.sfp loaded
LibClamAV debug: daily.pdb loaded
LibClamAV debug: daily.ftm loaded
LibClamAV debug: daily.ndb loaded
LibClamAV debug: daily.wdb loaded
LibClamAV debug: daily.idb loaded
LibClamAV debug: daily.ign2 loaded
LibClamAV debug: daily.mdb loaded
LibClamAV debug: daily.hsb loaded
LibClamAV debug: daily.ldb loaded
LibClamAV debug: daily.crb loaded
LibClamAV debug: daily.hdb loaded
LibClamAV debug: /var/lib/clamav/daily.cld loaded
LibClamAV debug: bytecode.info loaded
LibClamAV debug: 3986187.cbc loaded
LibClamAV debug: 3986188.cbc loaded
LibClamAV debug: 3986206.cbc loaded
LibClamAV debug: 3986212.cbc loaded
LibClamAV debug: 3986214.cbc loaded
LibClamAV debug: 3986215.cbc loaded
LibClamAV debug: 3986216.cbc loaded
LibClamAV debug: 3986217.cbc loaded
LibClamAV debug: 3986218.cbc loaded
LibClamAV debug: 3986219.cbc loaded
LibClamAV debug: 3986220.cbc loaded
LibClamAV debug: 3986221.cbc loaded
LibClamAV debug: 3986222.cbc loaded
LibClamAV debug: 3986223.cbc loaded
LibClamAV debug: 3986224.cbc loaded
LibClamAV debug: 3986229.cbc loaded
LibClamAV debug: 3986230.cbc loaded
LibClamAV debug: 3986231.cbc loaded
LibClamAV debug: 3986232.cbc loaded
LibClamAV debug: 3986233.cbc loaded
LibClamAV debug: 3986234.cbc loaded
LibClamAV debug: 3986235.cbc loaded
LibClamAV debug: 3986236.cbc loaded
LibClamAV debug: 3986242.cbc loaded
LibClamAV debug: 3986244.cbc loaded
LibClamAV debug: 3986249.cbc loaded
LibClamAV debug: 3986259.cbc loaded
LibClamAV debug: 3986282.cbc loaded
LibClamAV debug: 3986283.cbc loaded
LibClamAV debug: 3986289.cbc loaded
LibClamAV debug: 3986292.cbc loaded
LibClamAV debug: 3986301.cbc loaded
LibClamAV debug: 3986303.cbc loaded
LibClamAV debug: 3986305.cbc loaded
LibClamAV debug: 3986306.cbc loaded
LibClamAV debug: 3986310.cbc loaded
LibClamAV debug: 3986321.cbc loaded
LibClamAV debug: 3986322.cbc loaded
LibClamAV debug: 3986327.cbc loaded
LibClamAV debug: 3986328.cbc loaded
LibClamAV debug: 3986334.cbc loaded
LibClamAV debug: 3986337.cbc loaded
LibClamAV debug: 4306126.cbc loaded
LibClamAV debug: 4306157.cbc loaded
LibClamAV debug: 4307467.cbc loaded
LibClamAV debug: 4510302.cbc loaded
LibClamAV debug: 4526683.cbc loaded
LibClamAV debug: 4553522.cbc loaded
LibClamAV debug: 4970075.cbc loaded
LibClamAV debug: 5044126.cbc loaded
LibClamAV debug: 5588995.cbc loaded
LibClamAV debug: 5819336.cbc loaded
LibClamAV debug: 5999914.cbc loaded
LibClamAV debug: 5999936.cbc loaded
LibClamAV debug: 6300337.cbc loaded
LibClamAV debug: 6311970.cbc loaded
LibClamAV debug: 6316126.cbc loaded
LibClamAV debug: 6324281.cbc loaded
LibClamAV debug: 6327695.cbc loaded
LibClamAV debug: 6329916.cbc loaded
LibClamAV debug: 6329917.cbc loaded
LibClamAV debug: 6335400.cbc loaded
LibClamAV debug: 6335427.cbc loaded
LibClamAV debug: 6335560.cbc loaded
LibClamAV debug: 6335564.cbc loaded
LibClamAV debug: 6336023.cbc loaded
LibClamAV debug: 6336035.cbc loaded
LibClamAV debug: 6336074.cbc loaded
LibClamAV debug: 6336259.cbc loaded
LibClamAV debug: 6336260.cbc loaded
LibClamAV debug: 6336630.cbc loaded
LibClamAV debug: 6336737.cbc loaded
LibClamAV debug: 6336739.cbc loaded
LibClamAV debug: 6380163.cbc loaded
LibClamAV debug: 6395243.cbc loaded
LibClamAV debug: 6399052.cbc loaded
LibClamAV debug: 6428210.cbc loaded
LibClamAV debug: 6428556.cbc loaded
LibClamAV debug: 6441308.cbc loaded
LibClamAV debug: 6442366.cbc loaded
LibClamAV debug: 6447941.cbc loaded
LibClamAV debug: 6497366.cbc loaded
LibClamAV debug: 6539706.cbc loaded
LibClamAV debug: 6566834.cbc loaded
LibClamAV debug: 6614848.cbc loaded
LibClamAV debug: 6645239.cbc loaded
LibClamAV debug: 6646491.cbc loaded
LibClamAV debug: 6754169.cbc loaded
LibClamAV debug: 6754171.cbc loaded
LibClamAV debug: 7001009.cbc loaded
LibClamAV debug: 7086472.cbc loaded
LibClamAV debug: /var/lib/clamav/bytecode.cvd loaded
LibClamAV debug: main.info loaded
LibClamAV debug: main.hdb loaded
LibClamAV debug: main.hsb loaded
LibClamAV debug: main.mdb loaded
LibClamAV debug: main.msb loaded
LibClamAV debug: main.ndb loaded
LibClamAV debug: main.ldb loaded
LibClamAV debug: main.fp loaded
LibClamAV debug: main.sfp loaded
LibClamAV debug: main.crb loaded
LibClamAV debug: main.cdb loaded
LibClamAV debug: /var/lib/clamav/main.cvd loaded