データベース設計と SQL 操作のチューニング技法のベストプラクティスに従っても、データベースが大量のディスク I/O アクティビティーによってまだ遅い場合は、ディスク I/O に関するこれらの低レベル技法を調査してください。Unix top
ツールまたは Windows タスクマネージャーに、ワークロードの CPU 使用率が 70% 未満であることが示されている場合、ワークロードはディスクに依存している可能性があります。
テーブルデータを
InnoDB
バッファープールにキャッシュすると、ディスク I/O を必要とせずに、クエリーでそれを繰り返し処理できます。バッファープールサイズは、innodb_buffer_pool_size
オプションで指定します。このメモリー領域はきわめて重要であるため、ビジーなデータベースでは多くの場合、サイズを物理メモリーの量の約 80% に指定します。詳細については、セクション8.9.1「InnoDB バッファープール」を参照してください。GNU/Linux および Unix の一部のバージョンでは、Unix
fsync()
呼び出し (これはInnoDB
がデフォルトで使用します) および類似のメソッドによるファイルのディスクへのフラッシュが驚くほど低速です。データベースの書き込みパフォーマンスが問題である場合、innodb_flush_method
パラメータをO_DSYNC
に設定してベンチマークを実行します。x86_64 アーキテクチャー (AMD Opteron) の Solaris 10 で
InnoDB
ストレージエンジンを使用する場合、InnoDB
関連ファイルにダイレクト I/O を使用して、InnoDB
のパフォーマンスの低下を回避します。InnoDB
関連ファイルを格納するために使用される UFS ファイルシステム全体にダイレクト I/O を使用するには、それをforcedirectio
オプションでマウントします。mount_ufs(1M)
を参照してください。(Solaris 10/x86_64 のデフォルトではこのオプションを使用しません)。ダイレクト I/O をファイルシステム全体ではなく、InnoDB
ファイル操作にのみ適用するには、innodb_flush_method = O_DIRECT
を設定します。この設定では、InnoDB
はデータファイルへの I/O (ログファイルへの I/O ではなく) にfcntl()
ではなく、directio()
を呼び出します。-
Solaris 2.6 以上の任意のリリースおよび任意のプラットフォーム (sparc/x86/x64/amd64) で、大きな
innodb_buffer_pool_size
値を使用して、InnoDB
ストレージエンジンを使用する場合、先述のforcedirectio
マウントオプションを使用して、raw デバイスまたは個別のダイレクト I/O UFS ファイルシステムで、InnoDB
データファイルおよびログファイルのベンチマークを実行します。(ログファイルのダイレクト I/O が必要な場合、innodb_flush_method
を設定する代わりに、マウントオプションを使用する必要があります。)Veritas ファイルシステム VxFS のユーザーは、convosync=direct
マウントオプションを使用してください。ダイレクト I/O ファイルシステムに、
MyISAM
テーブルのファイルなど、ほかの MySQL データファイルを配置しないでください。実行ファイルやライブラリは、ディレクト I/O ファイルシステムに配置しないでください。 RAID 構成または別のディスクへのシンボリックリンクをセットアップするために追加のストレージデバイスを使用できるようにする場合、追加の低レベル I/O のヒントについては、セクション8.11.3「ディスク I/O の最適化」を参照してください。
InnoDB
チェックポイント操作のため、スループットが周期的に低下する場合、innodb_io_capacity
構成オプションの値を増加することを考慮します。値を大きくすると、フラッシュが頻繁になり、スループットを低下させる可能性のある作業のバックログが避けられます。-
InnoDB
フラッシュ操作によって、システムが遅くならない場合は、innodb_io_capacity
構成オプションの値を小さくすることを考慮します。一般に、このオプション値はできるかぎり小さくしますが、前の箇条書きで示したように、スループットに周期的な低下が発生するほど小さくしないでください。オプション値を小さくすることができる一般的なシナリオでは、SHOW ENGINE INNODB STATUS
からの出力に、次のような組み合わせが示されることがあります。履歴リストの長さが短く、数千未満です。
挿入バッファーマージ数が挿入された行数に近いです。
バッファープール内の変更されたページが、一貫してバッファープールの
innodb_max_dirty_pages_pct
をはるかに下回っています。(サーバーが一括挿入を実行していないときに測定します。変更されたページの一括挿入時に、パーセンテージが大幅に高くなるのは正常です。)Log sequence number - Last checkpoint
が、InnoDB
ログファイルの合計サイズの 7/8 未満か、理想的には 6/8 未満です。
I/O に依存したワークロードのチューニング時に考慮するその他の
InnoDB
構成オプションには次が含まれます:innodb_adaptive_flushing
、innodb_change_buffer_max_size
、innodb_change_buffering
、innodb_flush_neighbors
、innodb_log_buffer_size
、innodb_log_file_size
、innodb_lru_scan_depth
、innodb_max_dirty_pages_pct
、innodb_max_purge_lag
、innodb_open_files
、innodb_page_size
、innodb_random_read_ahead
、innodb_read_ahead_threshold
、innodb_read_io_threads
、innodb_rollback_segments
、innodb_write_io_threads
、およびsync_binlog
。