mysql.server は MySQL インストールディレクトリの support-files ディレクトリあるいは MySQL のソースツリーにあります。それを自動的起動・シャットダウンの /etc/init.d/mysql としてインストールします。項2.11.2.2. 「MySQL を自動的に起動・停止する」 を参照してください。

MySQL が十分なファイルや接続ができない場合、十分なファイルを処理する Linux を設定していない場合があります。

Linux 2.2 およびそれ以降では、割り当てられたファイル処理を以下のように確認できます。

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

16MB 以上のメモリーがある場合、何か以下のようなものを 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

コマンドラインの echo コマンドを root として実行することもできます。しかし、これらの設定は次回コンピュータを再起動したときには失われます。

代わりに、これらのパラメータを sysctl ツールを使用して起動時に設定できます。それは多くの Linux 配布 (SuSE Linux 8.0 およびそれ以降を含む) で使用されています。以下の値を /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

これによりサーバーの接続総数およびオープンファイルの上限 8,192 まで可能になります。

LinuxThreads の STACK_SIZE 定数によりアドレススペースのスレッドスタックのスペースを管理します。その管理は各スレッドスタックに十分余裕をあたえられるように大きく、しかしスレッドのスタックが mysqld データに入り込まないように小さくなくてはなりません。幸いなことに、現在使用しているアドレスのマップを外す要求を出した場合 Linux の mmap() の実装によってマップした領域のマップを外し、エラーを返さずにページ全体のデータをゼロにすことが弊社の実験で分かりました。ですから mysqld あるいはほかのスレッドアプリケーションの安全はスレッドを作成するコードの 「紳士的な」 振る舞いにかかっています。ユーザーは所定の時間での実行中のスレッド数がスレッドスタックがグローバルヒープに近寄らないように十分に低くなっているようにするための対策を講じる必要があります。mysqld を使用して、適切な値を max_connections 変数に設定することでこの振る舞いを強化する必要があります。

MySQL をご自身でビルドする場合、スタックをよくするために LinuxThreads をパッチします。詳しくは項2.13.1.3. 「Linux バイナリ配布の注釈」を参照してください。LinuxThreads にパッチを適用しない場合は、max_connections を 500 を超えない値に設定するようにしてください。大きなキーバッファー、大きなヒープテーブル、または mysqld が大量のメモリーを割り当てる原因になるその他の事柄がある場合、あるいは 2G バイトのパッチを使って 2.2 カーネルを実行している場合は、さらに低い値に設定するようにしてください。弊社のバイナリあるいは RPM バージョンを使用する場合、大きなキーバッファーあるいは多量のデータを伴う大きなヒープテーブルがない場合、max_connections が 1500 に設定しても安全です。LinuxThreads の STACK_SIZE が小さければ小さいほど、多くのスレッドを安全に作成できます。128K - 256K バイトの値をお勧めします。

多数の同時接続を使用する場合、フォーキングあるいは子のクローン化でプロセスを妨げることによってフォークボムアタックを妨げようとする 2.2 kernel の「feature」 によって影響を受ける場合があります。これによって同時クライアントが増えるに従って MySQL はうまくスケールできなくなります。シングルの CPU を使用したシステムで、この例を非常に遅いスレッドで経験しました。MySQL に接続するのに長い時間 (1 分近く) がかかる場合があり、まさにそれをシャットダウンするほどの時間がかかります。1 台の複数の CPU を使用したシステムでは、クライアント数が増えるに従ってクエリーの速度が徐々に遅くなっていきました。解決策を探す段階で、弊社のユーザーの 1 社からユーザーのサイトで効果があったとのことで kernel のパッチが届けられました。このパッチは、http://dev.mysql.com/Downloads/Patches/linux-fork.patch で入手できます。弊社ではこのパッチに弊社の開発や実際の生産システムを含む広範なテストを実施しました。このパッチは何ら問題なく MySQL のパフォーマンスを大幅に改善しましたので、まだ 2.2 カーネルで高負荷のサーバーを実行しているユーザーにお勧めします。

この問題は 2.4 カーネルで修正されたため、現在のシステムパフォーマンスに満足できない場合は、2.2 カーネルにパッチを適用するよりも 2.4 にアップグレードするほうが簡単な場合があります。SMP システムでは、アップグレードによって、公平性のバグが修正されるだけでなく SMP のパフォーマンスも十分に向上します。

弊社では MySQL を 2.4 kernel で 2 つの CPU を搭載したマシンでテストしましたが MySQL スケールが 大幅に 良くなっています。1,000 クライアントまでのテストを実施している間に実質的にクエリーの減速がなく、MySQL スケーリング ファクターは (最大のスループットと 1 台のクライアントスループットの比率を計算したもの) は 180% でした。CPU が 4 個のシステムでも似たような結果が観察されています。クライアント数が 1,000 に増えるまで実質的に減速はなく、スケーリング係数は 300% でした。これらの結果に基づいて、2.2 カーネルを使用する高負荷の SMP サーバーでは、この段階で 2.4 カーネルにアップグレードすることを強くお勧めします。

最高のパフォーマンスを実現するには最優先課題として mysqld を 2.4 kernel で動作させることが必須であるということが分かりました。これを行うには renice -20 $$ コマンドを mysqld_safe に追加します。4 CPU 搭載マシン上での弊社のテストでは、その優先度を上げることによって 400 クライアントまでの増加の間に 60% の結果が出ました。

弊社では現在 2.4 kernel を four-way および eight-way のシステムで使用した場合 MySQL の性能がどのように良くなるか情報を集めています。お客様がその様なシステムにアクセスして何かベンチマークを行った場合、その結果を <benchmarks@mysql.com> まで E メール頂ければ幸甚です。弊社ではそれを検討してドキュメントに追加するかどうかを検討します。

ps で mysql サーバープロセスがデッドした場合、これは通常 MySQL にバグがあるかあるいはテーブルが破損していることを意味します。What to Do If MySQL Keeps Crashing を参照してください。

mysqld が SIGSEGV 信号でデッドした場合に Linux でコアダンプを取得するには、mysqld を --core-file オプションで起動します。多分コアファイルのサイズを ulimit -c 1000000 を mysqld_safe に追加あるいは mysqld_safe を --core-file-size=1000000 で起動して増やす必要があります。mysqld_safe を参照してください。