Prozessorauslastung bei Mehrkern-CPUs

[kalamazoo]

Eine weitere meiner vielleicht etwas eigentümlichen, aber durchaus ernst gemeinten laienhaften Fragen -- ich hoffe trotzdem auf weiterführende Informationen:

Hintergrund: ClamAV lief oder läuft bei mir auf mehreren Rechnern (nicht der Dämon, nur der Scan). Die Überprüfung des NAS dauert nun schon mehr als drei Tage -- nicht weiter verwunderlich, sind doch knappe 60TB an Daten zu durchsuchen. Was mir aber auffällt:
clamscan lief auf dem Laptop mit 2 Kernen mit 50% Auslastung, das Notebook mit 4 Kernen hatte 25% und der 8-kernige Desktop arbeitet ziemlich konstant mit nur 12,5% CPU-Leistung.
Es sieht also so aus, als ob ClamAV insgesamt von einem Chip mit 100% ausgeht und mit Mehrkernprozessoren nichts anfangen kann und Multicore-Ressourcen ignoriert.

Funktioniert Multithreading nicht, weil es sich nur um einen Prozess (clamscan) handelt? Aber andererseits werden laut System-Monitor doch alle acht Kerne durchaus simultan benützt? Könnte man die Prozessorauslastung irgendwie über das CLI steuern?

Ich nehme mal an, dass das mit dem Kernel zu tun hat, weshalb ich die Frage mal hier reinstelle -- falls nicht, bitte verschieben!

[MSfree]

Es sieht also so aus, als ob ClamAV insgesamt von einem Chip mit 100% ausgeht und mit Mehrkernprozessoren nichts anfangen kann und Multicore-Ressourcen ignoriert.

Nein. Nicht ClamAV geht von 100% aus sondern der Linuxkernel. CalmAV kann halt nur einen CPU-Kern voll auslasten, was bei einem Achtkerner 12.5% der Gesamtleistung ist.

Funktioniert Multithreading nicht, weil es sich nur um einen Prozess (clamscan) handelt?

Nein. CalmAV ist halt nicht in der Lage, mehrere CPU-Kerne zu benutzen, weil es schlecht programmiert ist.

Aber andererseits werden laut System-Monitor doch alle acht Kerne durchaus simultan benützt?

Nein. Der laufende CalmAV-Prozeß kann von Linuxkernel immer mal wieder den CPU-Kern wechseln.

Könnte man die Prozessorauslastung irgendwie über das CLI steuern?

Nein. Ein Prozeß, der nur single-theraded programmiert wurde, kann nur einen CPU-Kern auf einmal nutzen.

Ich nehme mal an, dass das mit dem Kernel zu tun hat

Nein. Es hat mit dem Programm zu tun.

[irmgard24]

Funktioniert Multithreading nicht, weil es sich nur um einen Prozess (clamscan) handelt?

Nein. CalmAV ist halt nicht in der Lage, mehrere CPU-Kerne zu benutzen, weil es schlecht programmiert ist.

Vollkommen richtig!

Als Denkansatz / Workaround:

Starte mehre Scans auf unterschiedliche Ordner und hefte die Prozesse an bestimmte CPU Kerne.

z.,b.:
Scan1: /ordner/a - CPU 1
Scan2: /ordner/b - CPU 2
usw.

Der Befehl dazu: taskset

[wanne]

Clamd startet per default laut man page mit 10 Theads. Du kannst das in der clamd.conf ändern.

So als kleine Warnung: Während einige Programm sich schlicht nicht die Mühe gemacht haben, multithreadding zu implementieren, ist es hin und wieder auch Absicht. gzip z.B. hat multi threadding absichtlich an vielen Stellen wieder ausgestellt. Viele andere Programme machen es nur nach expliziter Angabe.
Ich hätte erwartet, dass ClamAV sowieso die meiste Zeit auf die Platte wartet und die CPU idelt. Prüfst du jetzt 2 Dateien Gleichzeitig muss die die ganze Zeit hin und her springen was sehr lange dauert. Dein Scanvorgamg wird effektiv langsamer. Das scheint bei dir nicht der Fall zu sein. sonst währen ja nicht ein Kern auf 100% sondern keiner.
Intelligentere Programme lesend deswegen mit einem Thread in den RAM und die anderen arbeiten nur auf dem, was der schon besorgt haben und schlafen wenn der nicht hinter her kommt. Auf raids/storage Pools, wird das Problem ungleich komplizierter.
Deswegen gibt es ja clamd. Wenn du 5 ClamAV auf verschiedene Ordner laufen lässt. Hast du, genau wie wenn es nur einer ist, noch immer 10 clamd Threads. So kannst du ein mal konfigurieren was unabhängig vom konkreten Szenario sinnvoll ist..

Oft ist aber auch der RAM das Bottleneck. Und da ließt die CPU halt aktiv draus. Das heißt die läuft auf Vollast. Aber ob jetzt ein oder zwei CPUs auf den selben RAM warten macht den nicht schneller. Du hast nur mehr CPUs beschäftigt um die selbe Arbeit zu tun. – Das war ja die Idee, warum Intel Hyperthreadding eingeführt hat: Während ein Thread aus RAM/L3 Cache ließt kann der andere rechnen.


Kurz: Wenn du das Programm (entweder per Einstellung oder per mehrfach laufen lassen) dazu bekommst mehr Kerne aufzulasten: Benchmarke vorher mal, ob das wirklich schneller wird, oder ob du schlicht mehr Ressourcen verwendest..

[kalamazoo]

…

Aber andererseits werden laut System-Monitor doch alle acht Kerne durchaus simultan benützt?

Nein. Der laufende CalmAV-Prozeß kann von Linuxkernel immer mal wieder den CPU-Kern wechseln.
…

Zuerst mal danke für Deine Antworten!

Zum zitierten Text: hmm, zumindest der GUI-System-Monitor lässt anderes vermuten; clamscan läuft da ziemlich konstant mit 12,5%, der Prozess plasma-systemmonitor selbst steuert da noch um die 1% dazu, ansonsten nur ein paar kurz aufflackernde Prozesse mit 0,1% (wenn überhaupt); die graphische Darstellung mit der bunten Wiedergabe der einzelnen Cores, die jetzt "History" heißt, zeigt nicht nur alternierende Farben, sondern manchmal auch zwei simultan mit der Hälfte der Auslastung oder mehrere mit verschieden großen Anteilen; aber okay...

Gehört jetzt nicht hierher, ich frag's aber trotzdem: was ist das für ein Prozess mit dem Namen [192.168.xxx.xxx]-manager (also NAS-IP in eckigen Klammern mit angehängtem -manager) der von Zeit zu Zeit zusätzliche 12,5% CPU-Leistung in Anspruch nimmt? Der NetworkManager ist es nicht.

Starte mehre Scans auf unterschiedliche Ordner und hefte die Prozesse an bestimmte CPU Kerne.

Gute Idee, das geht natürlich auch. Ich habe bisher stets ganze Partitionen scannen lassen, was auch nicht übermäßig lange gedauert hat (maximal 3-4 Srunden). Die NAS-Partition mit knapp 60TB ist aber riesig: gestartet am 18.3. und clamscan läuft immer noch.

Der Befehl dazu: taskset

Interessant, taskset kenne ich noch nicht, muss ich mir näher anschauen ... und das "Anheften" funktioniert damit?

Clamd startet per default laut man page mit 10 Theads. Du kannst das in der clamd.conf ändern.

Es läuft nur die einmalige Überprüfung clamscan, nicht der Dämon clamd, ich nehme daher an, dass eine andere Config hier nichts ändern würde.

Oft ist aber auch der RAM das Bottleneck. Und da ließt die CPU halt aktiv draus. Das heißt die läuft auf Vollast. Aber ob jetzt ein oder zwei CPUs auf den selben RAM warten macht den nicht schneller. Du hast nur mehr CPUs beschäftigt um die selbe Arbeit zu tun. – Das war ja die Idee, warum Intel Hyperthreadding eingeführt hat: Während ein Thread aus RAM/L3 Cache ließt kann der andere rechnen.

Von den 32 GB RAM werden konstant (und das seit Tagen) 5,7 GiB benutzt, vom Swap zusätzlich 2,7 GiB -- also nicht wirklich eng.

Kurz: Wenn du das Programm (entweder per Einstellung oder per mehrfach laufen lassen) dazu bekommst mehr Kerne aufzulasten: Benchmarke vorher mal, ob das wirklich schneller wird, oder ob du schlicht mehr Ressourcen verwendest..

Okay und danke!

[heisenberg]

So grundsätzlich scheint mir das vernünftig, mit einem Prozess zu scannen. Anders fände ich das nur dann sinnvoll, wenn es Dir egal ist, ob der Server noch erreichbar ist oder nicht. Denn wenn der clamav auf allen Cores loslegt, dann kann es sein, dass Dein System dicht ist und für andere Jobs (Fileserver, ...) nicht mehr zur Verfügung steht. Also das System ist dann vermutlich dicht wegen der erzeugten I/O und nicht wegen der CPU-Last. Aber wenn das Nachts ist, wenn keiner den Server nutzt, dann würde das ja passen.

Wenn Du das möchtest, kannst Du das machen. Du kannst dafür clamdscan (clamDscan) verwenden. Der hat die Option --multiscan, die den Scanner parallelisiert. Dooferweise kann man das nicht näher angeben, wie viele Prozesse clamdscan da verwenden soll. Er wird also vermutlich bei der Option so viele Prozesse/Threads parallel starten, wie Cores verfügbar sind.

[kalamazoo]

So grundsätzlich scheint mir das vernünftig, mit einem Prozess zu scannen ... Denn wenn der clamav auf allen Cores loslegt, dann kann es sein, dass Dein System dicht ist und für andere Jobs (Fileserver, ...) nicht mehr zur Verfügung steht.

Sehr guter Punkt, daran habe ich freilich nicht gedacht!

Wenn Du das möchtest, kannst Du das machen. Du kannst dafür clamdscan (clamDscan) verwenden. Der hat die Option --multiscan, die den Scanner parallelisiert.

clamdscan installiert, werde es ausprobieren!

Wenn der Scanner mit allen Kernen nicht viel mehr als einen Tag bräuchte, würde mich das nicht so stören, so lange kann ich über das Wochenende durchaus auf den Datei-Server verzichten. Milchmädchen hat aber gerade ausgerechnet, dass clamscan (ohne D) nun schon 6 Tage unterwegs ist und das damit ein bisschen knapp werden kann (Milchmädchen sagt: in zwei Tagen wissen wir dann mehr). Eine -- wie Du sagst leider nicht mögliche -- Einschränkung auf vier oder sechs Cores wäre daher wirklich von Vorteil!

P.S. ich habe ja jetzt nicht vor, alle paar Tage den Virenscanner über die Platten laufen zu lassen; seit ich auf Linux umgestiegen bin, gibt es -- durchaus zu meinem Leidwesen* -- ohnehin keine neuen Viren mehr (ich hatte die Linux-Partitionen bisher noch nie geprüft, sie sind aber ohne jede Schadsoftware)
* "zu meinem Leidwesen" deshalb, weil ich mir unter Windows bereits am ersten Tag(!) meinen ersten Computervirus eingefangen habe und diese aus Interesse zu sammeln begonnen habe; Viren haben mich seither immer fasziniert und ich bin mit ihnen stets freundlich umgegangen; der einzige der mir wirklich einiges abverlangte, war ein Rootkit vor 20 Jahren -- da habe ich dann doch lieber alles neu aufgesetzt

[wanne]

clamdscan (clamDscan) verwenden.

Uh der Unterschied zwischen clamdscan und clamscan war mir nicht bewusst. Danke!

So grundsätzlich scheint mir das vernünftig, mit einem Prozess zu scannen. Anders fände ich das nur dann sinnvoll, wenn es Dir egal ist, ob der Server noch erreichbar ist oder nicht.

Naja. Ich glaube clamd läuft mit niedriger CPU und IO/Priorität.
Da CPU-Hochtakten deutlich länger dauert als den Prozess zu wechseln und clamav eh alle caches füllten wird, sollte das eher wenig ausmachen.