web-dev-qa-db-ja.com

重いInnoDBワークロード用にMySQLをどのように調整しますか？

生産OLTP主にInnoDBテーブルを持つシステムを想定しています。

  • 誤調整/誤設定されたシステムの一般的な症状は何ですか？
  • 最も一般的にデフォルトから変更する構成パラメーターは何ですか？
  • 問題が発生する前に、潜在的なボトルネックをどのように見つけますか？
  • アクティブな問題をどのように認識してトラブルシューティングしますか？

特定のstatus変数と診断を詳述する逸話があれば、喜んでいただけます。

mysqlperformanceinnodb
40
Riedsio

ここ は、SunのJenny ChenによるInnoDBのチューニングに関する優れた記事です-彼女はMySQLについて多くのブログを書いており、その一部はSolaris固有です（例 DTrace を使用）が、ブログ全体面白い情報がたくさんあります。

16
Gaius

興味深いことに、MySQL 5.5では、複数のinnodbバッファープールを使用できるようになりました。

気になるパラメータは

約1か月で、クライアント用に112のinnodbバッファープールを実装する予定です。どうだったか教えてあげます。

UPDATE 2011-02-27 21:57 EDT

Innodb_buffer_pool_instancesの最大値は64であることがわかったので、144 GBを構成することにしたので、innodb_buffer_pool_instancesを18に、innodb_buffer_pool_sizeを8に設定しました。現在、サーバーに450GBをロードしています

UPDATE 2011-04-28 13:44 EDT

複数のInnoDBバッファープールを試しました。スレッドのロックと競合が多すぎました。単一の162GBバッファープールに切り替え、read_io_threadsとwrite_io_threadsを64（最大値）に設定しました。これはずっとうまくいきました。

UPDATE 2012-07-03 17:27 EDT

MySQLについて驚くべきことを学びました。それよりも大きい単一のモノリシックInnoDBバッファープールを割り当てる場合インストールされた合計数を物理CPUの数で割った値、完全なInnoDBバッファープールが原因で、OSを定期的にメモリスワップするようにします。 innodb_buffer_pool_instances と呼ばれるMySQL 5.5のオプションを使用して、バッファープールを分割できます。昨日、昨年の回答で述べたクライアントにこれを適切に実装しました。クライアントのバッファプール用にまだ162GBあります。各DBサーバーはデュアルヘキサコアであるため、サーバーのinnodb_buffer_pool_instancesオプションを2に設定しました。私はそれを12に設定することを考えていましたが、同僚が MySQLとSwappinessに関するJeremy Coleのブログ を見せてくれました。読んだ後、すぐにクライアントのために実践しました。このコマンドを実行しました

numactl --hardware

サーバーの192GBのマッピングを確認しましたRAM各物理コアに96GBとして。したがって、innodb_buffer_pool_instancesを2に設定しました。現在、問題はありません。これを確認するために私の回答を更新します次の2つのmontnsのメモリスワッピングに影響します。

19
RolandoMySQLDBA

次のリソースをご覧ください。

7
Brian Ballsun-Stanton

最初に、my.cnfのデフォルトのInnoDBバッファープールサイズを増やします（デフォルトでは8MBと考えています）。

あなたはおそらくこれをあなたのRAMサイズの75％に設定するべきです（一般的に）

4
Matt Healy