mysql - MySQL の thread_concurrency、innodb_thread_concurrency を使用する必要がありますか?

Question

24 個の CPU と 32 GB の RAM を備えた専用サーバーがあります。

このサーバーは Web サイトと mysql を提供します。

もしあれば、これら2つの変数の違いは何なのかわかりません。

Googleで読んだ後、OSまたはMySQLのバージョンによってはこれらの変数が無視される可能性があると言う人もいるため、それらを使用する必要があるかどうかわかりません。

それで、私はそれらを使うべきですか？

Answer 1

MySQL の thread_concurrency オプションは、主に Solaris システム用であり、バージョン 5.6 では廃止される予定であるため、チューニングは時間の無駄になる可能性があります。

thread_concurrency

また、お読みください: https://www.percona.com/blog/2012/06/04/thread_concurrency-doesnt-do-what-you-expect/

innodb_thread_concurrency はパフォーマンスのために調整できますが、それを使用してもパフォーマンスが向上することはありませんでした。

https://www.percona.com/blog/から最良の情報を見つけました。他のすべての提案やアドバイスは、MySQL が動作不能であると見なす可能性があります。

Answer 2

Mysql パフォーマンス ブログを注意深く読み、適切な初期値を選択し、1 日の忙しい時間帯にサーバーのパフォーマンスを監視し、それに応じて調整してください。

ワークロードはあなただけのものなので、簡単な答えはありません。

私の頭の上では、CPU と RAM のバランスが間違っているようです。64GBのRAMには1〜4コア、または取得できる最大RAMには24コア、おそらく192GBだと思いますか？CPU はクエリ レート用にプロビジョニングする必要があり、RAM はアクティブ/ホット データセット サイズ用にプロビジョニングする必要があります。CPU/RAM が理にかなっている奇妙なワークロードを想像することはできますが、innodb が実際にそのようなワークロードの最適なソリューションであるかどうかはわかりません。

あなたの質問に戻ると、「スレッドの同時実行性が期待どおりに機能しない」ということです。つまり、使用しないでください。innodb_thread_concurrencyは単なるカットオフです。ワークロードがすべてホットな場合 (つまり、mysql があまりディスク (?) を使用しない場合) は、コア数よりも大きくするべきではありません。ブログを読んでください。これらの設定は見た目ほど単純ではありません。

また、スレッド キャッシュ、innodb バッファ プール、メモリ プールの追加、ヒープ テーブル サイズ、ソート/キー バッファ サイズ、tx コミット時のログのフラッシュ、ログ ファイルのサイズにも注意を払う必要があります。そしておそらく、今は考えられないことがいくつかあります。

Answer 3

（手動の「thread_concurrency」変数によると、Solaris OSでのみ使用可能です）

Answer 4

これは、さまざまな問題、オペレーティング システム、スケジューラ オプション、I/O サブシステム、CPU の数とタイプ、および実行されるクエリのタイプと数によって異なります。

システムで確実に判断できる唯一の方法は、innodb_thread_concurrency の値を調整し、一般的なワークロードを実行してベンチマークすることです。妥当な出発点は、0 から 48 (あなたの場合) x2 に利用可能な CPU コアの数を掛けたものです。次に、システムが CPU バウンドになるのを確認し始めるポイントまでこれを増やし、少しスロットルを戻すことができます。

これは、トランザクションが生成するディスク アクティビティを考慮していません。そこからディスク I/O を確認し、そこから調整を行うことができます。

これを 0 に設定すると、これが無制限 ** に設定され、デフォルトでは同時実行スレッド数に制限がなくなります

http://dev.mysql.com/doc/refman/5.5/en/innodb-performance-thread_concurrency.html