さらなる更新系処理の並列実行性の向上についてDB改造屋雑記2011年10月7日金曜日さらなる更新系処理の並列実行性の向上についてInnoDB性能フリークの皆様(日本語圏にいるかどうか解りませんが...)、ご無沙汰しております。MySQL-5.6では我々外野開発者が色々実装してきた改良・機能について人気の高い物・有効な物から順に積極的に取り込まれる様子が見て取れます。これはMySQLの開発コミュニティにとって素晴らしい進歩です。我々の活動が多くのユーザーに支持され、本家側からも無視できなくなり、何らかの進歩を阻害する要因が解決されたのではないでしょうか?感無量です。これで私も更に前へ進むことが出来るというものです。いうわけで、今回は今まで誰も触れてこなかった問題に触れてみます。更新系処理のスケーラビリティは、私が過去に数多のRDBMSをベンチマークした経験上、商用RDBMSと比べてまだ明らかに低い印象を受けます。ご存知の通りInnoDBのテーブルは主キーのB-Tree構造であるので、この競合はすべてのテーブル/インデックスに当てはまります。排他ロックはB-Tree構造が変更されるかも知れない場合に確保されます。leafブロックはblock->lockで排他制御するのですが、root/branchブロックは纏めて一個のindex->lockで代表させています。16:00)確保されます。3段B-Treeにleafブロックを1個追加するような処理であってもindex全体がロックされてしまい、その間、関係ない他のbranchブロックの先への処理が全くできないのです。厳密に言うと、境界時の多少の例外処理はありますが、leafブロックを1個追加する場合は基本的にはそのブロックへのポインタが十分収まる場合には、一つ上の階層のbranchブロックさえロックできていればそれが最小限のロックなのです(説明用に他の細かい事情は大幅に省略)。単純に考えても最適化したら効果大きそうでしょう?で、先月やってみました。kernel_mutexの競合に阻まれました。row/tableロックの管理のための取得が特に多い模様でした。5.6.xではkernel_mutexは機能毎に分割されているのでもう少し効果は大きいはずと考え、次は5.6.2で。今度はピーク性能は明らかに上がるのに多接続時の性能が大幅ダウン。私がカンファレンス等で長年説明していますが、競合箇所が1カ所でも残っていると、他の競合を解決すればするほど残されたその一カ所に集中し、見た目の性能は下がってしまうのです。これを進歩と捉えられない人は前に進めないのです。これは進歩!(リリースはできないですが...)さて次の競合はやはり、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絡みの処理がスケーラビリティを阻害しているので切りました。することで解決しました。次の競合は、InnoDB側では無いかも知れません。'wait/synch/mutex/innodb/log_sys_mutex'。順で見るのが正しいと思います。トランザクションログのシリアライズ絡みの排他処理が見えるところまで来ました。更新系処理のスケーラビリティが理想に近づいたと思います。次は...mysqld側か...。足りなかったかも知れない。Kinoshita2008年末くらいからInnoDBの改造等で生計を立てていました。2011年末から2015年頭まで、本家の開発チームにて公式にInnoDBの性能改善に取り組みました。その後4年ほどデータベースに拘らずに新しい技術を用いた開発に携わりました。2019年から再び中の人に復帰しています。