96 MySQL - Technische Referenz f¨ur Version 5.0.1-alpha
dieses "Gentleman"-Verhalten forcieren, indem Sie einen vern¨unftigen Wert f¨ur die the
max_connections-Variable setzen.
Wenn Sie MySQL selbst bauen und sich nicht mit dem Patchen von LinuxThreads herum
plagen wollen, sollten Sie max_connections auf einen Wert nicht gr¨oßer als 500 setzen.
Dieser Wert sollte sogar noch kleiner sein, wenn Sie einen großen Schl¨usselpuffer (Key
Buffer), große Heap-Tabellen oder andere Dinge haben, die mysqld dazu bringen k¨onnten,
eine Menge Speicher zu allozieren, oder wenn Sie einen 2.2-Kernel mit einem 2GB-Patch
fahren. Wenn Sie unsere Bin¨ardateien oder RPM-Versionen 3.23.23 oder sp¨ater benutzen,
k¨onnen Sie max_connections sicher auf 1500 setzen, unter der Annahme, dass es keine
großen Schl¨usselpuffer oder Heap-Tabellen mit vielen Daten gibt. Je mehr Sie STACK_SIZE
in LinuxThreads reduzieren k¨onnen, desto mehr k¨onnen Sie sicher Threads erzeugen. Wir
empfehlen einen Wert zwischen 128K und 256K.
Wenn Sie viele gleichzeitige Verbindungen benutzen, bekommen Sie vielleicht Probleme
durch ein "Feature" im 2.2-Kernel, der einen Prozess daf¨ur bestraft, dass er sich
aufspaltet (fork) oder einen Kindprozess klont, um einen Fork-Bombenangriff (Fork
Bomb Attack) zu verhindern. Das bringt MySQL dazu, nicht so gut zu skalieren,
wenn Sie die Anzahl gleichzeitiger Clients erh¨ohen. Wir konnten b eobachten, dass
sich das auf Einprozessor-Systemen mit sehr langsamer Thread-Erzeugung bemerkbar
macht, was sich darin zeigt, dass es sehr lange dauern kann, sich mit MySQL zu
verbinden (bis zu einer Minute), und genau so lange, um es herunter zu fahren. Auf
Multiprozessor-Systemen haben wir einen allm¨ahlichen Abfall der Anfrage-Geschwindigkeit
beobachtet, wenn die Anzahl der Clients zunimmt. Im Verlauf der Suche nach einer
L¨osung haben wir von einem unserer Benutzer einen Kernel-Patch erhalten, von dem
dieser sagt, dass er auf seiner Site eine betr¨achtliche Rolle spielt. Der Patch ist hier
verf¨ugbar (http://www.mysql.com/Downloads/Patches/linux-fork.patch). Inzwischen
haben wir recht ausf¨uhrliche Tests dieses Patchs sowohl auf Entwicklungs- als auch auf
Produktionssystemen gemacht. Er hat die Performance von MySQL erheblich verbessert,
ohne irgend welche Probleme zu verursachen, und wir empfehlen ihn jetzt denjenigen
unserer Benutzer, die immer noch Hochlast-Server auf 2.2-Kerneln fahren. Dieses Problem
wurde im 2.4-Kernel behoben. Wenn Sie daher nicht zufrieden mit der momentanen
Performance Ihres Systems sind, ist es wahrscheinlich einfacher, auf 2.4 zu aktualisieren,
statt den 2.2-Kernel zu patchen, was zus¨atzlich zur Behebung dieses Fairness-Bugs auch
noch Multiprozessor-Systemen einen netten Schub gibt.
Wir haben MySQL auf dem 2.4-Kernel auf einer Zweiprozessor-Maschine getestet und
haben festgestellt, dass MySQL VIEL bessere Leistungsdaten bringt - es gab praktisch
keine Verlangsamung bei Anfragen bis ganz herauf zu 1000 Clients, und der Skalierungsfak-
tor von MySQL (berechnet als Verh¨altnis von maximalem Durchsatz zum Durchsatz mit
1 Client) war 100%.
¨
Ahnliches haben wir auf einer Vierprozessor-Maschine beobachtet -
praktisch keine Verlangsamung, w¨ahrend die Anzahl der Clients bis auf 1000 stieg sowie
ein Skalierungsfaktor von 300%. F¨ur einen unter Hochlast fahrenden Multiprozessor-Server
empfehlen wir daher ausdr¨ucklich den 2.4-Kernel. Weiter haben wir festgestellt, dass es
essentiell wichtig ist, den mysqld-Prozess auf dem 2.4-Kernel mit der h¨ochstm¨oglichen Pri-
orit¨at laufen zu lassen, um maximale Performance zu erreichen. Das kann dadurch erreicht
werden, dass man den renice -20 $$-Befehl zu safe_mysqld hinzuf¨ugt. Bei unseren Tests
auf der Vierprozessor-Maschine ergab die Erh¨ohung der Priorit¨at eine 60%-ige Steigerung
des Durchsatzes bei 400 Clients.
Kommentare zu diesen Handbüchern