mysql.server はMySQL インストール ディレクトリの support-files ディレクトリあるいは MySQL のソース ツリーにあります。それを自動的起動・シャットダウンの /etc/init.d/mysql としてインストールします。項2.10.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 に大きな容量のメモリを割り当てる何かがある、または 2.2 kernel を 2GB パッチで動作させる場合にはもっと小さい値にする必要があるかも知れません。弊社のバイナリあるいは RPM バージョンを使用する場合、大きなキーバッファあるいは多量のデータを伴う大きなヒープ テーブルがない場合、max_connections が 1500 に設定しても安全です。LinuxThreads のSTACK_SIZE が小さければ小さいほど、多くのスレッドを安全に作成できます。弊社では 128KB から 256KB の間の値をお勧めしています。

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

この問題は 2.4 kernel では修正されているため、現在稼働中のシステムのパフォーマンスに満足しされていない場合には 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 kernel を使用した高負荷の SMP サーバには、弊社でこの段階で 2.4 kernel にアップグレードするよう強くお勧めします。

最高のパフォーマンスを実現するには最優先課題として 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 にバグがあるかあるいはテーブルが破損していることを意味します。項B.1.4.2. 「What to Do If MySQL Keeps Crashing」 参照。

mysqld が SIGSEGV 信号でデッドした場合に Linux でコア ダンプを取得するには、mysqld を --core-file オプションで起動します。多分コア ファイルのサイズを ulimit -c 1000000 を mysqld_safe に追加あるいは mysqld_safe を --core-file-size=1000000 で起動して増やす必要があります。.項4.3.1. 「mysqld_safe — MySQL サーバ スタートアップ スクリプト」 参照。