Was Multicore-CPUs wirklich bringen

visipix.de, Hannes Keller

Zwei Prozessorkerne – das bedeutet nicht notwenig auch doppelt so schnelle Anwendungen. HTTP-Benchmarks und ein synthetischer Test auf einem flotten Dual-Opteron-System bezeugen: Nur CPU-intensive und gut verteilbare Anwendungen profitieren.

Zunächst tat sich überhaupt nichts. Für den Versuch, dem Leistungsvermögen einiger aktueller Rechner mit Dualcore-CPU auf den Zahn zu fühlen, erhielt zuerst der HTTP-Benchmark Siege [1] ein Engagement. Das Testprogramm kennt einen Modus, der reale Belastungen simuliert, wofür er zwischen den Seitenabrufen einer einstellbaren Anzahl virtueller Benutzer ganz kurze Pausen einschiebt. Das ist wirklichkeitsnäher als die maximale Abfragefrequenz des Benchmark-Mode.

Kein Stress

Gleichzeitig vermindert die Einstellung die Konkurrenz der Apache-Prozesse um die Systemressourcen, namentlich um die CPU. Das Ergebnis: Dem Webserver ist die Anzahl seiner Kerne egal. Was er zu erledigen hat, arbeitet er leicht auf einem ab. Mehr stören nicht, helfen aber auch nicht weiter. Denn bei einer kleinen Seitengröße (2 KByte) steigern mehr virtuelle User proportional den Durchsatz des Servers. Der Anstieg wird im getesteten Rahmen durch keinen Engpass begrenzt. Der Unterschied zwischen einem und zwei Kernen verliert sich dabei im Rauschen der Statistik.

Auch zwischen Apaches verschiedenen Multiprozessing-Modulen (MPM) lassen sich keine Unterschiede erkennen: Das Modul Prefork, das das Verhalten des alten Apache 1.3 nachbildet und von vornherein eine vorgegebene Anzahl Kindprozesse zur Bearbeitung der Anfragen startet, skaliert genauso wie das Worker-Modul, das die Anzahl der Prozesse variabel an die Last anpasst.

Zieht man die Daumenschrauben an und vergrößert die abzurufende Testseite auf 200 KByte oder gar 2 MByte, ändert sich nichts Prinzipielles. Natürlich steigt der Durchsatz des getesteten Servers weiter, aber Single- und Dual-Core wie auch die beiden MPMs bleiben bis weit über 100 User so dicht zusammen, dass die Unterschiede nicht signifikant sind.

Daraus lässt sich eine erste Erkenntnis ableiten: Die Rechenleistung der CPU ist nur eine von etlichen Systemressourcen, zudem bei weitem nicht immer jene, die die Performance des Gesamtsystems begrenzt. Auch für jede Form von normalen Büroarbeiten – E-Mail, Surfen oder Textverarbeitung beispielsweise – gilt dasselbe: Die CPU dreht sowieso schon Däumchen. Verstärkung vergrößert nur ihre Langeweile, schneller wird der Rechner dadurch nicht.

Abbildung 1: Das Linux-Magazin ließ alle Test für diesen Artikel auf einem mit 2,61 GHz getakteten AMD-Dualcore-Opteron 2218 mit 2 MByte Cache laufen. Der online konfigurierte und drei Tage später gelieferte 2-HE-Server der Firma Thomas-Krenn AG ist mit 2 GByte DDR2-RAM, SATA-Festplatte und Debian ausgestattet.

Im Grenzbereich

Im Webserver-Beispiel ändern sich die Verhältnisse, wenn man die kleinen Pausen zum Luftholen streicht, die der Lasttest-Modus einfügt, und Sieges Benchmark-Modus die maximal mögliche Anfrageflut generieren lässt. Bereits zehn User fragen den Server in dieser Betriebsart statt ein paar 1000-mal je nach Seitengröße bis zu einigen 100000-mal in der Minute an.

Das lässt ihn dann doch nicht mehr kalt. Jetzt steigt der Durchsatz mit zunehmender Nutzerzahl nicht mehr, sondern sinkt als Zeichen der Überlastung. Die große Anzahl beteiligter Prozesse beansprucht die CPU viel stärker. Im Ergebnis kommt der Unterschied in der Anzahl mitrechnender Kerne deutlich zum Tragen: Einer alleine schafft nur etwas mehr als die Hälfte (Abbildung 2). Das Worker-Modul kommt in diesem Versuch mit der Last eine Spur besser zurecht als das alte Prefork-Modul.

Abbildung 2: In Sieges Benchmark-Modus kommt der Server an seine Grenzen. Die Konkurrenz der Prozesse nimmt stark zu, die CPU wird gefordert und die Spreu trennt sich vom Weizen: Ein Core schafft halbe Leistung.

Diese Ergebnisse bestätigen erwartungsgemäß jene Benchmarks besonders eindrucksvoll, die ganz gezielt die Arbeit der CPU bewerten. Hackbench [2] etwa, ein Tool der Kernelhacker, mit dem sie die Fähigkeiten des Prozess-Schedulers im Kernel messen und optimieren. Das Programm generiert einen Client und einen Server, die über eine Softwareleitung miteinander chatten, wobei für jede Verbindung ein neuer Prozess erzeugt wird. Dieser Test weist von Anfang an mit zwei Cores auch die doppelte Leistung aus (Abbildung 3).

Abbildung 3: Hackbench, gemessen auf dem in Abbildung 1 zu sehenden Dualcore-System mit AMDs aktuellem Opteron 2218. Der CPU-lastige Test ergibt rund die doppelte Leistung mit zwei Kernen (orangefarbene Kurve).

Verteilungsfragen

Mit dieser Beobachtung im Hinterkopf liegt die Vermutung nahe, zusätzliche Cores würden jene Programme, die für ihren Hunger nach Rechenleistung bekannt sind, in jedem Fall dramatisch beschleunigen. Wer als Probe beispielsweise die Zeiten beim Rendering mit dem bekannten Open-Source-Renderer Povray misst, stellt jedoch zwischen einem und mehreren Kernen keinen Unterschied fest.

Hier läuft nämlich nur ein Prozess, den das Betriebssystem auch nur einer CPU zuordnet. Davon kann sich leicht überzeugen, wer während des Renderings einmal »mpstat« (aus dem »sysstat«-Paket) aufruft. Es offenbart: Eine CPU ist zu 100 Prozent beschäftigt – die andere tut gar nichts (Abbildung 4). Das ist also die zweite Erkenntnis: Die Last muss sich verteilen lassen, sonst nützen noch so viele Kerne nichts.

Abbildung 4: Povray startet nur einen Prozess und kann deshalb auch nur mit einer CPU arbeiten – eine zweite nützt ihm nichts. Der ebenfalls freie Renderer Blender kann dagegen eine Multicore-Maschine ausnutzen.

Im besten Fall ist bereits die Applikation für Multiprozessing entworfen und optimiert. Wenn nicht, kann man es immerhin noch dem Betriebssystem überlassen, eine Menge von Prozessen auf eine Reihe von CPUs zu verteilen. Das schließt natürlich fremde Prozesse parallel laufender Applikationen und die des Betriebssystems selber mit ein. Wo es aber nur einen einzigen Prozess gibt, da profitiert dieser auch von vielen Kernen nicht. Beim Rendern beispielsweise hilft der Umstieg auf das freie Tool Blender, das von Multicore- oder Mehrprozessor-Systemen profitiert.

Fazit

Viel hilft nicht immer viel. Damit eine Anwendung auf einem Multicore-System tatsächlich schneller läuft, muss sie die CPU nennenswert beanspruchen und verteilbar sein, das heißt, verschiedene Prozesse erzeugen, die gleichzeitig laufen können. Die Applikationen, die normale Bürojobs erledigen, erfüllen diese Anforderungen meist nicht. Und selbst Serverdienste müssen nicht notwendigerweise in diese Klasse fallen, wie der HTTP-Benchmark zeigt. In diesen Fällen bringt ein weiterer Kern keinen Geschwindigkeitszuwachs. Anders sieht es bei gut verteilbaren, rechenintensiven Applikationen aus. Bei denen geht die Post ab.