このページは機械翻訳したものです。

8.12.1 ディスク I/O の最適化

このセクションでは、より高速なストレージハードウェアをデータベースサーバー専用にできる場合に、ストレージデバイスを構成する方法について説明します。 I/O のパフォーマンスを向上させるための InnoDB 構成の最適化の詳細は、セクション8.5.8「InnoDB ディスク I/O の最適化」 を参照してください。

• ディスクシークはパフォーマンスの大きなボトルネックです。 この問題は、データの量が、効果的なキャッシュが実行不能になるほど大きくなり始めると、明確になります。 多かれ少なかれランダムにデータにアクセスする大きなデータベースの場合、読み取りには最低 1 回、書き込みには 2 回のディスクシークが確実に必要になります。 この問題を最小にするには、少ないシーク回数でディスクを使用します。

• さまざまなディスクにファイルをシンボリックリンクするか、ディスクストライピングを行なって、使用可能なディスクスピンドル数を増やします (およびそれによってシークのオーバーヘッドを軽減します)。

  • シンボリックリンクの使用

    これは、MyISAM テーブルの場合、データディレクトリ内の通常の場所から別のディスクへのインデックスファイルやデータファイルのシンボリックリンクを作成する (ストライピングされることもある) ことを意味します。 ディスクがほかの目的にも使用されていないものとして、これによって、シークと読み取り時間がともに改善されます。 セクション8.12.2「シンボリックリンクの使用」を参照してください。

    シンボリックリンクは、InnoDB テーブルでの使用はサポートされていません。 ただし、InnoDB データおよびログファイルを異なる物理ディスクに配置することは可能です。 詳細は、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

  • ストライピング

    ストライピングは、多数のディスクがあり、最初のブロックを最初のディスクに、2 番目のブロックを 2 番目のディスクに、N 番目のブロックを (N MOD number_of_disks) 番目のディスクにというように配置することを意味します。 つまり、通常のデータサイズがストライプサイズより小さい (または完全に一致している) 場合に、パフォーマンスが大幅に向上します。 ストライピングはオペレーティングシステムとストライプサイズに大きく依存するため、さまざまなストライプサイズでアプリケーションのベンチマークを行なってください。 セクション8.13.2「独自のベンチマークの使用」を参照してください。

    ストライピングの速度の違いは、パラメータに大きく依存します。 ストライピングパラメータの設定方法とディスク数によって、桁違いの差が測定されることがあります。 ランダムアクセスに対する最適化か順次アクセスに対する最適化かを選択する必要があります。

• 信頼性のため、RAID 0+1 (ストライピングとミラーリング) を使用したいと考える場合がありますが、この場合、N 個のドライブのデータを保持するために 2 × N 個のドライブが必要です。 これは、そのための資金がある場合に最適なオプションである可能性があります。 ただし、それを効率的に処理するために、何らかのボリューム管理ソフトウェアに投資する必要がある場合もあります。

• 適切なオプションは、ある種類のデータがどのくらい重要であるかに応じて RAID レベルを変えることです。 たとえば、再生成が可能なやや重要なデータは RAID 0 ディスクに格納しますが、ホスト情報やログなどの本当に重要なデータは、RAID 0+1 または RAID N ディスクに格納します。 RAID N は、パリティビットの更新に必要な時間のため、多くの書き込みがある場合に問題になる可能性があります。

• データベースが使用するファイルシステムのパラメータを設定することもできます。

  ファイルに最後にアクセスされたタイミングを知る必要がない (実際にデータベースサーバーで役立たない) 場合、-o noatime オプションを使用してファイルシステムをマウントできます。 それは、ファイルシステム上の i ノードの最終アクセス時間への更新をスキップするため、一部のディスクシークが避けられます。

  多くのオペレーティングシステムで、-o async オプションを使用してファイルシステムをマウントすることによって、ファイルシステムが非同期に更新されるように設定できます。 コンピュータが適度に安定している場合、これにより、それほど信頼性を犠牲にすることなく、パフォーマンスが向上するはずです。 (Linux ではこのフラグがデフォルトでオンにされています。)

MySQL での NFS の使用

MySQL で NFS を使用するかどうかを検討する場合は注意が必要です。 オペレーティングシステムおよび NFS バージョンによって異なる潜在的な問題には、次のものがあります:

• NFS ボリュームに配置された MySQL データおよびログファイルはロックされ、使用できなくなります。 ロックの問題は、MySQL の複数のインスタンスが同じデータディレクトリにアクセスする場合や、停電などが原因で MySQL が適切に停止されない場合に発生することがあります。 NFS version 4 は、アドバイザおよびリースベースのロックの導入に関する基本的なロックの問題に対処します。 ただし、MySQL インスタンス間でデータディレクトリを共有することはお薦めしません。

• 誤った順序で受信したメッセージまたはネットワークトラフィックが失われたため、データの不整合が発生しました。 この問題を回避するには、TCP with hard および intr マウントオプションを使用します。

• 最大ファイルサイズの制限。 NFS Version 2 クライアントは、最低 2GB のファイル (signed 32 bit offset) にのみアクセスできます。 NFS Version 3 クライアントは、より大きなファイル (最大 64 ビットオフセット) をサポートします。 サポートされる最大ファイルサイズは、NFS サーバーのローカルファイルシステムによっても異なります。

プロフェッショナル SAN 環境またはその他のストレージシステム内で NFS を使用すると、このような環境外で NFS を使用するよりも高い信頼性が得られる傾向があります。 ただし、SAN 環境内の NFS は、直接接続されたストレージまたはバス接続された非ローテーションストレージよりも低速になる可能性があります。

NFS を使用する場合は、本番環境に配備する前に NFS 設定を徹底的にテストするため、NFS Version 4 以降をお勧めします。