以下の glibc に関する注釈は MySQL をご自身でビルドする際にのみ適用します。Linux を x86 マシンで使用している場合、弊社のバイナリが多くのケースで最適です。弊社では弊社のバイナリを弊社が知り得るかぎりベストパッチの glibc バージョンにリンクし最高のコンパイラオプションを使用して、高負荷のサーバーに最適なソリューションを目指しています。一般的なユーザーにとって、多数の同時接続あるいは 2 GB の制限を越えるテーブルでの設定においてさえ、弊社のバイナリはそのほとんどのケースで最適な選択といます。以下のテキストを読まれたあとで、それでも何をすべきか分からない場合には、まず弊社のバイナリを試してみてお客様のニーズに合うか決めてください。もし要求を十分満たすことができない場合には、ご自身でビルドしてみることもできます。そのような場合、お客様のご意見を寄せて頂ければ弊社はさらによいバイナリをビルドするための参考にさせて頂きます。

MySQL は Linux に LinuxThread を使用しています。glibc2 を実装していない旧 Linux バージョンを使用している場合には、MySQL をコンパイルする前に LinuxThread をインストールする必要があります。LinuxThreads は、http://dev.mysql.com/downloads/os-linux.html から入手できます。

INSERT DELAYD ステートメントが発行されるときに使用されるバージョン 2.1.1 を含む以前の glibc のバージョンには pthread_mutex_timedwait() の処理で致命的なバグがあります。glibc をアップグレードする前に INSERT DELAYED を使用しないでください。

Linux kernel および LinuxThread ライブラリはデフォルトで最大 1,024 スレッドを扱うことができます。1,000 以上の同時接続を計画している場合には、以下のように LinuxThread を変更する必要があります。

MySQL のパフォーマンスに大きな影響を与える別の問題が、特に SMP システム上であります。glibc 2.1 の LinuxThreads の mutex の実装が mutex をほんの短時間保持する多くのスレッドを使用するプログラムで非常に貧弱です。このことは逆説的な結果を生みます。MySQL を無修正の LinuxThreads にリンクさせる際、SMP からプロセッサを削除すると MySQL パフォーマンスが実質的に多くのケースで改善されます。この動作を修正する glibc 2.1.3 のパッチが利用できるようになっています (http://dev.mysql.com/Downloads/Linux/linuxthreads-2.1-patch)。

glibc 2.2.2 を使用する際、MySQL に adaptive の mutex を使用することによって glibc 2.1.3 にパッチ版を使用するよりはるかによくなります。しかし、使用条件によっては、glibc 2.2.2 の現在の mutex code はオーバースピンし、MySQL パフォーマンスを低下さるので、その点注意が必要です。この現象の再現を mysqld のプロセスを最高度まで再調整することで減らすことができます。http://dev.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch で入手できるパッチを使って、オーバースピン動作を修正することもできます。そのパッチでオーバースピン、スレッドの最大数、およびスタックのスペースをすべて 1 つにまとめるなどの修正を加えています。そのパッチは linuxthreads ディレクトリに patch -p0 </tmp/linuxthreads-2.2.2.patch を適用します。そのパッチを何らかの形で glibc 2.2 の今後のリリースに含めることを希望しています。いずれにしても、glibc 2.2.2 に対してリンクを設定する場合でも、STACK_SIZE および PTHREAD_THREADS_MAX を修正する必要があります。弊社ではデフォルトの値が、今後 MySQL の高負荷設定に対応できるように修正され、お客様ご自身でビルドする際に必要なコマンドが ./configure; make; make install まで減少できるように期待しています。

これらのパッチを使用して特別な静的バージョンの libpthread.a を構築する場合は、MySQL に静的にリンクする場合にのみ使用してください。これらのパッチは MySQL に使用する際は安全でそのパフォーマンスを大幅に改善しますが、ほかのアプリケーションに対する影響についてはなにも言う立場にありません。LinuxThreads をライブラリのパッチ版の静的ベージョンが必要なほかのアプリケーションにリンクする、あるいはパッチ共有バージョンをビルドしそれをお客様のシステムにインストールすることは、お客様ご自身のリスクで行うことになります。

MySQL のインストールの最中に予想外の問題に遭遇した場合、あるいはそれに一般的なユーティリティーのハンギングが伴う場合、それらの問題はライブラリあるいはコンパイラにいずれかに起因するものである確立が高いといえます。このような場合には、弊社のバイナリがその問題を解決します。

お客様ご自身の MySQL クライアントプログラムをリンクさせる場合、ランタイムで以下のエラーが表示される場合があります。

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

この問題は以下のメソッドのいずれかで回避できます。

富士通のコンパイラ (fcc/FCC) を使用する場合、Linux のヘッダーファイルは gcc に特化したものですので MySQL のコンパイルで問題が発生する場合があります。以下の configure 行が fcc/FCC の役に立つはずです。

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