Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Jut, bei solchen Sachen wie auch bei dem Debian List Thema geht's prinzipiell um ein Problem, welches man versucht zu lösen. Und für ein Problem gibt es oft mehrere Lösungen. Diese kann man in die Runde werfen.
Du möchtest hier den anderen Weg gehen. Viel Glück dabei. Ich konnte mich in den letzten ~40 Minuten on ClaimAV und RAM ein wenig einlesen und fand die diversen Beiträge interessant. Selbst nutze ich es nicht und habe auch nicht vor.
Ich bleibe dabei, was ich unter #7 geschrieben habe. Dein Ansatz wird dir keinen Vorteil bringen, wenn du den SWAP wieder zurück setzen wirst.
Ich denke, das Problem wurde nun hinreichend beschrieben, und Lösungsansätze gibt es auch (swappiness ändern z. B. (obwohl das keine Garantien gibt) oder den Swap zwischenzeitlich deaktivieren)... Insofern verstehe ich den vorhergehenden Beitrag nicht ganz, außer, dass er die Beitragszahl erhöht.
Lösungsansätze würde ja implizieren dass es ein Problem gibt... das scheint mir aber nicht der Fall zu sein? Für mich fällt das unter Schönheitsoperation weil die einzige Motivation ist dass du nicht willst das bei Swap ne Zahl größer als 0M steht.
Die Daten die clamscan von der Disk liest gehen durch den VFS Cache. Der Cache konkurriert mit den Prozessen um den RAM. Mit swappiness und vfs_cache_pressure kann man tunen ob Linux eher dateien aus dem cache schmeißen oder prozesse swappen soll. Man kann die Balance jetzt in die eine oder andere Richtung verschieben aber funktionieren tut es ohnehin.
Nur was überhaupt kein Sinn macht ist es Speicherseiten die gar nicht benutzt werden wieder in den RAM zu laden obwohl sie nächste Nacht wieder auf die SSD geswapped werden müssen und dabei immer und immer wieder Schreibzugriffe verursachen und die SSD abnutzen.
Swap ist imo immer ne Notlösung für Außnahmesituationen mit hohem Speicherbedarf. Sinnig ist es nur dem System genug RAM für alle seine tagtäglichen Vorgänge zu geben.
Nein, innerhalb von 23:59:59 Stunden lang (von mir aus auch nur 23:59:55 Stunden ...) den Swap nicht zurückzuholen ist eine Ausnahmesituation und falsch, meiner Ansicht nach (sozusagen ein Pivot oder Peak). Hier wäre ein manuelles Eingreifen in das Swap-Management sinnvoll, das nicht so vorausschauend sein kann, da es auch auf Annahmen beruht.
Wenn ClamAV nicht ausgeführt werden würde, dann würde der Cache/Swap ja auch nicht verwendet werden.
Und falls zwischendurch gerebootet werden muss, entstehen ohnehin Lese- und Schreibzugriffe.
Nein, ist es nicht. Mit steigender Uptime werden auch mehr Prozesse gecached. Und dafür wird auch der Swap verwendet. Das ist eine ganz normale Strategie.
Eine Ausnahmesituation liegt dann vor, wenn beim Starten eines Programmes auf einmal der kswapd anfängt, den Speicher immer zwischen RAM und Swap hin- und herzuschaufeln. Dann hat entweder der Programm einen Memory Leak, oder der RAM ist zu wenig.
Die erste Antwort mit mlockall wird Dir wenig bringen. Dazu müsstest du einen Wrapper in C schreiben, der halt dann Clam-AV starten, wobei das nicht auf Child-Prozesse vererbt wird.
Das Ganze kannst du in eine Systemd-Unit packen, z.B. clam-av@.service, bei dem du dann sogar die Cgroup als Variable übergeben kannst. (z.B. systemctl start clam-av@noswap mit CGroup noswap)
WARUM denn? Wenn Daten für 24h im Swap liegen bleiben ist das der Beweis dass auf diese Daten kein einziges mal zugriffen wurde. Also macht es keinen Unterschied ob sie im Swap, im RAM oder auf dem Mond sind. Bei schon einem einzigen Zugriff auf eine geswappte Seite MUSS Linux die Seite in den RAM zurückholen ("Seitenfehler" bzw "page fault"). Das geht mit der Architektur unserer Computer gar nicht anders.
Linux macht kein swap reclaiming auf Verdacht weil das eben einfach Schwachsinn ist. Wenn die Seiten eh schon geswapped sind ist es für die Performance viel besser den freien RAM für den VFS Cache zu benutzen als ihn mit Seiten zu füllen die gar nicht benutzt werden! Größerer VFS Cache spart Disk Zugriffe. Swap reclaiming verursacht Disk Zugriffe obwohl man gar nicht weiß ob die Daten gebraucht werden.
Das memory management von Linux hat sich nicht mal jemand eben so an einem verregneten Dienstnachmittag ausgedacht. Das wird seit über 40 Jahren auf allen unixoiden so gemacht. Die Strategie von Linux minimiert Disk Zugriffe um die Leistung des Systems zu erhalten. So gut es eben geht. Das man überhaupt Swap braucht ist natürlich immer schlechter als genug RAM zu haben. Logisch, RAM ist immer noch viel schneller als die schnellste SSD. Aber Linux wurde über 3 Jahrzehnte optimiert um in einer Situation mit zu wenig RAM die bestmögliche Leistung zu erhalten.
Hier wäre ein manuelles Eingreifen in das Swap-Management sinnvoll
Wenn du keinen Swap willst dann mach den Swap aus und gib dem System genug RAM.
Pummeluff schrieb:
Nein, ist es nicht. Mit steigender Uptime werden auch mehr Prozesse gecached. Und dafür wird auch der Swap verwendet. Das ist eine ganz normale Strategie.
Darauf wollte ich mit dem VFS Cache in meinem letzten und diesem Post etwas eingehen. Langfristig ist es sinnvoll mehr vom RAM als Cache nutzen zu können als ungenutzte Seiten von Prozessen drin zu haben.
Dafür benutze ich heutzutage aber nur noch zram (mit sehr hoher swappiness), swapping auf disks halte ich für eine Notsituation. Halte aber die 4GB RAM vom OP für zu wenig für zram.
The following minimum recommended system requirements are for using ClamScan or ClamD applications with the standard ClamAV signature database provided by Cisco.
Minimum recommended RAM for ClamAV:
FreeBSD and Linux server edition: 3 GiB+
Linux non-server edition: 3 GiB+
Windows 7 & 10 32-bit: 3 GiB+
Windows 7 & 10 64-bit: 3 GiB+
macOS: 3 GiB+
D.h. unpassende Hardware für das was insgesamt darauf läuft.
Wenn was geswappt wird, was nichts schlimmes ist und man keine Probleme hat -> ignorieren.
Hat man ein Problem mit dem Swapping, dann Hardware mit deutlich mehr RAM hinstellen und SWAP ausschalten.
Mein Mini-Server auf #7 hat 32GB RAM und 6 GB Swap. die größte Anwendung, die darauf läuft ist PostgreSQL (~6GB groß) und ich habe dem Prozess schon viel RAM zugewiesen. Nach 1-2 Tagen ist SWAP zu 10-20% gefüllt und wächst dann langsam. Und ich habe keine Performance Probleme.
Ergänzung ()
Und wenn ich die Tage 1-2h Zeit übrig habe, setze ich bei mir eine VM mit 4GB RAM (mit/ohne swap) auf und schaue es mir genauen an, wie viel RAM da wirklich benötigt wird und wie das Verhalten sein wird.
Habe Ubuntu 24.0.4.1 Server in einer VM unter Proxmox aufgesetzt. Und dann ClamAV 1.0.7 LTS installiert. Ansonsten keine weiteren Tools. Ich will ClainAV auch nicht in einer VM bei mir aufsetzen, wo ich einige Tools am Laufen habe. Habe der VM 2 Cores, 4 GB RAM und 2 GB Swap gegeben. Ich habe es mehrfach laufen lassen und dabei verschiedene Dateien zum Testen hinzugefügt. Ich wollte hier keine NFS Freigabe mounten.
Beim Scan:
Hier schwankt die RAM-Nutzung.
Halt durch das Lesen steigt buff/cache:
Nach dem Lauf sah es so
aus.
ClamAV lief ohne Probleme in einer VM mit 2GB RAM und 2GB Swap.
und verstehen, wieso es gemacht wird. Wurde schon darauf hingewiesen.
Ich sehe aber nicht, dass bei mir claimscan sich ~4 GB RAM nimmt. Die größte Dateien waren ~500MB groß.
Ja, ClamAV muss auf einer Hardware laufen, die 4+ GB RAM hat. bedeutet aber auf der anderen Seite, dass die anderen Tools, die darauf laufen, Platz machen müssen. Ist erstmal nicht schlimm. Ansonsten müsste man ein wenig Zeit reinstecken, um hier ein wenig was zu optimieren. Aber das würde ich nur machen, wenn ich merkliche Probleme habe nachdem ClamAV gelaufen ist.
Vielleicht hab ich mich vorher nicht eindeutig ausgedrückt ...
Es stehen 4GB RAM und 4GB Swap auf dem Server insgesamt zur Verfügung. Jedoch sind 2GB RAM schon vor und während der Scan-Ausführung durch Docker-Container belegt. Deshalb wird dann der Swap so stark beansprucht.
Bei Swappiness 60 und erneuter Ausführung von clamscan -r <...> (der Swap ist also schon belegt):
Du hast dich schon korrekt ausgedrückt. Ich hab's falsch geschrieben.
Wenn der Scan vorbei ist und du was an dem System machst, lass mal daneben in der Console sudo vmstat -w 1 laufen lassen. Und beochte hin und wieder swasp (si/so). Wenn na vorwiegend 0 zu sehen sein sollte, dann passt alles. wenn aber häufig > 0 steht (dazu noch höhere Werte), dann wird aus dem Swap gelesen oder geschrieben.
@oicfar : Gute Erklärung. Der wichtige Parameter ist swap in und swap out zu betrachten. Solange die beiden bei Null bleiben ist alles ok. Die kann man auch mit ins Monitoring nehmen. Früher war das alles schlimmer, da hatte man nur eine lahme IDE Platte. Heute sind das entweder SSD oder sogar RAID. Da hat keine spürbare Verzögerung mehr.
Idee:
Pack einfach mehr RAM rein und gut ist. Ich habe das früher auch gemacht, optimieren wo es geht. Aber wenn das Problem mit mehr RAM sehr günstig zu lösen ist, dann mache es so.
Hint: Mehr RAM wird dein Problem nicht lösen. Wenn ich bei mir so schaue:
Code:
user@host:~$ w
21:19:44 up 20 days, 3:01, 6 users, load average: 0.12, 0.11, 0.15
[...]
user@host:~$ free -m
total used free shared buff/cache available
Mem: 63891 27844 3534 544 33942 36046
Swap: 8191 4510 3681
Anbei noch das Skript (nicht von mir) mit dem man sehen kann, was im Swap ausgelagert wurde. Bitte das Skript nach .sh umbenennen und dann mit sudo ./swap_usage.sh ausführen. Zuvor aber noch chmod 755 swap_usage.sh .
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?
Doch, das ist extrem sinnvoll weil RAM was lange nicht angefasst wird nicht den schnellen Teil vom virtuellen Speicher belegt und der schnelle Teil besser genutzt werden kann.
Lasst mal "sar -SWr 5" laufen wenn dieser Prozess läuft.
Ergänzung ()
nutrix schrieb:
Wie einige hier richtig sagen, wenns swappt, mehr RAM dazu.
@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.
Nein, weil es Situationen geben kann wo schneller Speicher benötigt wird als durch swappen bereitgestellt wird, vereinfacht gesagt.
swappiness < 5 sollte man vermeiden.
Ergänzung ()
CyborgBeta schrieb:
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.
Ich habe es in meinem Kommentar nicht im Detail geschrieben, was ich genau meine. Das Problem, was ich da sehe ist, dass clamav in diesem Fall 1x am Tag läuft und prüft neue Dateien. D.h., dass was nach dem Lauf in buff/cache (sieht man bei free) nach dem Lauf steht, wird dann eher nicht wieder genutzt werden. Also macht man sich mit dem einen Lauf am Tag den buff/cache "kaputt". Ich weiß auch nicht, was alles auf dem Server noch läuft. Ich gehe aber davon aus, dass es da keine Performance-Probleme gibt.
Hier
ein Auszug aus meinem Mini-Server (4 Cores, 32GB RAM, 6GB Swap). Man sieht, dass nur 1,7GB RAM in Nutzung sind. Aber fast 29GB ist buff/cache. Und das was drauf läuft, läuft flüssig.
Ich denke, das Problem wurde nun hinreichend beschrieben, und Lösungsansätze gibt es auch (swappiness ändern z. B. (obwohl das keine Garantien gibt) oder den Swap zwischenzeitlich deaktivieren)... Insofern verstehe ich den vorhergehenden Beitrag nicht ganz, außer, dass er die Beitragszahl erhöht.
Wenn man den swap deaktiviert und Speicheranforderungen bestehen werden u.a. Pages aus dem Text-segment laufender Prozess rausgeworfen, denn die können ja jederzeit wieder von der Platte geholt werden.
Text und Daten von laufenden Prozessen werden schlicht per mmap(2) "geladen".
