さらなる更新系処理の並列実行性の向上について

InnoDB性能フリークの皆様（日本語圏にいるかどうか解りませんが…）、ご無沙汰しております。MySQL-5.6では我々外野開発者が色々実装してきた改良・機能について人気の高い物・有効な物から順に積極的に取り込まれる様子が見て取れます。これはMySQLの開発コミュニティにとって素晴らしい進歩です。我々の活動が多くのユーザーに支持され、本家側からも無視できなくなり、何らかの進歩を阻害する要因が解決されたのではないでしょうか？感無量です。これで私も更に前へ進むことが出来るというものです。というわけで、今回は今まで誰も触れてこなかった問題に触れてみます。

InnoDB の更新系処理のスケーラビリティは、私が過去に数多のRDBMSをベンチマークした経験上、商用RDBMSと比べてまだ明らかに低い印象を受けます。この記事を読むような人は勿論InnoDBのmutex/rw_lockの競合状態の確認はできるのでもう知ってると思いますが（飛ばします^^;）、index->lock の競合です。ご存知の通りInnoDBのテーブルは主キーのB-Tree構造であるので、この競合はすべてのテーブル／インデックスに当てはまります。index->lock の排他ロックはB-Tree構造が変更されるかも知れない場合に確保されます。leafブロックはblock->lockで排他制御するのですが、root/branchブロックは纏めて一個のindex->lockで代表させています。そして、それらのロックはトランザクションの一部であるミニトランザクション終了まで（修正しました：10/7 16:00）確保されます。例えば、３段B-Treeにleafブロックを１個追加するような処理であってもindex全体がロックされてしまい、その間、関係ない他のbranchブロックの先への処理が全くできないのです。

厳密に言うと、境界時の多少の例外処理はありますが、leafブロックを１個追加する場合は基本的にはそのブロックへのポインタが十分収まる場合には、一つ上の階層のbranchブロックさえロックできていればそれが最小限のロックなのです（説明用に他の細かい事情は大幅に省略）。とにかく単純に考えても最適化したら効果大きそうでしょう？

で、先月やってみました。先ず、5.5.xで。しかし、直ぐにkernel_mutexの競合に阻まれました。row/tableロックの管理のための取得が特に多い模様でした。5.6.xではkernel_mutexは機能毎に分割されているのでもう少し効果は大きいはずと考え、次は5.6.2で。今度はピーク性能は明らかに上がるのに多接続時の性能が大幅ダウン。私がカンファレンス等で長年説明していますが、競合箇所が１カ所でも残っていると、他の競合を解決すればするほど残されたその一カ所に集中し、見た目の性能は下がってしまうのです。これを進歩と捉えられない人は前に進めないのです。これは進歩！（リリースはできないですが…）

さて次の競合はやはり、kernel_mutex(~5.5)から派生しているlock_sys->mutex(5.6~)です。今週、さっくりspace_id(テーブルスペースのID)をキーに分割してみましたら、見事な結果が得られました。tpc-c系の負荷で32CPU以上までスケールしているように見えます。まぁ、その分、過多接続の性能は少し下がっているかも知れませんが（次の競合で）。まだデバッグ用のコードをまだ全く書いていない（UNIV_DEBUGでは動作しない）状態なのでリリースにはまだ遠いですが性能は大きく変わることは無いと思います。デッドロック検出関係が少し不安ですが、思ったよりも今動いてるので多分大丈夫でしょう。

…数字？出しませんよ。性能フリークなら、性能は自分で試す癖をつけましょう。私も他人の結果は信用しないのです、大抵分析不足なので。最悪の場合、プロモーション用に極端なケースのみが切り取られていたりします。

実験用。試してwktkするためだけのパッチセットです。
https://code.launchpad.net/~yasufumi-kinoshita/percona-server/5.6-xtradb-performance-alpha
まだ、5.6.2用です。でもノーマルの5.6.2と比較して効果を試すには十分かと思います。
(＊バグバグだったので随分前に消しました。何時の日か何らかの形で復活を目指しています。)

その他気づいたこととしては、query_cache絡みの処理がスケーラビリティを阻害しているので切りました。query_cache_size = 0 だけでは多接続時に重く、完全に切れていないようなので、明示的に query_cache_type = OFF とすることで解決しました。

次の競合は、InnoDB側では無いかも知れません。有効にすると結構重くなってしまうので好きではないのですが（さらにそのせいで「電子顕微鏡のジレンマ」に近い問題もあるかもしれない）、performance_schema
で調べてみたところ、'wait/synch/mutex/sql/LOCK_open' みたいです、２位は 'wait/synch/mutex/innodb/log_sys_mutex'。ちなみに開発者が解決すべき競合は SUM_TIMER_WAIT 順で見るのが正しいと思います。log_sys->mutex つまり、トランザクションログのシリアライズ絡みの排他処理が見えるところまで来ました。かなり更新系処理のスケーラビリティが理想に近づいたと思います。次は…mysqld側か…。