Eine unzweckmäßige Konfiguration oder Fehler in den Applikationen haben sicher eine größere Auswirkung auf die Performance als das Drehen an einer exotischen Schraube im Kernel. Ähnliches trifft beispielsweise auch auf die Optimierung von SQL-Abfragen im Vergleich zum Tunen der internen Datenbank-Einstellungen zu. Eine verkorkste Architektur oder ungünstige Algorithmen sind mit Parameter-Tuning nicht wettzumachen.
Zudem sind moderne Betriebssysteme in der Lage, sich verschiedenen Bedingungen selbstständig und dynamisch anzupassen, sodass dort keine Justierung von Hand mehr nötig ist. Ein weithin bekanntes Beispiel sind etwa die gleitenden Fenster (Sliding Windows) bei der TCP-Flusskontrolle, die eine automatische Anpassung an die Fehlerrate während der Übertragung ermöglichen. Ähnlich verhält es sich mit den lastabhängigen Taktraten moderner CPUs.
Diese Adaptionsfähigkeit bewirkt zugleich eine erhöhte Komplexität und untergräbt zum Teil Annahmen, die einfachen Faustformeln zugrunde liegen, auf die man sich früher verlassen konnte. Da rechnete man beispielsweise mit einem eingeschwungenen Zustand (steady state), einer konstanten Servicezeit oder einer zufälligen Verteilung der Anforderungen über die Zeit. Schwankt nun aber beispielsweise die Taktrate der CPU oder bucht ein virtueller Server bei Bedarf CPUs hinzu, wird die Annahme falsch, dass eine bestimmte Aufgabe immer eine reproduzierbare Zeit für ihre Erledigung braucht. Rechnet man dann beispielsweise mit einer Auslastung von 30 Prozent bei 3 GHz, erhält man tatsächlich 70 Prozent Auslastung bei 1,5 GHz, auf die die CPU zum Stromsparen zurückgeschaltet hat. Dies exakt vorauszuberechnen ist bis heute unmöglich.
Trotzdem ist man nicht machtlos. Wer sich auf die überschaubaren Probleme beschränkt und diese mit solidem Know-how systematisch angeht, wird Leistungsreserven erschließen können.
Infos