Der Load Average auf Linux Systemen

Auszug aus einem Artikel, den ich am 31. Juli 2009 auf der Mailingliste des Linux Workshops Köln geschrieben habe.

Mit dem Kommando uptime kann man auf einem Linux/UNIX System dem Load Average anzeigen:

user@host:~$ uptime
 18:22:15 up 28 days,  6:32,  1 user,  load average: 0.17, 0.08, 0.04

Die drei Zahlen ganz rechts geben an, wie viele Prozesse durchschnittlich in den letzten 1, 5 bzw. 15 Minuten zur Bearbeitung anstanden.

Der Load Average ist ein exponentiell geglätteter Mittelwert der Anzahl der Prozesse in der Run-Queue. Er wird alle fünf Sekunden aus der gerade aktuellen Größe der Queue neu berechnet.

Ein dauerhafter Load von 1.0 kann auf einem Einprozessorsystem bedeuten, dass der Prozessor voll ausgelastet ist. Diesen Wert erhält man bei einem einzelnen Prozess mit hinreichend langer Laufzeit, z.B. einem Passwortcracker. Ein Load von 1.0 kann aber ebenfalls bedeuten, dass zeitweise mehrere, zeitweise gar kein Prozess läuft. Dann würden z.T. Prozesse warten, aber das System ist insgesamt nicht ausgelastet.

Man beachte, dass bei der Neuberechnung des Load Average alle fünf Sekunden eine Momentaufnahme der Run Queue herangezogen wird. Prozesse, die kürzer laufen, gehen evtl. in die Berechnung gar nicht ein. Software, die mittels eines eigenen Schedulers in einem Vielfachen von 5 Sekunden viele Prozesse erzeugt, kann wegen der Interferenzeffekte zu einem sehr seltsamen Load führen; ein Beispiel dafür ist ein Nagios-Server.

Zu beachten ist außerdem, dass nicht nur Userspace-Prozesse, sondern auch Kernel-Threads von I/O Aktivitäten (z.B. SCSI Treiber) berücksichtigt werden. Deswegen kann ein einzelner I/O-lastiger Prozess den Load durchaus um mehr als eins erhöhen. Z.B. habe ich schon Systeme gesehen, auf denen das Rippen eines CD-Images auf die Festplatte einen Load von dauerhaft 8.0 erzeugt. Da die verschiedenen Treiber im Kernel sehr unterschiedlich von Kernel-Threads Gebrauch machen, sind Werte nicht vergleichbar.

Das oben gesagte gilt sinngemäß für beliebige Anzahlen von Prozessoren. Auf einem System mit 8 unabhängigen Prozessoren und 8 lange rechnenden Prozesse lasten diese genau die CPUs aus und sorgen für einen Load von 8.0.

In vielen Systemen sind aber heute Multicore- oder Hyperthreading-Prozessoren verbaut, auf denen nur bestimmte Baugruppen mehrfach vorhanden sind (z.B. Register, Steuerwerk), aber andere gemeinsam benutzt werden müssen (z.B. Rechenwerk, Speicherzugriff, Caches).

Als grobe Faustregel verwende ich seit längerem die folgende Berechnung:

Ein System “verträgt” einen Load von 1.0 pro CPU, 0.6 pro weiteren Core und 0.3 pro weiterem Hyperthread. Beispiel: ein 2-CPU System mit je 2 hyperthreadfähigen Cores erscheint in /proc/cpuinfo als 8 CPU-System, kommt aber auf eine Belastbarkeit von:

1.0 + 0.3 + 0.6 + 0.3 + 1.0 + 0.3 + 0.6 + 0.3 = 4.4

Je nach Anwendung sollte diese Belastbarkeit mit einem weiteren Faktor multipliziert werden. Anwendungen, die eher batchorientiert arbeiten, können überlastet werden (Faktor > 1), um die CPUs noch vollständiger auszulasten und Zeiten von Inaktivität zu überbrücken. Anwendungen mit einer hohen Interaktivität sollten für niedrige Latenzzeiten besser unterlastet werden. Auch wieder Erfahrungswerte:

Systemtyp Faktor
E-Mail-Gateway 2.0 - 3.0
Desktop-PC 1.0
Webserver 0.5 - 1.0
SQL-Datenbank 0.4 - 0.8
Fileserver 0.5
DNS-/NTP-Server 0.2

Wenn man jetzt noch davon ausgeht, dass sich der Leistungsbedarf einer Anwendung alle 18 Monate verdoppelt, dann kann man die Dimensionierung wie folgt planen:

Beispiel: der Kunde plant einen neuen Fileserver mit einer Laufzeit von 3 Jahren. Es werden die oben genannten 2x DualCore CPUs mit Hyperthreading eingesetzt, die einen Load von 4.4 vertragen. Aufgrund der Anwendung multipliziere ich diesen mit 0.5, empfehle also einen Load von 2.2. Da sich innerhalb von drei Jahren der Leistungsbedarf vervierfachen wird, sollte der Load bei der im normalen Betrieb erreichten Spitzenlast den Wert von 0.55 nicht überschreiten.

Das ganze sind natürlich nur grobe Faustregeln, die sich aber in der Praxis bewährt haben.