3.2. Prozessleistung
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.