を実行するとSHOW PROCESSLIST、多くの場合、「アイテムの解放」状態の多数のINSERT / UPDATEスレッドがあります。
MySQLのマニュアルでは、スレッドがこの状態になる理由の少なくとも一部がクエリキャッシュに関係していることを示唆しています。データの変更によりキャッシュクエリが無効になっていると考えられます。
ただし、my query_cache_sizeは0に設定され、クエリキャッシュが完全に無効になります。
この状態で非常に多くのスレッドを持つことには、他にどのような理由がありますか？
関連するテーブルはInnoDBストレージエンジンを使用します。
回答:
innodb_thread_concurrencyの値を確認します。
私のシステムでは、MySqlドキュメントのガイドラインに従って、値を8から32に増やすと、「アイテムの解放」状態を同時に報告するスレッドの数が大幅に減少しました。また、観察された平均クエリ時間は桁違いに減少しました。
これはサーバー全体のパフォーマンスに大きな違いをもたらしましたが、「解放アイテム」の特効薬ではありませんでした。私のハードウェアエコシステムは、この状態は主に「遅い」ディスク（2x10kディスクraid 1）を備えたシステムで見られ、高速ストレージ（12x15kディスクraid 10）を備えたシステムではあまり見られないと仮定します。そのため、ディスクのパフォーマンスのチェックも保証される場合があります。
幸運を！
また：
innodb_thread_concurrencyのデフォルト値は、使用されている5.0ポイントリリースによって根本的に異なることに注意してください。
デフォルト値は数回変更されています：MySQL 5.0.8より前の8、5.0.8から5.0.18の20（無限）、5.0.19から5.0.20の0（無限）、5.0.21から8（無限）オン。- ソース
これは、一見無害な5.0.20から5.0.21へのアップグレードにより、デフォルトが無限から8に変更され、それに伴ってパフォーマンスが低下したことを意味します。
アイテムの解放は、一時的な構造、バッファなどの割り当てが解除されるクエリ実行ステージです。クエリキャッシュの一部の作業はこの段階で行われますが、そこで起こることはそれだけではありません。SHOW PROFILESを使用して、このステージが他のステージと比較してどれくらい時間がかかっているかを確認することをお勧めします。消費時間が問題になる場合は、貧乏人のプロファイラーやoprofileなどのツールでトラブルシューティングします。
「アイテムの解放」とクエリキャッシュに関するこの問題に関するバグレポートがありました。バグはクローズされていますが、innodb_thread_concurrencyに関する言及はありませんでした。
偶然にも、5月にPercona Live NYCでロナルド・ブラッドフォードと話をしました。MySQL 5.5の複数のInnoDBバッファープールが大量のスレッドロックを生成し、必要なキャッシュデータが複数のバッファープールに分散している可能性が高いため、innodb_thread_concurrencyを控えた状況を彼に伝えました。
彼は、私がinnodb_thread_concurrencyに対して決して値を設定するべきではないことをはっきりと言った。常にデフォルト値とし、現在はゼロ（0）にしてください。そうすることで、InnoDBストレージが独自に生成するinnodb_concurrency_ticketsの数を決定できます。これは、無限並行性が行うことです。
「アイテムの解放」は、innodb_thread_concurrencyに制限を課すと発生する可能性が高くなります。それは常にゼロ（0）でなければなりません。私はリスクを取ってinnodb_concurrency_ticketsを上げ、それが役立つかどうかを確認します。
まったく同じ症状で問題が発生しました。InnoDBログファイルのあるディスクがいっぱいになったことが判明しました。価値があるチェック。