 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
|
||||||||||||||
| thread_cacheチューニング後の測定結果 | ||||||||||||||
|
thread_cacheの設定を変更した後、再度負荷テストを実施しました。以下がその結果です。  図2：負荷テスト結果 （画像をクリックすると別ウィンドウに拡大図を表示します） 先ほどまでとは違い、Max_used_connectionsは同時接続数の増加と共に増え、最終的には400近くになりました。また、Threads_createdが激減し、ほとんどスレッドが生成されなくなりました。 これがthread_cacheの直接的な効果ですが、それ以上に重要なのはスレッド生成の負荷がなくなったことによって、Queries_per_secが「同時接続数が増加してもばらつきが少なく、数値も低下しにくくなった」という効果があらわれていることです。 データのばらつきは多少あるものの、ひいき目に見れば「Max_used_connections=310程度まではQueries_per_secを維持している」といえるのではないでしょうか。先ほどは128でしたから、単純な数値の比較で約2.5倍の同時接続に耐えうるサーバになったのです。 |
||||||||||||||
| 適切なthread_cacheの設定値を知るために | ||||||||||||||
|
負荷テストを行った結果、このサーバでは下記のように設定すればよいことがわかりました。
max_connections=310
これはあくまで単純なクエリに対するテスト結果であって、実際に運用しているサーバでは処理するクエリがより複雑で、返されるデータサイズも大小様々なので、このようにわかりやすいグラフにはならないでしょう。また当然負荷テストをするわけにもいきませんので、これはそのまま適用できる方法ではありません。 実機ではどのようにして適切な値を知ることができるでしょうか。今回はグラフ化しませんでしたが、Threads_connectedやThreads_runningの値が役立つでしょう。定常的にこれらの値を収集しておき、もっとも負荷が高い時間帯にどの程度のスレッドが同時に処理を実行しているのかがわかれば、thread_cacheはThreads_running（場合によってはThreads_connected）の最大値を指定すればよい、ということも直ちに理解できます。 |
||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
