Ein paar Gedanken zu Skalierbarkeit


Vor einigen Tagen gab es auf einem internen Verteiler ein Diskussion ueber Skalierbarkeit, und warum Solaris besonders gut darin ist.  Einige alt-gediente Performance-Meister fassten das Thema so bemerkenswert gut zusammen, dass ich diese Zusammenfassung gerne einem breiteren Publikum zugaenglich machen moechte.  Sie waren einverstanden, deswegen:


Was ist Skalierbarkeit, und warum ist Solaris so gut darin, Anwendungen nicht am skalieren zu hindern?
Gute Skalierbarkeit ist eine klassische Beobachtung bei Systemen, die ueber Jahre hinweg optimiert wurden.  Diese Systeme habe nicht nur eine gute Leistung bei hoher Last, sondern diese Leistung degeneriert bei Ueberlast auch weniger.


Der Grund dafuer wird meistens mathematisch beschrieben:  Die Steigung der Kurve der Antwortzeit (Degeneration) wird dominiert durch die Antwortzeit der einen, langsamsten Komponente.  Ein neues Produkt hat normalerweise ein paar wenige, grosse Flaschenhaelse.  Und weil sie so gross sind, steigt die Antwortzeit-Kurve fruehzeitig in Richtung Unendlichkeit, und ist dabei sehr steil und gerade.


Ein solches System auch nur ein wenig zu ueberlasten wirkt wie ein "Gegen die Wand fahren" - das System haengt scheinbar.  Wenn man die Last auf der X-Achse, und die Antwortzeit auf der Y-Achse auftraegt, sieht das ungefaehr so aus:



Das heisst in unserem Metier die "Hockey-Stick" Kurve ;-)  Die Antwortzeit ist anfangs recht flach, bis zu einem Wendepunkt, ab dem die Kurve gen Himmel steigt wie ein Engel mit Heimweh.


Ein gut optimiertes, ausgereiftes Produkt hingegen hat viele kleine Flaschenhaelse.  Einer davon ist der groesste, und dieser bestimmt die Position und Steigung des Wendepunkts.  Bei einem entsprechend kleinen Flaschenhals ist die Steigung flach.  Bei Ueberlast erlebt der Benutzer ein solches System als langsam oder zaeh, aber nicht als haengend.  Grafisch sieht das dann etwa so aus:



Nicht optimierte oder wenig ausgereifte Programme zeigen ab ca. 80% Auslastung haeufig schlechte Leistung.  Ein haeufiger Grund dafuer ist, dass die Wahrscheinlichkeit fuer wirklich gleichzeitige Anfragen hoch ist, und diese die Software kurzfristig an den Wendepunkt hin zur Degeneration fuehren.  Da das System nicht-optimal ist, ist der Grad der Degeneration hoch und entsprechend fuer den Benutzer sichtbar.  Diese Situation tritt typischerweise bei ca. 70% - 80% Last auf, manchmal auch frueher.


Wir haben in der Entwicklung von Solaris seit Jahren erfolgreich Jagd auf auch die kleinsten Flaschenhaelse gemacht.  Entsprechend ist der Anstieg unserer Degenerations-Kurve sehr sehr sanft.  PCs, auf der anderen Seite, haben eine Tendenz, schnell und haeufig gegen die Wand zu fahren.  Ein Teil ihrer ja bereits legendaeren Unzuverlaessigkeit ist allerdings nicht echt: Manche Benutzer ueberlasten die Maschine, vermuten wegen der extrem langen Antwortzeiten einen Haenger oder Absturz, und booten neu...


Ein haeufig genannter Grund fuer die hervorragenden Skalierungseigenschaften von Solaris sind seine sehr feinkoernigen Spin-Locks.  Grobkoernige Locks verlaengern die Antwortzeiten von eigentlich seriellen Locks mit der zu erwartenden Auswirkung entsprechend Amdahl's Law.  Durch seine ueber die Jahre entwickelte Plattform-Kenntnisse traegt insbesondere der Solaris Scheduler stark zur Skalierbarkeit von Solaris bei.  Auch andere Features wie diverse AIO Optionen und Preemption-Kontrolle wie sie bspw. in Oracle integriert wurden sind weitere Gruende fuer die gute Skalierbarkeit.


Desweiteren geht es bei Skalierung, insbesondere \*guter\* Skalierung, nicht nur um hohen Durchsatz und die durchschnittliche Antwortzeit als Funktion der Last.  Gute Skalierbarkeit fuehrt haeufig auch zu einer geringeren Varianz in der Antwortzeit, die der Benutzer als hoehere Zuverlaessigkeit erlebt, sowie zu der erwaehnten sanften Degeneration jenseits der Saettigung.  Diese Faktoren sollten viel oefter gemessen und besprochen werden.  Leider konzentriert sich die Benchmark-Welt viel zu sehr auf die eine Zahl des hoechsten Durchsatzes.


Als letztes:  Die Grundlage fuer all dies wurde gelegt, als Sun (in den 90er Jahren) seine Version von SVR4 definierte.  Wir haben die Implementierung von AT&T mehr oder weniger vollstaendig durch unsere eigene Vorstellung von voller Preemption, Multi-Threading und dem ganzen Rest ersetzt.  Wenn die Grundlage stimmt, ist es so viel einfacher, darauf aufbauend andere Dinge zu bauen.  Wenn man bei jedem neuen Feature die Grundlage umbauen muss, ist das sehr viel muehsamer.  


Die Folge:  Grosse Server auf einer hervorragenden Grundlage fuehrt zu Kunden, die immer noch mehr Arbeit auf die Server bringen, was neue Probleme aufzeigt die wir loesen, was zu Kunden fuehrt, die noch mehr Arbeit auf die Maschinen bringen...


Wenn man das ganze live erleben moechte, hier die Zutaten fuer eine Live-Demo:
Perfbar oder den Gnome perfmeter als Anzeige der CPU-Auslastung.  Auch ein Textfenster mit mpstat reicht dafuer aus.  Dann noch eine interaktive Anwendung als Gradmesser fuer die "gefuehlte" Performance.  Hier bietet sich z.B. die Java2D-Demo an, die mit jedem JDK-Release ausgeliefert wird.  Nun den Rechner unter Last setzten, bspw. mit mehreren endlos laufenden encrypt-Kommandos.  Sichtbare Verschlechterung der interaktiven Anwendung wird es erst sehr nahe an 100% geben ;-)


Die Steigerung hiervon ist, die interaktive Anwendung mittels Solaris Resource Manager mit bspw. 80% CPU auszustatten und die Menge der Hintergrundjobs immer weiter zu steigern.  Selbst erfahrene Techniker kommen hierbei immer wieder ins Staunen.  Problematisch an dieser zweiten Demo koennte sein, dass der eine oder andere anfaengt, an einen Trick zu glauben...  


Dieser Artikel wurde aus mehreren Email-Beitraegen zusammengestellt.  Die Autoren sind:

David Collier-Brown
James Litchfield
Bob Sneed

Vielen Dank hierfuer!
(Die englische Originalfassung gibt es im englischsprachigen Teil dieses Blogs.  Die deutsche Uebersetzung ist von mir.

Kommentare:

Senden Sie einen Kommentar:
Kommentare sind ausgeschaltet.
About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute