Prozessor-Auslastung

Das Herzstück eines Rechners ist sein Prozessor und natürlich ist dessen Auslastung ebenfalls ein wichtiges Element der Systemperformance. Das älteste Maß dafür ist der so genannte Load Average, der auf jeden Fall dem gleitenden Durchschnitt der Anzahl laufender und ausführungsbereiter Prozesse in der Run Queue entspricht. Im Unterschied zu anderen Unix-Varianten addiert Linux auch noch die auf I/O wartenden Prozesse zum Load Average. Dessen Wert steigt hier also, wenn das System viele I/O-lastige Prozesse hat.

Als Faustregel kann man sich merken, dass der Load Average die Anzahl der CPUs nicht um das Zwei- unter Linux vielleicht auch kurzzeitig das Dreifache übersteigen sollte – andernfalls bildet die CPU den Flaschenhals und das System reagiert nur noch träge. Ein Load Average von eins bei einer CPU würde bedeuten, dass ein Prozess den Prozessor belegt und keiner wartet. Es herrschen also paradiesische Verhältnisse. Nun greifen auf einen beschäftigten Server aber immer auch Prozesse gerade auf die Platten zu und müssen warten, bis das I/O-Subsystem die Daten liefert. In diesem Stadium gehen sie zwar – zumindest unter Linux – in den Load Average ein, sind aber tatsächlich gar nicht ausführbar. Deshalb darf man dessen kritischen Wert etwas höher als eins pro CPU ansetzen.

Doch spätestens wenn die Länge der Run Queue mehr als das Dreifache der CPU-Anzahl beträgt, warten eine entsprechende Anzahl Prozesse auf die knappe Ressource-Rechenzeit und bremsen das System merklich aus. Den Load Average für die letzten ein, fünf und fünfzehn Minuten geben Tools wie »uptime« oder »top« aus.

Der Load Average ist allerdings nicht die einzige CPU-bezogene Metrik. Eine weitere ist etwa die Anzahl der so genannten Context Switches. Damit sind die Umbauarbeiten gemeint, die jedes Multitasking-System ausführen muss, bevor es eine neue Task der CPU übergibt – entweder durch den Prozess-Scheduler, oder weil es eine Interrupt-Service-Routine ausführt. Damit der unterbrochene Prozess später an derselben Stelle wieder fortgesetzt werden kann, sind im Zuge des Context Switch der Program Counter und andere Register im RAM zu sichern. Das kostet Zeit, und zwar unverhältnismäßig mehr als die Ausführung einer normalen Instruktion. Sehr viele Context Switches bremsen also. (Ähnliches gilt für sehr viele Interrupts, die ihrerseits auch immer einen Context Switch erzwingen.) Noch teurer ist der Spaß, wenn der Prozess in einem Mehrprozessorsystem bei Wiederaufnahme die CPU wechselt und dadurch seinen Cache verliert. Moderne Betriebssysteme wie Linux sind deshalb darauf bedacht, die Anzahl der Context Switches zu optimieren und Prozesse an eine CPU zu binden (CPU-Affinität).

Auskunft über den Status der CPU gibt das bereits erwähnte »vmstat«, das sich wie seine Kollegen (»netstat«, »iostat«, »mpstat«) auch mit einem Intervall und einer Wiederholungsanzahl aufrufen lässt. Alternativen sind »top« oder das vielseitige »nmon«. Auch »procinfo« gibt hier Aufschluss und führt zusätzlich beispielsweise eine Interrupt-Statistik. Schließlich berichtet auch »mpstat« über die Anteile an User-, System- und Leerlaufzeit jeder CPU.

Rechenzeit optimal nutzen

Sieht man einmal von der fragwürdigen Übertaktung der CPU ab, ist ihre Rechenkapazität eine gegebene Größe. Dennoch gibt es Ansatzpunkte – der naheliegendste: alles Unnötige abschalten. Nicht verwendete Services, die dennoch laufen, stehlen den Applikationen Rechenzeit. Ausmisten ist Tuning.

Zweitens ist es möglich als Anwender in das Scheduling einzugreifen, indem man via »nice« beziehungsweise »renice« beeinflusst, wie kooperativ sich ein Prozess verhält. Je höher der Nice-Wert, desto freundlicher verhält er sich, je niedriger der Wert ist, desto egoistischer geht der Prozess zu Werke.

Drittens sind einige Optionen des Schedulers direkt über Parameter konfigurierbar. Seine Strategie lässt sich damit an eher interaktive Workloads oder Batch-Prozesse anpassen. Der mit Kernel 2.6.23 eingeführte neue modulare Scheduler wird hier künftig sicher noch weitergehende Möglichkeiten bieten.

Viertens lohnt es sich, zu überlegen, wann man via »cron« oder »at« Batch-Prozesse startet. Fünftens hat auch das Design der Applikation selber einen großen Einfluss auf den Rechenzeitbedarf. Profiler und Tools wie »strace« geben dabei Aufschluss darüber, mit welchen Operationen das Programm die meiste Zeit totschlägt oder welche Libraries und Systemaufrufe es wie oft benutzt.