Befehl in for Schleife auf mehrere Kerne verteilen?

[Cordess]

Ich habe mehrere Datenträger in einem Ordner eingebunden und will diese nun alle mit clamscan einzeln scannen, da ich auch die Ergebnisausgabe pro Datenträger getrennt haben will.

Dazu nutze ich momentan folgenden Befehl in der BASH:

Code: Alles auswählen

time for disk in *; do clamscan -ir $disk ; done

Jetzt ist es natürlich so, dass die for Schleife nur sequentiell abgearbeitet wird.
D.h. zuerst kommt Datenträger A und wenn der fertig ist, B, dann C usw..
Das dauert auf einem Mehrkernsystem natürlich unnötig lange und könnte man beschleunigen, in dem man
Datenträger A Kern 1 zuweist, Datenträger B Kern 2, Datenträger C Kern 3 usw... bis alle Kerne - 1 ausgelastet sind. Den einen brauch ich für sonstige Arbeiten auf dem Desktop.

Nur wie realisiert man das mit einer for Schleife?
Weiß das jemand?

Gibt's da für eine for Schleife einen speziellen Parameter oder vielleicht einen anderen for Befehl, mit dem man genau das machen kann?

Zwar gibt es für clamdscan die Option -m --multiscan, mit der man dann den Prozess auf mehreren Kernen abarbeiten lassen kann, aber vielleicht brauche ich die for Schleife auch mal für etwas anderes, was keine parallele Abarbeitung implementiert hat. Daher suche ich nach einer generellen Lösung die mit allen möglichen Befehlen funktioniert.

[GregorS]

... Datenträger A Kern 1 zuweist, Datenträger B Kern 2, Datenträger C Kern 3 usw...

Ich würde nicht darauf vertrauen, dass das einen nennenswerten Geschwindigkeitsvorteil bei den Platten-Operationen brächte - Controller/Bus(se) könnten Flaschenhälse darstellen.

Gruß

Gregor

[Cordess]

In dem Fall ist die SSD nicht das Nadelöhr.
clamscan ist wirklich langsam.

Beispiel:

Code: Alles auswählen

Known viruses: 8615510
Engine version: 0.103.5
Scanned directories: 73
Scanned files: 2522
Infected files: 0
Data scanned: 2429.14 MB
Data read: 638.53 MB (ratio 3.78:1)
Time: 1688.061 sec (28 m 8 s)

638 MB hätte ich mit dem cp Befehl in 28 min ein paar mal kopieren können.

[Meillo]

Ganz einfach: Indem du nach dem Befehl ein &-Zeichen machst, also damit den Strichpunkt ersetzt. Dann laeuft der Job im HIntergrund und sofort wird der naechste Job im Hintergrund gestartet, usw. Mehrere laufende Jobs werden dann automatisch auf mehrere Kerne verteilt.

Mit dem Befehl `wait' kannst du danach warten bis alle Befehle fertig sind, falls du das willst.

Code: Alles auswählen

for i in 5 15 10; do sleep $i & done ; wait

Alternativ koenntest du auch `parallel' verwenden, z.B. etwa so:

Code: Alles auswählen

parallel clamscan -ir -- *

[Cordess]

Ganz einfach: Indem du nach dem Befehl ein &-Zeichen machst. Dann laeuft der Job im HIntergrund und sofort wird der naechste Job im Hintergrund gestartet, usw. Mehrere laufende Jobs werden dann automatisch auf mehrere Kerne verteilt.

So werden mehr Prozesse gestartet, als Kerne verfügbar sind.

Aber ich denke ich habe eine bessere Lösung gefunden:

Code: Alles auswählen

for mach in 3 5 1 3 ; do sem -j 3 "sleep $mach && echo $mach" ; done; sem --wait

sem -j N garantiert mir, dass nur N Kerne benutzt werden.
sleep müsste dann natürlich mit clamscan entsprechend ersetzt werden.

Aber es gibt bei der Sache noch ein anderes Problem. Die Ausgabe in der Konsole könnte sich überschneiden.
Bspw. könnten zwei Prozesse zur gleichen Zeit nach stdout schreiben und im Falle von clamscan -i müsste man dann manuell wieder auf das Verzeichnis schauen, damit man unterscheiden kann, für welches Device die Ausgabe nun gilt.

Ich bräuchte also eine Lösung wo die Ausgabe nach stdout wieder sequentiell ist.
Vielleicht etwas, was die Ausgabe pro Prozess in einen Buffer schickt und dort quasi zwischenspeichert und dann jeden einzelnen Buffer nacheinander ausgibt?
Dazu habe ich noch keine Lösung gefunden.

EDIT:
Außer ich nutze die Variable $disk als Dateiname, in dem ich die Ausgabe mit angehängtem "> $disk.output" in eine Datei schreibe, dann hätte ich für jeden Prozess eine eigene *.output Datei. Das würde gehen. Eine Lösung, die ohne Schreibzugriff auf einen Datenträger auskommt, wäre mir allerdings noch lieber.

EDIT2:
Also so:

Beispiel, diesmal mit Dateien:

Code: Alles auswählen

time for datei in *.zip ; do sem -j 7 clamscan $datei > $datei.output ; done; sem --wait

Interessanterweise wird dabei dummerweise nur time viel zu früh ausgegeben.
Dafür wird aber wenigstens jedes Ergebnis in eine eigene Datei gespeichert.

Zeitmäßig habe ich in diesem Beispiel jetzt allerdings nichts gewonnen, denn clamscan auf alle Dateien in nur einem Prozess anzuwenden geht sogar schneller. Da ist dann die Größe der Dateien zu klein bzw. die Datenmenge zu klein.
Ich denke, clamscan muss da wohl die Virendatenbank bereit machen und das kostet wohl jede Menge Zeit.
Bei meinem großen Datenträgern sollte das aber so durchaus schneller gehen, als eine sequentielle abarbeitung.

Warum time vorher ausgegeben wird, als die for Schleife abgearbeitet ist, das müsste ich aber noch wissen und dann verhindern.
Time soll die Zeit ja erst ganz am Schluss ausgeben. Weiß jemand woran das liegen könnte?

[heisenberg]

Als Verbesserung des workarounds kannst Du nach /dev/shm/... (RAM!) schreiben.

[heisenberg]

Vielleicht ist das ja eine Lösung...

Run ClamAV as a Daemon

Install clamav-daemon. You can then use clamdscan where you would previously have used clamscan. Lots of programs, especially e-mail servers, can connect to a ClamAV daemon. This speeds up virus scanning as the program is always in memory.

The clamav-daemon package creates a 'clamav' user; in order to allow ClamAV to scan system files, such as your mail spool, you can add clamav to the group that owns the files.

[Meillo]

So werden mehr Prozesse gestartet, als Kerne verfügbar sind.

Das kann natuerlich passieren.

Aber ich denke ich habe eine bessere Lösung gefunden:

Code: Alles auswählen

for mach in 3 5 1 3 ; do sem -j 3 "sleep $mach && echo $mach" ; done; sem --wait

sem -j N garantiert mir, dass nur N Kerne benutzt werden.

Das kannte ich noch nicht.

`parallel' kann auch `-j' ... allerdings kannst du damit die Ausgabe nicht so einfach in Dateien schreiben wie du es in deinem Beispiel weiter unten dann machst.

Vielleicht etwas, was die Ausgabe pro Prozess in einen Buffer schickt und dort quasi zwischenspeichert und dann jeden einzelnen Buffer nacheinander ausgibt?

Wenn du mit Buffer sowas wie eine Pipe meinst, dann ist das keine gute Idee, weil Pipe-Buffer begrenzt sind und dann den Schreiber blockieren wenn sie voll sind. Du musst schon Dateien verwenden. Die kannst du aber, wie heisenberg angemerkt hat, auch in den RAM legen.

Code: Alles auswählen

time for datei in *.zip ; do sem -j 7 clamscan $datei > $datei.output ; done; sem --wait

Interessanterweise wird dabei dummerweise nur time viel zu früh ausgegeben.
[...]
Warum time vorher ausgegeben wird, als die for Schleife abgearbeitet ist, das müsste ich aber noch wissen und dann verhindern.
Time soll die Zeit ja erst ganz am Schluss ausgeben. Weiß jemand woran das liegen könnte?

Das ist nicht verwunderlich wenn dir klar ist, dass `sem' auch nichts anderes macht als den Befehl im Hintergrund zu starten. Erst `sem --wait' ist der Zeitpunkt an dem alle Befehle fertig sind. Wenn du `time' von dem ganzen Rest haben willst, dann musst du um den ganzen Rest runde Klammern machen:

Code: Alles auswählen

time (for datei in *.zip ; do sem -j 7 clamscan $datei > $datei.output ; done; sem --wait)

[Cordess]

Als Verbesserung des workarounds kannst Du nach /dev/shm/... (RAM!) schreiben.

Das ist eine gute Idee. Danke dafür.

Was clamdscan als daemon betrifft, ich wollte jetzt keine AV Software als Daemon im Hintergrund laufen lassen.
Sicherlich ist das dann beim Scannen schneller, da die Virendatenbank dann ja schon ins RAM geladen ist, aber extra einen Daemon starten wollte ich dafür jetzt nicht. Trotzdem danke für den Tipp.

[Cordess]

Das ist nicht verwunderlich wenn dir klar ist, dass `sem' auch nichts anderes macht als den Befehl im Hintergrund zu starten. Erst `sem --wait' ist der Zeitpunkt an dem alle Befehle fertig sind. Wenn du `time' von dem ganzen Rest haben willst, dann musst du um den ganzen Rest runde Klammern machen:

Code: Alles auswählen

time (for datei in *.zip ; do sem -j 7 clamscan $datei > $datei.output ; done; sem --wait)

Super

Das ist genau das was ich noch brauchte.
Jetzt funktioniert es.

Ich danke euch allen und werde das dann an meine Datenträgerprüfung anpassen, also im Prinzip so:

Code: Alles auswählen

time (for disk in *; do sem -j 7 clamscan -ir $disk > /dev/shm/$disk.output ; done; sem --wait)

[hikaru]

Falls du die Anzahl der CPU-Threads automatisch ermitteln willst, um die Anzahl der clamscan-Instanzen zu steuern, dann brauchst du nur die Anzahl der Records in /proc/cpuinfo zählen, z.B. mit grep:

Code: Alles auswählen

$ grep -c processor /proc/cpuinfo 
8

Falls clamscan nicht von Hyperthreading profitiert, wovon ich nicht ausgehe, dann solltest du noch prüfen, ob die CPU das kann:

Code: Alles auswählen

$ grep -m 1 flags /proc/cpuinfo | grep -c ' ht '
1

Wenn dabei "Ja" (1) herauskommt, dann solltest du die Anzahl der Threads halbieren.

Mein Beispiel stammt also von einer 4-Kern-CPU mit Hyperthreading (=8 Threads).

[heisenberg]

Du hattest an eine generische Lösung gedacht.

Meine Gedanken sind derart, dass man ja eigentlich nur X Pipes bräuchte, in die dann jeweils immer nur 1 Prozess schreibt. Am Ende jeder Ausführung wird ein Marker gesetzt. X ist die Anzahl der parallelen Ausführungen. Ein Nachfolgeprozess liest alle Pipes und serialisiert die Daten mit Hilfe der Marker.

Ist nur die Frage, wie man die Information der Pipe ID mitgibt. Es müsste ja z. B. nur ein Zähler sein, der vor jeder Ausführung erhöht wird mit Ausgabeumlenkung in Abhängigkeit von Modulus Pipe ID (Zähler).

Das wäre dann vollständig parallelisiert und nicht nur schubweise, wie die aktuelle Lösung.

[Cordess]

Falls du die Anzahl der CPU-Threads automatisch ermitteln willst, um die Anzahl der clamscan-Instanzen zu steuern, dann brauchst du nur die Anzahl der Records in /proc/cpuinfo zählen, z.B. mit grep:

Code: Alles auswählen

$ grep -c processor /proc/cpuinfo 
8

sem bringt da noch ein paar weitere Bordmittel mit.
Da kann man die CPU wie gewünscht komplett auslasten, oder alle Kerne bis zu einer bestimmten Anzahl N auslasten.
Siehe manpage zu sem.
Das grep für /proc/cpuinfo brauchst du also nicht, falls du ein entsprechendes Skript schreiben musst.

Falls clamscan nicht von Hyperthreading profitiert, wovon ich nicht ausgehe, dann solltest du noch prüfen, ob die CPU das kann:

Code: Alles auswählen

$ grep -m 1 flags /proc/cpuinfo | grep -c ' ht '
1

Wenn dabei "Ja" (1) herauskommt, dann solltest du die Anzahl der Threads halbieren.

Mein Beispiel stammt also von einer 4-Kern-CPU mit Hyperthreading (=8 Threads).

Ich habe einen Core i7 mit 4 Kernen und aktivem nicht abgeschaltetem HT, weswegen ich die 7 genommen habe.
Warum ich die Anzahl der Threads halbieren sollen, weiß ich allerdings nicht.

Gut HT ist kein vollwertiger Kern, bezüglich der Threads kann man das aber so behandeln, als hätte man eine doppelte Anzahl an Kerne ohne HT.
So mache ich das zumindest in der Regel.

[Cordess]

Ist nur die Frage, wie man die Information der Pipe ID mitgibt. Es müsste ja z. B. nur ein Zähler sein, der vor jeder Ausführung erhöht wird mit Ausgabeumlenkung in Abhängigkeit von Modulus Pipe ID (Zähler).

Für sem gibt es noch den Parameter --id vielleicht ist das, das was du suchst.

Das wäre dann vollständig parallelisiert und nicht nur schubweise, wie die aktuelle Lösung.

Wie meinst du das genau?
Sobald ein clamscan prozess beendet wird, wird gleich der nächste gestartet. Da sem praktisch schaut, ob ein Kern wieder frei ist.

[heisenberg]

Ist nur die Frage, wie man die Information der Pipe ID mitgibt. Es müsste ja z. B. nur ein Zähler sein, der vor jeder Ausführung erhöht wird mit Ausgabeumlenkung in Abhängigkeit von Modulus Pipe ID (Zähler).

GNU parallel kann die Sequenznummer mitgeben! {#}

[heisenberg]

Wie meinst du das genau?
Sobald ein clamscan prozess beendet wird, wird gleich der nächste gestartet. Da sem praktisch schaut, ob ein Kern wieder frei ist.

Sorry. Verständnis Fehler meinerseits.

[hikaru]

sem bringt da noch ein paar weitere Bordmittel mit.

Danke! Damit müsste ich mich noch beschäftigen.

Ich habe einen Core i7 mit 4 Kernen und aktivem nicht abgeschaltetem HT, weswegen ich die 7 genommen habe.
Warum ich die Anzahl der Threads halbieren sollen, weiß ich allerdings nicht.

Gut HT ist kein vollwertiger Kern, bezüglich der Threads kann man das aber so behandeln, als hätte man eine doppelte Anzahl an Kerne ohne HT.

Ob man von HT profitiert hängt vom Szenario ab. Wenn du z.B. Videos encodierst profitierst du davon nicht. Im Gegenteil, der HT-Overhead reduziert sogar die Geschwindigkeit leicht.
Ich würde erwarten, dass clamscan auf ausreichend schnellen CPUs I/O-limitiert ist. Da sollte HT also Vorteile bringen. Vielleicht könnte man sogar mehrere Instanzen auf einen CPU-Thread schicken, und immer noch profitieren.
Ich habe eine I/O-limiterte Anwendung in der das Optimum ist, zwei Instanzen pro Thread zu starten. Die bremsen sich zwar gegenseitig leicht aus, sind in der Summe aber parallel immer noch schneller, als würden sie sequenziell laufen. Der Rechner muss allerdings keine interaktive User-Session zusätzlich bedienen.

[Cordess]

Gut HT ist kein vollwertiger Kern, bezüglich der Threads kann man das aber so behandeln, als hätte man eine doppelte Anzahl an Kerne ohne HT.

Ob man von HT profitiert hängt vom Szenario ab. Wenn du z.B. Videos encodierst profitierst du davon nicht. Im Gegenteil, der HT-Overhead reduziert sogar die Geschwindigkeit leicht.

Ach so meinst du das. Ja in gewissen Fällen kann das vorkommen, in den meisten Fällen hilft HT aber mehr als es schadet, weswegen ich bei meinem 4 Kerner immer von 8 Threads ausgehe.

Ich würde erwarten, dass clamscan auf ausreichend schnellen CPUs I/O-limitiert ist. Da sollte HT also Vorteile bringen. Vielleicht könnte man sogar mehrere Instanzen auf einen CPU-Thread schicken, und immer noch profitieren.

Keine Ahnung. Ich weiß nur, dass clamscan einer der langsamsten Antivirensoftware ist, die ich kenne, aber gut, er ist Open Source und vielleicht macht er seine Aufgabe gründlicher als andere und so oft muss ich Dateien nicht scannen, weswegen ich mit der Geschwindigkeit dann wiederum meistens leben kann.

Ich habe eine I/O-limiterte Anwendung in der das Optimum ist, zwei Instanzen pro Thread zu starten. Die bremsen sich zwar gegenseitig leicht aus, sind in der Summe aber parallel immer noch schneller, als würden sie sequenziell laufen.

Ja, in dem Fall macht das Sinn.

[JTH]

Bin ja ein Freund davon, Sachen in reiner Shell zu lösen. Aber bietet es sich nicht hier an, direkt parallel aus parallel zu benutzen, anstatt einer manuellen Parallelisierung mit sem? sem ist nichts anderes als ein Alias für parallel --semaphore, das Paket ist also eh schon installiert.

parallel hat (offensichtlich) die gleichen Optionen wie sem zu Angabe und Beschränkung der verwendeten Kerne/CPUs. Und parallel sorgt auch ohne extra Arbeit dafür, dass die Ausgaben der einzelnen Aufrufe streng getrennt bleiben. Und vieles, vieles mehr, wenn mans braucht

Die Übertragung von diesem

Code: Alles auswählen

time (for disk in *; do sem -j 7 clamscan -ir $disk > /dev/shm/$disk.output ; done; sem --wait)

wäre recht übersichtlich:

Code: Alles auswählen

parallel -j7 clamscan -ir {} ::: *

Evtl. plus -k/--keep-order. -j7 sieht aus wie CPU-Kerne - 1. Das geht auch per -j-1. Wenn man -j ganz weg lässt, nimmt parallel, anders als sem, direkt alle Kerne.

Wenns doch eine Umleitung der einzelnen Ausgaben in Dateien sein soll, geht das auch recht direkt:

Code: Alles auswählen

parallel -j-1 'clamscan -ir {} > {}.output' ::: *

[heisenberg]

...parallel sorgt auch ohne extra Arbeit dafür, dass die Ausgaben der einzelnen Aufrufe streng getrennt bleiben.

Also, das, was ich mir ausgedacht habe, ist hier der Default...