8.5.7 InnoDB ディスク I/O の最適化

データベース設計と 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。