Bash-Skripte, die Multicore-Prozessoren auslasten

Will man Software dazu bewegen, verschiedene Dinge parallel auszuführen, dann liegt die erste Herausforderung darin, die Aufgabe in sinnvolle Teilprobleme aufzuteilen, die der Rechner gleichzeitig bearbeiten und deren Resultate er am Ende wieder zusammenführen kann. OpenMP ist eine Bibliothek, die bei dieser Spielart der Parallelisierung hilft. Für Bash-Skripte ist dagegen nicht das numerische Problem typisch, stattdessen sollen sie oft mehrere Dateien in gleicher Weise verarbeiten.

Klassisch seriell

Ein solches Skript sieht dann typischerweise aus wie Listing 1. Die Shellfunktion arbeitet darin alle Argumente der Reihe nach ab und übergibt sie an ein Programm (»doSomething«). Eine parallele Verarbeitung drängt sich hier förmlich auf. Dafür bieten sich verschiedene Strategien an.

Bevor sich der Skript-Autor aber ins Programmieren stürzt, lohnt es sich zu überlegen, ob eine Parallelisierung überhaupt sinnvoll und machbar ist.

01 doSeriell() {
02  local item
03  for item in "$@"; do
04   doSomething "$item"
05  done
06 }

Sinnfrage

Die Sinnfrage ist recht einfach zu beantworten, eine Hilfestellung gewährt hier der Befehl »sar -u -P ALL 1 0«. (Das Utility »sar« ist Teil des Sysstat-Pakets [1].) In einer zweiten Konsole startet der Tester anschließend das Bash-Skript. Der Sar-Befehl gibt im Sekundenabstand die Auslastung aller CPUs des Systems aus (Abbildung 1). Neben dem »%idle«-Wert ist auch der »%iowait«-Wert interessant: Er zeigt, ob die Berechnung womöglich pausiert, weil das System auf ausstehende I/Os wartet.

Abbildung 1: Die Ausgabe von »sar« zeigt die Auslastung aller CPUs. Nur wenn einige Kerne überlastet sind, während sich andere langweilen, lohnt sich Parallelisierung.

Die Sar-Werte erleichtern die Entscheidungsfindung sehr: Nur falls es überhaupt Prozessoren gibt, die sich langweilen, während gleichzeitig andere am Anschlag arbeiten (wie in Abbildung 1), lohnt sich eine Parallelisierung. Typische Anwendungsfälle sind CPU-lastige Bild- und Musikkonvertierungen oder das Parsen von Logdateien mit komplexen regulären Ausdrücken. Ungeeignet sind dagegen I/O-gebundene Prozesse. Zwar lässt sich durchaus das Kopieren von 200 Dateien von einem Verzeichnis in ein anderes parallelisieren, nur bringt das letztlich gar nichts, weil hier die Festplatte den Engpass bildet.

Die Machbarkeit der Parallelisierung bestimmt dagegen in erster Linie das Problem. Wenn die Verarbeitungsschritte voneinander abhängen oder wenn die Reihenfolge der Verarbeitung wichtig ist, dann ist eine sequenzielle Abfolge unvermeidlich. Eventuell hilft dabei ein anderer Algorithmus, die in diesem Artikel vorgeschlagenen einfachen Änderungen reichen in dieser Situation sicherlich nicht aus.

Außerdem sollte der Admin noch bedenken, dass es nicht immer sinnvoll ist, den Rechner voll auszulasten. Wenn er neben CPU-intensiven Aufgaben auch noch seiner regulären Tätigkeit am Rechner nachgehen will (Mailing, Internet, Texte schreiben und so weiter), wird er eine sequenzielle Verarbeitung im Hintergrund, die nur einen Kern beschäftigt, eher mögen als die schnelle Alternative, die den Rechner blockiert.