主にInnoDBテーブルを持つ本番OLTPシステムを想定
- システムの調整ミス/構成ミスの一般的な症状は何ですか?
- どの設定パラメーターをデフォルトから最もよく変更しますか?
- 問題が発生する前に、潜在的なボトルネックをどのように見つけますか?
- アクティブな問題をどのように認識してトラブルシューティングしますか?
特定のstatus
変数と診断の詳細を示す逸話をいただければ幸いです。
主にInnoDBテーブルを持つ本番OLTPシステムを想定
特定のstatus
変数と診断の詳細を示す逸話をいただければ幸いです。
回答:
興味深いことに、MySQL 5.5では、複数のinnodbバッファープールを使用できるようになりました。
気にするパラメータは
約1か月で、クライアントに112個のinnodbバッファープールを実装する予定です。どのように行ったかをお知らせします。
innodb_buffer_pool_instancesの最大値は64であることがわかりました。144GBを構成することにしました。そのため、innodb_buffer_pool_instancesを18に、innodb_buffer_pool_sizeを8に設定しています。
複数のInnoDBバッファープールを試しました。スレッドのロックと競合が多すぎます。単一の162GBバッファープールに変更し、read_io_threadsとwrite_io_threadsを64(最大値)に設定しました。これはうまく機能しました。
MySQLについて驚くべきことを学びました。物理CPUの数で割った総インストール数よりも大きい単一のモノリシックInnoDBバッファープールを割り当てると、InnoDBバッファープールがいっぱいになったために、OSを定期的にメモリスワッピングに誘導します。innodb_buffer_pool_instancesとして知られるMySQL 5.5のオプションを使用して、バッファープールを分割できます。昨日、昨年の回答で言及したクライアントに対してこれを適切に実装しました。クライアントのバッファプール用にまだ162GBあります。各DBサーバーはデュアルヘキサコアであるため、サーバーのinnodb_buffer_pool_instancesオプションを2に設定しました。12に設定することを考えていましたが、同僚がMySQLとSwappinessに関するJeremy Coleのブログを見せてくれました。それを読んだ後、私はクライアントのためにすぐにそれを実践しました。このコマンドを実行しました
numactl --hardware
各物理コアに対して96 GBの192 GBのサーバーRAMのマッピングを見ました。そのため、innodb_buffer_pool_instancesを2に設定しました。今は順調です。回答を更新して、これが次の2か月のメモリスワッピングにどのように影響するかを確認します。
次のリソースを調べることをお勧めします。
どの設定パラメーターをデフォルトから最もよく変更しますか?
メモリ構成