同時接続について自分なりに理解してみた

書こうと思ったときに少しでも記事書いたほうがよいと思い、とりあえず書いてみる。言葉にしてまとめていくこと大事。

いつも通り流れに任せて書くので、多分整理されてないかもしれない。。間違ってる箇所があったら指摘お願いします。
今回はmysqlのチューニング＋スレッドの話です。

スレッドの基本的なチューニング

my.cnfとかでmax_connection変数ってのがありますが、maxってのがついているおかげで、この値を500とか1000にすれば、その分だけmysqlが処理を行ってくれると思っちゃったりするかもしれない。多分昔の自分もそうだった気がする気がする。最大って言うぐらいだから、この値を設定しておけば問題ないみたいな。

でも、基本的にmax_connectionをいくら高めても、一秒間に処理できるクエリ（qps）はそこまで伸びない。多分、CPU利用率余ってたり、スレッド数にムラがあるのがよくあるような気がしつつ、そこまで調べる気力が出ないので、とりあえずそんな気がする。ざっくりでごめんなさい。

んで、max_connectionとともに設定しなければいけないのが、「thread_cache_size」であり、作成したスレッドをキャッシュしておくことにより、作成するコストを減らすことができる。

んで、その分処理に回すことができれば、より多くの処理をすることができ、qpsがあがるってわけでございます。ab社によれば、max_connectionの1/3ぐらいが妥当という話しもあるので、基本はそれぐらいであとは調整していけばよいと思うが、基本的にこのあたりをやっておけば、スレッド周りはそこまで悲鳴をあげることはないと思う。

ここまではまず基本的なチューニング。

スレッド掘り下げてみる

んで、今回ちょいとスレッド周りを掘り下げて理解してみた。

負荷という場合に、I/OなのかCPUなのかという話しはよくあるが、いづれにしても「待ち」が生じて、処理に進めないってのがざっくりという負荷の実体でもあり、解消しなければいけない問題であったりする。

じゃ、max_connectionとthread_cache_sizeによるチューニングを行うとどういうことになるかというと、お店の入り口が広がり、いっぱいお客をいれることができる。

要はいっぱい捌けるわけである。個人的な印象としては全ての入り口に扉がついていて、max_connectionはお店への扉の数、thread_cache_sizeは扉をあけっぱなしにしておく感じ。

こうすることで、待ちを減らすことができるのは、ラーメン屋とかを想像すれば、分かるかもしれない。行列が減りますよって感じ。

ただ、5.1や5.5じゃなくて、5.0とかを使っている場合に、「innodb_thread_concurrency」って値がデフォルトで8になっており、いくらお店への間口を増やし、いっぱい入れるようにしても、お店に同時に入れる数が8になっており、効率よくない。

んで、バージョン5.0.8以降から20、要は制限なしとなり、いくらでもお店に入れるようになった。

じゃ、お店に入れたらどうなるかというと、今度はチケットを渡される。その数が「innodb_concurrency_tickets」である。チケットを持ってるお客はinnodbの処理に入ることができ、特に待つ必要はない。

ただし、チケットにも配布できるチケットにも当然上限があるので、処理に入れない部分がある。なので、お店に入れても、チケットを使ったら、またスタート地点からやり直しということなのである。なので、マシンが処理しきれる程度のチケットを配るのがよいだろう。（結局は実験していくしかないかもしれないが…）

このあたりの説明をレファレンスマニュアルでは、以下のように説明している。

InnoDBに同時に入る事ができるスレッドの数は、innodb_thread_concurrency変数によって決められます。スレッドが InnoDBに入ろうとする時にもし並行処理の限度までスレッド数が達していたら、それらは列になります。スレッドがInnoDB に入るのを許可されると、innodb_concurrency_ticketsの値と同等の「フリーチケット」をたくさん与えられ、スレッドはそのチケットを使ってしまうまでは自由にInnoDB に出入りできます。それ以降は、スレッドが次に InnoDBに入ろうとした時に、再度並行処理チェックの対象となります。(または列に並ぶ可能性もある)
引用:
http://dev.mysql.com/doc/refman/5.1/ja/innodb-parameters.html