Die folgenden Anmerkungen zu glibc betreffen Sie nur, wenn Sie MySQL selbst erstellen. Wenn Sie Linux auf einem x86-Computer ausführen, sollten Sie in den meisten Fällen besser unsere Binärdistribution verwenden. Wir verknüpfen unsere Binärdateien zur jeweils am besten gepatchten Version von glibc, die wir finden können, und mit den bestmöglichen Compiler-Einstellungen, um sie so für hochbeanspruchte Server zu optimieren. Für normale Benutzer ist unsere Binärdistribution auch in Setups mit vielen gleichzeitigen Verbindungen oder Tabellen, die die 2-Gbyte-Grenze sprengen, in den meisten Fällen erste Wahl. Wenn Sie nach der Lektüre des folgenden Texts nicht genau wissen, wie Sie vorgehen sollen, probieren Sie zunächst unsere Binärdatei aus, um zu ermitteln, ob diese für Ihre Anforderungen geeignet ist. Sollten Sie feststellen, dass dies nicht der Fall ist, dann sollten Sie eine selbsterstellte Version erproben. In diesem Fall würden wir uns freuen, wenn Sie uns dies mitteilen würden, damit wir beim nächsten Mal eine bessere Binärdistribution erstellen können.

MySQL verwendet LinuxThreads unter Linux. Wenn Sie eine alte Linux-Version verwenden, die glibc2 nicht enthält, dann müssen Sie LinuxThreads installieren, bevor Sie MySQL zu kompilieren versuchen. Sie bekommen LinuxThreads unter http://dev.mysql.com/downloads/os-linux.html.

Beachten Sie, dass glibc-Versionen bis einschließlich 2.1.1 beim Umgang mit pthread_mutex_timedwait(), welches beim Absetzen von INSERT DELAYED-Anweisungen verwendet wird, einen schweren Bug aufweisen. Wir empfehlen Ihnen, INSERT DELAYED erst nach der Aktualisierung von glibc zu verwenden.

Beachten Sie, dass der Linux-Kernel und die LinuxThread-Bibliothek standardmäßig maximal 1024 Threads verwalten können. Wenn Sie mehr als 1000 gleichzeitige Verbindungen vorsehen, dann müssen Sie wie folgt ein paar Änderungen an LinuxThreads vornehmen:

Weitere Informationen dazu, wie Sie Thread-Beschränkungen in LinuxThreads umgehen, finden Sie unter http://www.volano.com/linuxnotes.html.

Es gibt noch ein weiteres Problem, dass die Performance von MySQL insbesondere auf SMP-Systemen erheblich beeinträchtigt. glibc 2.1 weist eine sehr schwache Mutex-Implementierung in LinuxThreads für Programme mit vielen Threads auf, die das Mutex nur für eine kurze Zeit halten. Die Folgen sind paradox: Wenn Sie MySQL mit einer nicht modifizierten LinuxThreads-Version verbinden, können Sie die Leistungsfähigkeit von MySQL in vielen Fällen verbessern, indem Sie Prozessoren aus dem SMP entfernen! Wir haben für glibc 2.1.3 unter http://dev.mysql.com/Downloads/Linux/linuxthreads-2.1-patch einen Patch bereitgestellt, um dieses Verhalten zu korrigieren.

Bei glibc 2.2.2 verwendet MySQL das adaptive Mutex, welches wesentlich besser ist als bei glibc 2.1.3 (auch in der gepatchten Version). Wir wollen aber darauf hinweisen, dass der aktuelle Mutex-Code in glibc 2.2.2 gelegentlich zu viel des Guten tut, wodurch die MySQL-Performance wieder beeinträchtigt wird. Die Wahrscheinlichkeit, dass ein solches Verhalten auftritt, kann dadurch verringert werden, dass man dem Prozess mysqld die höchste Priorität zuweist. Wir konnten das Problem zudem ebenfalls mit einem Patch beheben, den Sie unter http://dev.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch finden. Dieser Patch korrigiert alle drei hier beschriebenen Probleme: das STACK_SIZE-Problem, das Problem der Thread-Beschränkung und das Mutex-Problem. Er muss im Verzeichnis linuxthreads mit patch -p0 </tmp/linuxthreads-2.2.2.patch angewendet werden. Wir hoffen, dass er in irgendeiner Form in zukünftigen Releases von glibc 2.2 enthalten sein wird. In jedem Fall müssen Sie bei der Verknüpfung mit glibc 2.2.2 STACK_SIZE und PTHREAD_THREADS_MAX korrigieren. Wir hoffen, dass die Standardeinstellungen in Zukunft auf Werte korrigiert werden, die für hochbeanspruchte MySQL Server geeigneter sind; in diesem Fall ließen sich die Befehle zur Erstellung eines eigenen Builds auf ./configure; make; make install beschränken.

Wir empfehlen Ihnen, diese Patches zur Erstellung einer speziellen statischen Version von libpthread.a zu verwenden und diese dann nur für die statische Verknüpfung mit MySQL zu verwenden. Wir wissen, dass diese Patches in Verbindung mit MySQL einwandfrei funktionieren und die Leistungsfähigkeit erheblich verbessern, können jedoch nichts zu ihren Auswirkungen auf andere Anwendungen sagen. Wenn Sie andere Anwendungen verknüpfen, die LinuxThreads mit einer anderen als der gepatchten statischen Version der Bibliothek benötigen, oder eine gepatchte gemeinsame Version erstellen und diese auf Ihrem System installieren, dann tun Sie dies auf eigenes Risiko.

Sollten während der Installation von MySQL merkwürdige Probleme auftreten oder bestimmte gängige Hilfsprogramme stehen bleiben, dann ist dies mit hoher Wahrscheinlichkeit durch die Bibliothek oder den Compiler verursacht. Wenn dies der Fall ist, dann können Sie diese Probleme mithilfe unserer Binärdistribution lösen.

Wenn Sie eigene MySQL-Clientprogramme verknüpfen, dann wird unter Umständen die folgende Fehlermeldung zur Laufzeit angezeigt:

ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory

Dieses Problem lässt sich auf eine der folgenden Weisen lösen:

Wenn Sie den Fujitsu-Compiler (fcc/FCC) verwenden, treten unter Umständen Probleme bei der Kompilierung von MySQL auf, weil die Linux-Header-Dateien sehr stark auf gcc ausgerichtet sind. Der folgende configure-Befehl sollte auch für fcc/FCC funktionieren:

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
    -DCONST=const -DNO_STRTOLL_PROTO" \
CXX=FCC CXXFLAGS="-O -K fast -K lib \
    -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE \
    -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
    '-D_EXTERN_INLINE=static __inline'" \
./configure \
    --prefix=/usr/local/mysql --enable-assembler \
    --with-mysqld-ldflags=-all-static --disable-shared \
    --with-low-memory