Oft auch als CPU-Leistung, CPU-Zyklen und unter zahlreichen anderen Namen bekannt, ist Prozessleistung die F�higkeit eines Computers Daten zu manipulieren. Prozessleistung variiert mit der Architektur (und der Taktrate) der CPU — normalerweise besitzen CPUs mit h�herer Taktrate und diejenigen, die gr��ere Datentypen unterst�tzen, eine h�here Prozessleistung als langsamere CPUs, welche kleinere Datentypen unterst�tzen.
3.2.1. Fakten �ber Prozessleistung
Hier sind die zwei Hauptfakten �ber Prozessleistung, die Sie im Ged�chtnis behalten sollten:
Prozessleistung ist fix
Prozessleistung kann nicht gespeichert werden
Die Prozessleistung ist ein fixer Wert, daher kann die CPU nur eine bestimmte Geschwindigkeit erreichen. Wenn Sie zum Beispiel zwei Nummern zusammenz�hlen m�ssen (ein Vorgang, bei dem nur eine Maschinen-Instruktion in den meisten Architekturen ben�tigt wird), so kann eine spezielle CPU dies lediglich mit einer Geschwindigkeit tun. Mit wenigen Ausnahmen ist es nicht einmal m�glich die CPU-Rate bei der Bearbeitung von Befehlen zu verlangsamen; die Chancen diese zu erh�hen sind noch geringer.
Prozessleistung ist auch auf eine andere Art fix festgelegt: Sie ist begrenzt/endlich. Die Arten von CPUs, die an irgendeinen Computer angeschlossen werden k�nnen, sind begrenzt. Einige Systeme unterst�tzen eine Vielzahl von verschiedenen CPUs von unterschiedlicher Geschwindigkeit, w�hrend andere Systeme dahingehend �berhaupt nicht upgradbar sind[1].
Prozessleistung kann nicht f�r einen sp�teren Gebrauch gespeichert werden. In anderen Worten bedeutet dies, dass wenn eine CPU 100 Millionen Befehle in einer Sekunde verarbeiten kann, in einer Sekunde Leerlauf gleichzeitig 100 Millionen verarbeitungsw�rdige Befehle verschwendet worden sind.
Wenn wir diese Tatsachen von einer etwas unterschiedlicheren Perspektive aus betrachten, so "produziert" eine CPU einen Strom von ausgef�hrten Befehlen zu einem bestimmten Satz. Und wenn eine CPU ausgef�hrte Befehle "produziert", so bedeutet dies gleichzeitig, dass etwas anderes diese "konsumiert". Der n�chste Abschnitt definiert diese sogenannten Konsumenten.
3.2.2. Konsumenten der Prozessleistung
Es gibt zwei Hauptkonsumenten von Prozessleistung:
Applikationen
Das Betriebssystem selbst
3.2.2.1. Applikationen
Die offensichtlichsten Konsumenten von Prozessleistung sind die Applikationen und Programme, welche Sie vom Computer ausgef�hrt haben m�chten. Von der Kalkulationstabelle bis zur Datenbank, Applikationen sind der Grund daf�r, dass Sie �berhaupt einen Computer besitzen.
Ein Einzel-CPU-System kann immer nur eine Sache auf einmal tun. Deshalb gilt, dass wenn Ihre Applikation gerade l�uft, alles andere auf Ihrem System nicht ablaufen kann. Und nat�rlich umgekehrt — wenn etwas anderes als Ihre Applikation abl�uft, dann steht daf�r Ihre Applikation still.
Aber wie kommt es, dass viele verschiedene Applikationen dem Anschein nach auf einem modernen Betriebssystem gleichzeitig ablaufen? Die Antwort darauf ist, dass es sich dabei um Multitasking-Betriebssysteme (Betriebssysteme mit Mehrprogrammbetrieb) handelt. In anderen Worten erzeugen diese die Illusion, dass mehrere Dinge gleichzeitig geschehen, obwohl dies in Wirklichkeit nicht m�glich ist. Der Trick dabei ist, jedem Prozess einen Bruchteil einer Sekunde Laufzeit auf der CPU zu geben, bevor die CPU an einen anderen Prozess f�r wiederum einen Bruchteil einer Sekunde weitergegeben wird. Wenn diese 'Context-Switches' (�nderungen des Inhaltes) h�ufig genug stattfinden, so wird die Illusion von mehreren gleichzeitig laufenden Applikationen vermittelt.
Nat�rlich f�hren Applikationen auch andere Dinge aus, als lediglich Daten mit Hilfe der CPU zu manipulieren. Diese k�nnen auch auf Benutzereingaben warten und genauso I/O zu Ger�ten ausf�hren, wie z.B. Laufwerken und Grafik-Displays. Wenn diese Ereignisse stattfinden, ben�tigt die Applikation die CPU nicht mehr l�nger. Dann kann die CPU dazu benutzt werden, andere Prozesse oder auch andere Applikationen laufen zu lassen, ohne die wartende Applikation dadurch zu verlangsamen.
Zus�tzlich dazu kann die CPU bei einem anderen Konsumenten von Prozessleistung benutzt werden: dem Betriebssystem selbst.
3.2.2.2. Das Betriebssystem
Es ist schwierig festzustellen, wieviel Prozessleistung vom Betriebssystem selbst aufgebraucht wird. Betriebssysteme benutzen n�mlich eine Mischung aus Prozess-Ebenen-Code und System-Ebenen-Code, um deren Arbeit durchzuf�hren. W�hrend es zum Beispiel einfach ist, mittels Prozess�berwachung festzustellen, was der Prozess, der einen daemon oder service ausf�hrt, gerade tut, ist es weniger einfach festzustellen, wieviel Prozessleistung bei I/O-bezogenen Abl�ufen auf System-Ebene aufgebraucht wird (was normalerweise innerhalb des Kontext des Prozesses geschieht, durch welchen I/O angefordert wird).
Generell ist es m�glich, diese Art von Betriebssystem-Overhead in zwei Typen zu unterteilen:
Betriebssystem Housekeeping
Prozessbezogene Aktivit�ten
Betriebssystem Housekeeping beinhaltet Aktivit�ten, wie zum Beispiel Prozessplanung und Speicherverwaltung, wobei prozessbezogene Aktivit�ten s�mtliche Prozesse beinhalten, die das Betriebssystem selbst unterst�tzen, wie z.B. Prozesse, die systemweites Event-Logging oder I/O-Cache-Flushing abwickeln.
3.2.3. Verbessern eines CPU-Engpasses
Im Falle von unzureichender Prozessleistung f�r die Arbeit, welche erledigt werden muss, haben Sie zwei Optionen:
Die Last reduzieren
Die Kapazit�t erh�hen
3.2.3.1. Die Last reduzieren
Die CPU-Last zu reduzieren, kann auch ohne finanzielle Ausgaben erledigt werden kann. Der Trick dabei ist diejenigen Aspekte der Systemlast zu identifizieren, die sich in Ihrer Kontrolle befinden und die verringert werden k�nnen. Es gibt drei Bereiche, auf die man sich dabei konzentrieren muss:
Betriebssystem-Overhead reduzieren
Applikations-Overhead reduzieren
Applikationen vollst�ndig eliminieren
3.2.3.1.1. Betriebssystem-Overhead reduzieren
Um Betriebssystem-Overhead zu reduzieren, muss die gegenw�rtige Systemlast �berpr�ft werden und festgestellt werden, welche Aspekte zu ungew�hnlichen Overhead-Mengen f�hren. Dies k�nnte beinhalten:
Den Bedarf nach h�ufiger Prozessplanung reduzieren
Die Menge an geleistetem I/O reduzieren
Erwarten Sie keine Wunder. In einem einigerma�en gut konfigurierten System ist es unwahrscheinlich, dass eine gro�e Leistungssteigerung beim Versuch Betriebssystem-Overhead zu reduzieren bemerkt wird. Dies ist damit erkl�rbar, dass ein einigerma�en gut konfiguriertes System, grunds�tzlich nur ein minimale Menge an Overhead zur Folge hat. Wenn Ihr System jedoch z.B. mit zuwenig RAM ausgestattet ist, so kann Overhead reduziert werden, indem der RAM-Engpass ausgeglichen wird.
3.2.3.1.2. Applikations-Overhead reduzieren
Die Reduktion von Applikations-Overhead bedeutet gleichzeitig sicher zu gehen, dass die Applikation alles das besitzt, was diese zum einwandfreien Ablaufen ben�tigt. Manche Applikationen weisen absolut unterschiedliche Verhaltensweisen in verschiedenen Umgebungen auf — eine Applikation kann sich h�chst compute-bound beim Verarbeiten bestimmter Arten von Daten verhalten, was z.B. bei anderen Daten wiederum nicht der Fall ist.
Dabei sollte im Auge behalten werden, dass Sie grunds�tzlich ein gutes Verst�ndnis der Applikationen besitzen m�ssen, die auf Ihrem System laufen, um diese so effizient als m�glich ablaufen lassen zu k�nnen. Oft hat dies zur Folge, dass Sie mit Ihren Benutzern und/oder Entwicklern zusammenarbeiten m�ssen, um Wege herauszufinden, auf denen die Applikationen effizienter ablaufen k�nnen.
3.2.3.1.3. Applikationen vollst�ndig eliminieren
Abh�ngig von Ihrem Unternehmen mag diese Vorgehensweise in Ihrem Fall nicht m�glich sein, da es oft nicht im Verantwortungsbereich eines Systemadministrators liegt, vorzuschreiben welche Applikationen verwendet werden k�nnen und welche nicht. Wenn Sie jedoch Applikationen, welche als sogenannte "CPU-Hogs" (frei �bersetzt als "CPU-Schweine") bekannt sind, ausfindig machen k�nnen, so k�nnen Sie vielleicht doch durchsetzen, dass von deren Verwendung abgesehen wird.
Diese Vorgehensweise involviert mit h�chster Wahrscheinlichkeit nicht nur Sie selbst. Die betroffenen Benutzer sollten auch an diesem Prozess teilhaben d�rfen, da diese in vielen F�llen das Wissen und das politische Durchsetzungsverm�gen besitzen, um die notwendigen �nderungen in der Aufstellung der Applikationen durchzusetzen.
Tipp
Vergessen Sie dabei nicht, dass eine Applikation dabei nicht unbedingt von jedem System in Ihrem Unternehmen entfernt werden muss. Vielleicht sind Sie in der Lage eine speziell CPU-hungrige Applikation von einem �berlasteten System zu einem System zu verschieben, welches kaum in Betrieb ist.
3.2.3.2. Erh�hen der Kapazit�t
Wenn es keine M�glichkeit gibt, die Nachfrage nach Prozessleistung zu reduzieren, dann sind Sie nat�rlich gezwungen, Wege und Mittel zu finden, wie bestehende Prozessleistung erh�ht werden kann. Dies ist zwar mit Kosten verbunden, kann aber jederzeit durchgef�hrt werden.
3.2.3.2.1. Upgraden der CPU
Die einfachste Vorgehensweise ist festzustellen, ob Ihre System-CPU upgegraded werden kann. Der erste Schritt dabei ist festzustellen, ob die gegenw�rtige CPU entfernt werden kann. Einige Systeme (vorwiegend Laptops) haben CPUs, welche angel�tet sind, was ein Upgrade unm�glich macht. Der Rest besitzt jedoch gesockelte CPUs, was Upgrades m�glich macht — zumindest in der Theorie.
Als n�chstes m�ssen Sie ein paar Nachforschungen anstellen, ob eine schnellere CPU f�r Ihre Systemkonfiguration existiert. Wenn Sie zum Beispiel derzeit eine 1GHz CPU besitzen und eine 2GHz Einheit f�r den selben Typ existiert, so w�re ein Upgrade m�glich.
Schlussendlich m�ssen Sie die maximale Taktrate feststellen, die von Ihrem System unterst�tzt wird. Um das obige Beispiel weiterzuf�hren, ist ein einfaches Austauschen der CPU nicht m�glich, sollte Ihr System nur maximal 1 GHz Prozessoren unterst�tzen; auch wenn es eine passende 2GHz CPU gibt.
Sollten Sie keine schnellere CPU installieren k�nnen, so bestehen Ihre M�glichkeiten nur noch aus dem Austauschen von Hauptplatinen oder sogar dem bereits erw�hnte und noch teureren 'Forklift'-Upgrade (g�nzliches Austauschen des Computers).
Einige Systemkonfigurationen machen jedoch eine geringf�gig andere Vorgangsweise m�glich. Anstatt die jeweilige CPU zu ersetzen, warum nicht eine zweite CPU dazugeben?
3.2.3.2.2. Ist Symmetrisches Multiprocessing (Simultanverarbeitung) f�r Sie das Richtige?
Symmetrisches Multiprocessing (auch als SMP bekannt) macht es f�r ein Computersystem m�glich, mehr als eine CPU zu besitzen, welche alle Systemressourcen gemeinsam benutzen. Dies bedeutet, dass im Gegensatz zu einem Uniprozessor-System auf einem SMP-System tats�chlich mehrere Prozesse zur selben Zeit ablaufen k�nnen.
Auf den ersten Blick scheint dies der Traum eines jeden Systemadministrators zu sein. Zuallererst macht es SMP m�glich, die CPU-Leistung eines Systems zu erh�hen, auch wenn CPUs mit schnellerer Taktrate nicht erh�ltlich sind — und dies nur durch das Hinzuf�gen einer weiteren CPU. Jedoch kann diese Flexibilit�t auch Nachteile mit sich bringen.
Als Erstes sind nicht alle Systeme f�r SMP geeignet. Ihr System muss eine Hauptplatine besitzen, welches dazu ausgerichtet ist, mehrere Prozessoren zu unterst�tzen. Wenn dies nicht der Fall ist, so ist (zumindest) ein Hauptplatinen-Upgrade erforderlich.
Der zweiter Widerspruch ist der, dass SMP zur System-Overhead-Steigerung beitr�gt. Es macht auch Sinn, wenn Sie kurz dar�ber nachdenken; mit mehreren CPUs, f�r die Arbeit geplant wird, ben�tigt das Betriebssystem logischerweise auch mehr CPU-Zyklen. Ein anderer Gesichtspunkt ist der, dass es mit mehreren CPUs auch mehr Auseinandersetzungen hinsichtlich der gemeinsam benutzten System-Ressourcen gibt. Deshalb resultiert das Upgraden eines Dual-Prozessor-Systems auf ein Quad-Prozessor-System auch nicht in einer 100prozentigen Steigerung der CPU-Leistungsf�higkeit. Tats�chlich ist es an einem bestimmten Punkt sogar m�glich (abh�ngig von der eigentlichen Hardware, der Arbeitslast und der Prozessorarchitektur), dass durch das Hinzuf�gen eines weiteren Prozessors die Systemleistung sogar verringert wird.
Ein weiterer Punkt, den man dabei im Auge behalten sollte, ist dass SMP nicht hilfreich bei Arbeitslasten in Bezug auf eine monolithische Applikatio mit einer einzigen Ausf�hrungssequenz ist. Wenn also z.B. ein gro�es Simulationsprogramm (h�chst compute-bound) als ein Prozess ohne Threads abl�uft, so l�uft dieser Prozess nicht im Geringsten schneller auf einem SMP-System, als auf einer Einzel-Prozessor-Maschine ab. Tats�chlich kann dieser sogar etwas langsamer ablaufen, was auf den erh�hten Overhead durch SMP zur�ckzuf�hren w�re. Aus diesen Gr�nden entscheiden sich viele Systemadministratoren f�r eine Prozessleistung mit einem einzigen Ausf�hrungsstrom, wenn es zum Thema CPU-Leistung kommt. Dies bietet die h�chste CPU-Leistung und besitzt die wenigsten benutzungsbezogenen Einschr�nkungen.
W�hrend diese Auseinandersetzung mit dem Thema m�glicherweise den Anschein erweckt hat, dass SMP niemals eine gute Idee ist, gibt es Umst�nde, unter denen SMP sehr wohl Sinn macht. Umgebungen, auf denen mehrere Applikationen ablaufen, die sich h�chst compute-bound verhalten, sind Anw�rter f�r SMP. Der Grund daf�r ist, dass Applikationen, die �ber lange Zeitr�ume hinweg nichts anderes tun als zu rechnen, dadurch die Auseinandersetzungen zwischen aktiven Prozessen (und deshalb auch den OS-Overhead) minimal halten, w�hrend der Prozess selbst jede CPU besch�ftigt.
Ein weiterer Punkt, der in Hinblick auf SMP beachtet werden sollte, ist der Umstand, dass die Leistung weitaus eleganter mit steigenden Systemlasten sinkt, als dies ansonsten der Fall w�re. Dies macht SMP in Server und Multi-User Bereichen h�chst popul�r, da der sich st�ndig �ndernde Prozess-Mix auf einer Multi-Prozessormaschine weniger Auswirkungen auf die systemweite Auslastung hat.
Diese Situation f�hrt zu einem humorvoll genannten 'Forklift Upgrade' (Gabelstapler Upgrade), was soviel wie das Ersetzen des gesamten Computers bedeutet.
