ひげろぐ@はてな RSSフィード

※ スパムが来るのでコメントは全面的に閉じました。

2006-03-28

[] thread_cacheの効果

thread_cacheを50にしてみたらひどく効果があった。

mysql> show status like '%con%';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Aborted_connects     | 0     |
| Connections          | 33433 |
| Max_used_connections | 32    |
| Threads_connected    | 1     |
+----------------------+-------+
4 rows in set (0.00 sec)

mysql> show status like '%thre%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| Delayed_insert_threads | 0     |
| Slow_launch_threads    | 0     |
| Threads_cached         | 32    |
| Threads_created        | 33    |
| Threads_connected      | 1     |
| Threads_running        | 1     |
+------------------------+-------+
6 rows in set (0.00 sec)

Connectionsの33433に対してThreads_createdが33。

設定前と比べると雲泥の差だ。

ちなみにかなり長い時間33のまま。


実はMax_used_connectionsも大幅に減っていて、これはMySQLが力いっぱい働けるようになって同じ処理を短時間でさばけるようになったためかと思われる。

サーバのロードアベレージも10分の1以下にまで下がった。


netstatでMySQLへの接続を見ても以前は数十あるのが当たり前だったのが、今は1接続から多くて10接続くらいしかない。


ちょっと感動的な効果だ。

[] DB接続のコスト

DB処理は接続と切断のコストが高いと言われるけど、それってカーネルが働くコストだったのかな。

thread_cacheはデフォルトだと0で無効だし。

まあほかのDBMSではわからないけどMySQLではそうっぽい。


持続的接続はそのコスト解決の典型的な一手段だけど、実際やってみるとDBの接続数をmax_connectionsを超える勢いでを食いつぶしたり、MySQL側を再起動すると確立済みの持続的接続がエラーを出し続けるとか問題もあるので気軽に使うとはまることが多々ある。


それに比べるとthread_cacheはMySQL側だけで解決するので楽だ。


MySQL, Linux, and Thread Caching (by Jeremy Zawodny)

http://jeremy.zawodny.com/blog/archives/000173.html


2002年9月にはすでに同じ感動を味わった人がいたようです。

CarterCarter 2007/08/29 13:02 http://7bbfc200fa042a2b187ff3043f725f1c-t.mjwljt.org <a href=”http://7bbfc200fa042a2b187ff3043f725f1c-h.mjwljt.org”>7bbfc200fa042a2b187ff3043f725f1c</a> [url]http://7bbfc200fa042a2b187ff3043f725f1c-b1.mjwljt.org[/url] [url=http://7bbfc200fa042a2b187ff3043f725f1c-b2.mjwljt.org]7bbfc200fa042a2b187ff3043f725f1c[/url] [u]http://7bbfc200fa042a2b187ff3043f725f1c-b3.mjwljt.org[/u] 1a3cc74952c0f718df670921a31a3934