mysql.server finden Sie im Verzeichnis support-files, das sich im MySQL-Installationsverzeichnis befindet, oder in einem MySQL-Source-Tree. Sie können es als /etc/init.d/mysql installieren, um MySQL automatisch zu starten und zu beenden. Siehe auch Abschnitt 2.9.2.2, „MySQL automatisch starten und anhalten“.

Wenn MySQL nicht genügend Dateien oder Verbindungen öffnen kann, haben Sie Linux möglicherweise nicht so konfiguriert, dass es genug Dateien verwalten kann.

Unter Linux 2.2 und höher können Sie die Anzahl zugewiesener Datei-Handles wie folgt überprüfen:

shell> cat /proc/sys/fs/file-max
shell> cat /proc/sys/fs/dquot-max
shell> cat /proc/sys/fs/super-max

Wenn Sie mehr als 16 Mbyte Speicher haben, sollten Sie Ihre Skripten durch einen Zusatz in der Art des folgenden ergänzen (z. B. /etc/init.d/boot.local unter SuSE Linux):

echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

Sie können die echo-Befehle auf der Befehlszeile auch als root ausführen, aber diese Einstellungen gehen beim nächsten Neustart Ihres Computers verloren.

Alternativ stellen Sie diese Parameter für den Start mithilfe des Tools sysctl ein, welches von vielen Linux-Distributionen (einschließlich SuSE Linux 8.0 und höher) verwendet wird. Tragen Sie die folgenden Werte in eine Datei namens /etc/sysctl.conf ein:

# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024

Außerdem sollten Sie Folgendes in /etc/my.cnf ergänzen:

[mysqld_safe]
open-files-limit=8192

Auf diese Weise konfigurieren Sie für den Server eine Gesamtbeschränkung der Verbindungen und offenen Dateien auf 8192.

Die Konstante STACK_SIZE in LinuxThreads steuert das Spacing von Thread-Stapeln im Adressraum. Dieses muss groß genug sein, um genügend Raum für jeden einzelnen Thread-Stapel bereitzustellen, aber auch klein genug, um zu verhindern, dass der Stapel bestimmter Threads mit den globalen mysqld-Daten kollidiert. Leider trennt, wie wir durch Experimentieren festgestellt haben, die Linux-Implementierung von mmap() einen bereits zugeordneten Bereich wieder auf, wenn Sie sie anweisen, die Zuordnung einer derzeit verwendeten Adresse aufzulösen: Es wird kein Fehler zurückgegeben, sondern alle Daten auf der gesamten Seite werden auf null gesetzt. Insofern hängt die Sicherheit von mysqld und allen anderen Thread-basierten Anwendungen vom „wohlwollenden“ Verhalten des Codes ab, der die Threads erstellt. Der Benutzer muss Maßnahmen ergreifen, um sicherzustellen, dass die Anzahl laufender Threads jederzeit so niedrig ist, dass es nicht zum Konflikt zwischen den Thread-Stapeln und dem globalen Bereich kommt. Bei mysqld sollten Sie dieses Verhalten erzwingen, indem Sie der Variablen max_connections einen sinnvollen Wert zuweisen.

Wenn Sie MySQL selbst erstellen, können Sie LinuxThreads für eine bessere Stapelnutzung patchen. Siehe auch Abschnitt 2.12.1.3, „Anmerkungen zur Linux-Quelldistribution“. Wenn Sie LinuxThreads aber nicht patchen wollen, sollten Sie max_connections auf einen Wert von maximal 500 setzen. Arbeiten Sie mit einem großen Schlüsselpuffer, großen Heap-Tabellen oder anderen Materialien, die zu einer umfassenden Speicherzuweisung durch mysqld führen, oder verwenden Sie die Kernel-Version 2.2 mit einem 2-Gbyte-Patch, dann sollte der Wert noch kleiner sein. Wenn Sie unsere Binär- oder RPM-Version verwenden, können Sie max_connections beruhigt auf 1500 setzen, sofern Sie weder große Schlüsselpuffer noch datenintensive Heap-Tabellen benutzen. Je stärker Sie STACK_SIZE in LinuxThreads verringern, desto mehr Threads können Sie gefahrlos erstellen. Wir empfehlen Werte zwischen 128 und 256 Kbyte.

Wenn Sie zahlreiche nebenläufige Verbindungen verwenden, können Sie einem „Feature“ im Kernel 2.2 zum Opfer fallen, das Fork-Bomb-Angriffe verhindern soll, indem Prozesse, die untergeordnete Prozesse aufspalten oder klonen, eine Strafe erhalten. Hierdurch wird die Skalierbarkeit zunehmend beeinträchtigt, je größer die Anzahl nebenläufiger Clients ist. Auf Systemen mit nur einem Prozessor manifestiert sich dies unseren Beobachtungen zufolge in einer sehr langsamen Thread-Erstellung: Die Verbindungsherstellung mit MySQL kann sehr lange (bis zu einer Minute) dauern; Gleiches gilt für das Abbauen der Verbindung. Auf Multiprozessorsystemen haben wir bei steigender Clientanzahl eine allmähliche Abnahme der Abfragegeschwindigkeit feststellen können. Im Zuge der Lösung dieses Problems haben wir von einem unserer Benutzer einen Kernel-Patch erhalten, der seinen Angaben zufolge auf seiner Site geholfen haben soll. Dieser Patch ist unter http://dev.mysql.com/Downloads/Patches/linux-fork.patch verfügbar. Wir haben den Patch sowohl in Entwicklungs- als auch in Produktionssystemen umfassend getestet und festgestellt, dass sich die MySQL-Performance hierdurch erheblich verbessert, ohne dass es zu Problemen kommt. Deswegen empfehlen wir Benutzern, die hochbeanspruchte Server mit Kernel-Version 2.2 betreiben, seine Anwendung.

In der Kernel-Version 2.4 wurde das Problem behoben; wenn Sie also nicht mit der aktuellen Leistungsfähigkeit Ihres Systems zufrieden sind, ist es unter Umständen einfacher, ein Upgrade auf Version 2.4 durchzuführen, statt Ihren 2.2-Kernel zu patchen. Auf SMP-Systemen erhalten Sie neben der Problembehandlung zusätzlich noch eine beträchtliche SMP-Steigerung.

Wir haben MySQL mit dem Kernel 2.4 auf einem System mit zwei Prozessoren getestet und festgestellt, dass sich MySQL wesentlich besser skalieren lässt. Es gab im gesamten Testbereich bis 1000 Clients praktisch keine Verringerung des Abfragedurchsatzes, und der MySQL-Skalierungsfaktor (berechnet als Verhältnis des maximalen Durchsatzes zum Durchsatz pro Client) lag bei 180 %. Ähnliche Ergebnisse konnten wir auf einem System mit vier CPUs beobachten: praktisch keine Verlangsamung, während die Anzahl der Clients auf 1000 erhöht wurde, und dazu ein Skalierungsfaktor von 300 %. Basierend auf diesen Ergebnissen empfehlen wir für hochbeanspruchte SMP-Server mit dem Kernel 2.2 derzeit in jedem Fall eine Aktualisierung auf Kernel 2.4.

Unseren Beobachtungen zufolge ist es unumgänglich, den Prozess mysqld unter dem Kernel 2.4 mit höchstmöglicher Priorität auszuführen, um maximale Leistung zu erzielen. Dies ist möglich, indem der Befehl renice -20 $$ zu mysqld_safe hinzugefügt wird. Bei unseren Tests mit einem 4-CPU-Rechner haben wir eine 60-prozentige Durchsatzsteigerung bei 400 Clients erzielt.

Ferner versuchen wir derzeit auch, weitere Informationen dazu zu sammeln, wie gut MySQL mit dem Kernel 2.4 auf 4-Wege- und 8-Wege-Systemen funktioniert. Wenn Sie Zugang zu einem solchen System haben und einige Benchmarks erstellt haben, möchten wir Sie bitten, eine E-Mail mit den Ergebnissen an <benchmarks@mysql.com> zu senden. Wir werden diese prüfen und ggf. in das Handbuch aufnehmen.

Wenn Sie einen abgestürzten mysqld-Serverprozess mit ps erkennen, dann weist dies normalerweise darauf hin, dass Sie einen Bug in MySQL entdeckt haben oder eine Tabelle beschädigt ist. Siehe auch Abschnitt A.4.2, „Was zu tun ist, wenn MySQL andauernd abstürzt“.

Um, wenn mysqld mit einem SIGSEGV-Signal abstürzt, unter Linux einen Speicherauszug zu erhalten, können Sie mysqld mit der Option --core-file starten. Beachten Sie, dass Sie wahrscheinlich auch die Größe der Speicherauszugsdatei erhöhen müssen, indem Sie ulimit -c 1000000 zu mysqld_safe hinzufügen oder mysqld_safe mit --core-file-size=1000000 starten. Siehe auch Abschnitt 5.4.1, „mysqld_safe — Startskript für den MySQL-Server“.