Mittwoch Mrz 10, 2010

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.

Mittwoch Apr 22, 2009

MySQL mit Skalierungsnachhilfe

In das neue Release von MySQL (version 5.4) sind ettliche Verbesserungen, u.A. beigetragen von Google, eingeflossen, die die bisher doch eher beschraenkte Skalierbarkeit deutlich verbessern.  Die Verbesserungen sind erheblich, wie man auf einem Graphen von Allan Packer sieht:



Damit wird MySQL nun auch auf CMT-Platformen einsetzbar.  Allerdings bleibt die absolute Leistung dieser Software auf CMT immer noch weit hinter den Leistungen z.B. auf der neuen, natuerlich auch gut 2 Jahre juengeren Nehalem-CPU zurueck.  2 Intel x5500 in der X4275 schaffen mit sysbench ca. 4500 TPS, zwei UltraSPARC T2Plus in der T5240 nur ca. 1600 (Faktor 2.8).  Dieser Abstand ist deutlich groesser als z.b. bei SPECjbb2005 (554976 zu 388456, Faktor 1.43) oder SPECint_rate2006 (255 zu 157, Faktor 1.62) .  Es scheint also noch einiges an Potential in MySQL zu stecken...

Montag Okt 13, 2008

Aus zwei mach vier

Gestern wurde die neue 4-Sockel Maschine T5440 vorgestellt.  Im April war es die T5240 mit zwei Sockeln.  Nun stehen uns mit 4 CPUs mit je 8 Kernen mit je 8 Strands insgesamt 256 Strands zur Verfuegung - mit der entsprechenden Leistungsfaehigkeit.  Dass es da schon schwierig wird, diese Leistung auch zu nutzen, wurde uns bei den Beta-Tests, die es auch diesmal wieder gab bereits deutlich.  Und zwar nicht etwa, weil die Software nicht so gut skaliert, sondern weil es schwierig ist, genug Last zu finden :-)


In einem Fall gingen uns einfach die Lasttreiber aus - es waren nur Loadrunner-Lizenzen fuer 1500 Benutzer vorhanden, und die reichten bei der Datenbank-Anwendung gerade mal fuer 8% CPU-Auslastung.  Die Leistung der Anwendung war dabei natürlich auf dem geforderten Niveau.


Auch bei Strato, einem bekanntermaßen erfolgreichen Anwender der CMT Technologie, war eine T5440 vor Ort.  Das Ergebnis: Eine T5440 ist einfach zu leistungsstark...


"The system was so fast we really had problems to utilize all available
CPU power. Even one of those systems would be fast enough as a pop or
imap server for all our customers, so we had to use it as an http server
 (we are still using old apache 1.3, which does not scale as good as
apache 2.x). So in the future we will have to think about zones or ldoms
to break these large boxes into smaller units that are easier to manage
for us"


Diese Erkenntnis werden sicher auch viele Andere noch haben: Um eine 4-Sockel CMT Maschine voll auszulasten benoetigt man oftmals mehr als nur eine Anwendung.  Und falls man diese nicht gemeinsam im selben Solaris betreiben will oder kann, bieten sich natuerlich Zonen oder LDoms als Virtualisierungsmoeglichkeiten an.  Gut, dass die Maschine auch ausreichen viel RAM unterstuetzt!


Eine Uebersicht weiterer Blogs zur Einfuehrung gibt es bei meinem Kollegen Allan Packer.

Freitag Okt 10, 2008

Unerwartete Parallelisierung - Threads all ueberall

SPECint2006 ist, anders als der auf Skalierung setzende SPECint_rate2006 ein CPU-Benchmark, der die Singlethread-Leistung einer CPU misst.  Doch seit auch Intel und AMD erkannt haben, dass Taktfrequenzsteigerungen keine Leistungssteigerungen mehr bringen, wird in den Entwicklungsabteilungen der Compilerbauer intensiv, und offenbar erfolgreich, an den Parallelisierungsmoeglichkeiten der Compiler gearbeitet.  Und diese Arbeit bringt nun erste Fruechte, zu sehen an den neuesten Ergebnissen von SPECint2006.  Mein Kollege Lawrence Spracklen hat sie untersucht.  Sein Fazit: "So much for single-threaded performance improvements :-)"  Mein Fazit: Die Einsatzgebiete von CMT-Technologie werden durch die Kombination dieser Entwicklung mit der zunehmenden Verbreitung paralleler Programmiertechniken immer universeller werden.  Und daß sich auch bei diesen Programmiertechniken einiges tut, kann man an der baldigen Verfuegbarkeit von Transactional Memory sehen...

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