glibc に関する以下の注意事項は、MySQL を自分でビルドする場合にのみ適用されます。x86 マシン上で Linux を実行している場合、当社が提供するバイナリを使用する方がはるかに適切です。当社のバイナリは、高負荷なサーバに適したものするために、最適なコンパイラオプションを使用して、当社が考案した最適なパッチ適用済みバージョンの glibc をリンクしています。一般のユーザにとって、多数の同時接続や 2GB の制限を超えるテーブルがある構成であっても、ほとんどの場合、当社のバイナリは最良の選択です。以下のテキストを読んで、どうすべきか判断がつかない場合は、最初に当社のバイナリを試して自社の要件を満たすかどうかを確認し、十分でないことがわかった場合にのみ独自のビルドを検討してください。その場合は、不足な点を当社にお知らせください。次回のバイナリのビルドの際に参考にさせていただきます。

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

注意: SMP システム上の Linux 2.2.14 と MySQL で未知の問題が発生したことがあります。SMP システムを使用している場合は、できるだけ速やかに Linux 2.4 にアップグレードすることをお勧めします。これによって、システムの処理速度と安定性が向上します。

注意: バージョン 2.1.1 以前のバージョンの glibc は、INSERT DELAYED ステートメントを発行したときに使用される pthread_mutex_timedwait 処理に重大なバグがあります。glibc をアップグレードするまでは、INSERT DELAYED を使用しないことをお勧めします。

1,000 を超える同時接続を予定している場合は、LinuxThreads にいくつかの変更を加えて再コンパイルし、新しい libpthread.a を MySQL に再リンクする必要があります。 sysdeps/unix/sysv/linux/bits/local_lim.h の PTHREAD_THREADS_MAX を 4096 に増やし、linuxthreads/internals.h の STACK_SIZE を 256 KB に減らしてください。このパスは glibc のルートからの相対パスです。 注意: STACK_SIZE がデフォルト値の 2MB である場合、MySQL は約 600 〜 1,000 接続で不安定になります。

MySQL が十分な数のファイルまたは接続を開けない場合は、その数のファイルを処理するように Linux を設定していない可能性があります。

Linux 2.2 以降では、以下を実行して、割り当てられているファイルハンドルの数をチェックできます。

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

16 MB を超えるメモリがある場合は、init スクリプト（SuSE Linux の /etc/init.d/boot.local など）に以下のような記述を追加してください。

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

root アカウントでコマンドラインから上記のコマンドを実行することもできますが、次回にコンピュータがリブートしたときにそれらの設定は失われます。

あるいは、sysctl ツールを使用して、ブート時に以下のパラメータを設定することもできます。このツールは、多くの Linux ディストリビューションで使用されています（SuSE Linux 8.0 以降、SuSE でもこのツールが追加されています）。/etc/sysctl.conf という名前のファイルに以下の値を入力してください。

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

/etc/my.cnf に以下を追加する必要もあります。

[mysqld_safe]
open-files-limit=8192

これによって、MySQL は最大で 8,192 の接続およびファイルを作成できるようになります。

LinuxThreads の STACK_SIZE 定数は、アドレス空間でのスレッドスタックのスペーシングを制御します。アドレス空間は、個別のスレッドのスタックに十分なスペースを提供できる程度に大きくなければなりませんが、いくつかのスレッドのスタックがグローバルな mysqld データにぶつからない程度に小さくなければなりません。mmap() の Linux 実装は、すでに使用されているアドレスをマップアウトするように指示されると、エラーを返さずに、マップ済みの領域を正常にマップ解除して、ページ全体のデータを消去することが実験でわかっています。mysqld やその他のスレッドアプリケーションの安全性は、スレッドを作成するコードの "紳士的な" 動作にかかっています。ユーザは、任意の時点で稼動しているスレッドの数が、スレッドスタックがグローバルヒープから離れていられる程度に小さくなるようにするための措置をとる必要があります。mysqld では、max_connections 変数に適切な値を設定してこの "紳士的な" 動作を強制する必要があります。

自分で MySQL をビルドする場合、LinuxThreads にパッチを適用する作業をしたくなければ、max_connections を 500 以下の値に設定してください、大きなキーバッファや大きなヒープテーブルなど、mysqld が大量のメモリを割り当てなければならないものがある場合や、2G のパッチが適用された 2.2 カーネルを実行している場合は、さらに小さな値を設定します。当社のバイナリまたは RPM バージョン 3.23.25 以降を使用している場合は、大量のデータを持つキーバッファまたはヒープテーブルがなければ、max_connections を 1500 に設定しても大丈夫です。LinuxThreads の STACK_SIZE の値を小さくすればするほど、スレッドを支障なく作成できるようになります。128K から 256K までの範囲の値を推奨します。

多数の同時接続を使用する場合、fork 爆弾攻撃を避けるために、子プロセスの fork や複製のプロセスにペナルティを科すという、2.2 カーネルの "機能" に悩まされることがあります。これにより、同時実行クライアントの数を増やすと、MySQL がうまくスケールしなくなります。シングル CPU システムでは、スレッド生成が非常に遅くなることでこれが明らかになりました。これは、MySQL に接続するのに長い時間がかかり（1 分程度）、接続を切断するのにも同じだけ時間がかかることを意味します。マルチ CPU システムでは、クライアント数の増加に伴って、クエリ速度が徐々に落ちていくのが観測されました。解決法を見つける過程で、ユーザの 1 人からカーネルパッチを受け取りました。このユーザのサイトではこのパッチが大きな効果を上げているということでした。このパッチは、http://www.mysql.com/Downloads/Patches/linux-fork.patch で入手できます。当社は、開発システムと実稼動システムの両方で、このパッチに非常に広範囲に及ぶテストを実行しました。このパッチは、何の問題も引き起こすことなく MySQL のパフォーマンスを大幅に向上させました。2.2 カーネル上で高負荷のサーバを実行しているユーザに、このパッチをお勧めします。2.4 カーネルではこの問題は修正されています。したがって、システムの現在のパフォーマンスに満足していない場合は、2.2 カーネルにパッチを適用するよりも、2.4 カーネルにアップグレードする方が簡単です。2.4 カーネルは、この公正バグが修正されたほかに、優れた SMP ブーストも提供します。

2 CPU マシンでバージョン 2.4 上の MySQL をテストした結果、MySQL のスケーラビリティが非常に向上することがわかりました。1,000 クライアントに達するまでクエリスループットが低下することは実質的に皆無で、MySQL のスケーリングファクタ（1クライアントでのスループットに対する最大スループットの比率として算出される）は 180% でした。 4 CPU システムでも同様の結果が観察されました。クライアント数が 1,000 に達するまで実質的に速度低下はなく、スケーリングファクタは 300% でした。したがって、高負荷 SMP サーバの場合は、現時点で 2.4 カーネルを使用することを強くお勧めします。最大パフォーマンスを達成するには、2.4 カーネル上で最も高い優先順位を設定して mysqld プロセスを実行することが不可欠であることがわかりました。 これを行うには、renice -20 $$ コマンドを mysqld_safe に追加します。4 CPU マシン上でのテストでは、優先順位を高くすると、400 クライアントでのスループットが 60% 増加しました。

また、現在、当社は、4-way システムおよび 8-wayシステムで 2.4 カーネル上の MySQL のパフォーマンスがどれだけ向上するかについての情報を収集中です。このようなシステムにアクセスでき、何らかのベンチマークを行った場合は、結果を http://www.mysql.com/company/contact/ にお送りください。将来、このマニュアルにそれらの結果を記載します。

特に SMP システム上で顕著な、MySQL のパフォーマンスを大きく損なうもう 1 つの問題があります。glibc-2.1 の LinuxThreads の相互排他ロック（mutex）の実装は、短時間だけ相互排他ロックを保持する多数のスレッドを持つプログラムに悪影響を及ぼします。皮肉なことに、SMP システムでは、MySQL を未修正の LinuxThreads にリンクしている場合、多くの場合、マシンからプロセッサを取り外すと MySQL のパフォーマンスが向上します。当社は、この動作を修正するための、glibc 2.1.3 用のパッチを用意しました（http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch）。

MySQL バージョン 3.23.36 は、glibc-2.2.2 のアダプティブロックを使用します。これは、glibc-2.1.3 のパッチ適用済みの相互排他ロックよりもさらに適切です。ただし、状況によって glibc-2.2.2 の現在の相互排他ロックのコードはオーバースピンし、これによって MySQL のパフォーマンスは損なわれるということに注意してください。mysqld プロセスの優先順位を最も高いものに変更することで、この状況が発生する可能性を下げることができます。オーバースピン動作は、パッチで修正することもできました。このパッチは、http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch で入手できます。 このパッチは、オーバースピン、スレッドの最大数、およびスタックスペーシングの修正を一体化したものです。patch -p0 </tmp/linuxthreads-2.2.2.patch の linuxthreads ディレクトリでパッチを適用する必要があります。 glibc-2.2 の将来のリリースに何らかの形でこのパッチが組み込まれることが望まれます。いずれにしても、glibc-2.2.2 にリンクしている場合は、STACK_SIZE と PTHREAD_THREADS_MAX を修正する必要があります。将来、デフォルトが高負荷の MySQL 設定として許容できる値に修正されて、その結果ユーザ自身のビルドが ./configure; make; make install まで減ることが望まれます。

上記のパッチを使用して libpthread.a の静的ライブラリを別にビルドし、MySQL に静的にリンクするためにのみ使用することをお勧めします。これらのパッチが MySQL にとって安全であり、MySQL のパフォーマンスを大幅に向上させることはわかっていますが、その他のアプリケーションについてはわかっていません。その他のアプリケーションをこのライブラリのパッチ適用済みバージョンにリンクする場合や、パッチ適用済みの共有バージョンをビルドしてシステムにインストールする場合は、LinuxThreads に依存するその他のアプリケーションに関してはユーザ自身の責任で行ってください。

MySQL のインストール時に未知の問題が発生した場合や、一般的なユーティリティがハングした場合は、それがライブラリまたはコンパイラに関連するものである可能性が高いです。その場合は、当社のバイナリを使用することでそれらの問題は解決されます。

バイナリディストリビューションの既知の問題の 1 つは libc を使用する旧バージョンの Linux システム（Red Hat 4.x や Slackware など）に関連するもので、ホスト名解決で重大ではない問題がいくつか発生します。 See 項2.6.2.1. 「Linux の注意事項 （バイナリディストリビューション）」。

LinuxThreads を使用している場合は、最小で 3 つのプロセスが稼動しているのが確認されます。これらは、実際はスレッドで、1 つは LinuxThreads マネージャ用のスレッド、1 つは接続を処理するスレッド、1 つはアラームとシグナルを処理するスレッドです。

注意: Linux カーネルと LinuxThreads ライブラリは、デフォルトでは 1,024 のスレッドしか持つことはできません。したがって、パッチ未適用のシステムでは、MySQL への接続は最大で 1,021 しか使用できません。この制限を回避する方法については http://www.volano.com/linuxnotes.html ページを参照してください。

ps で dead 状態の mysqld デーモンプロセスが表示された場合は、通常は、MySQL にバグがあるか、壊れたテーブルがあることを意味します。 See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。

SIGSEGV シグナルで mysqld が停止した場合に Linux 上でコアダンプを取得するには、--core-file オプションを指定して mysqld を起動します。注意: ulimit -c 1000000 を mysqld_safe に追加するか、--core-file-size=1000000 を指定して mysqld_safe を起動して、コアファイルのサイズを増やします。 See 項4.8.2. 「mysqld_safe（mysqld のラッパ）」。

独自の MySQL クライアントをリンクしているときに、以下のエラーが発生した場合

ld.so.1: ./my: fatal: libmysqlclient.so.4:
open failed: No such file or directory

それらを実行するときに、以下のいずれかの方法で問題を回避できます。

富士通コンパイラ (fcc / FCC) を使用している場合は、MySQL のコンパイルでいくつかの問題が発生します。これは、Linux ヘッダファイルが非常に gcc 指向であるためです。

fcc/FCC を使用する場合は、以下の configure 行が有効です。

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