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

MySQL は Linux に LinuxThread を使用しています。glibc2 を実装していない旧 Linux バージョンを使用している場合には、MySQL をコンパイルする前に LinuxThread をインストールする必要があります。LinuxThread は 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 を変更する必要があります。

LinuxThreads のスレッド制限の回避法の詳細は http://www.volano.com/linuxnotes.html にあります。

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 にあります。そのパッチでオーバースピン、スレッドの最大数、およびスタックのスペースをすべて一つにまとめるなどの修正を加えています。そのパッチは 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