一部の関係者や、勘の鋭い方はお気づきだと思いますが、11月にPerconaを辞して、12月よりInnoDB teamの一員として働くこととなりました。XtraDB等Perconaの製品については少なくとも現職にある限りは、関与することは今後基本的にありません。
XtraDBは私にとっては、InnoDBという優れたアーキテクチャの持つポテンシャルを引き出す手段を素早く積極的に世に問うための重要なチャネルでした。しかし利用者が増えるに連れ、利用者や会社にとっては製品としての位置づけが強くなってしまったようです。この立場の違いが、開発の方針のあらゆる面での意見の相違を生んだと思います。迅速な進歩を失ってしまっては、永続的な存在意義は無いと、例え現在満足していても、将来問題に直面したときに小手先で解決できることなどもう無いのです、先に手を打たなければ。体裁を気にして将来の継続的なメンテナンスコストを犠牲にするような実装は開発リソースが少ないのだからいくら顧客がお金を払うといってもやるべきではなかったと思います。顧客が直接お金を払って前に進む形式では未来の問題は解決できず、満足した時点で終了。つまり、XtraDBのInnoDBへの提案という役割は一定の成果は得たものの、もう終わったのだと判断しました。開発リソース豊富な本家の進歩に追いつくことはもうできないのではないかと思います。
今回幸運にも、本家に参加する機会を得ました。今まで、ソースコードのみを教師に孤独に我流で腕を磨いてきましたが、これからは、自分よりもInnoDBに詳しい方々と、垣根無く議論し前へ進んでいけるのだと思うと、非常に期待と興奮を覚えます。皆さんも期待してもらっていいと思います。
反骨精神の私を今でも突き動かすのは、確か６・７年前(？)、某社有名CEOが「１０年経とうがオープンソースのデータベースは商用のものには追いつくことは無い」という公式発言をしたことです（次の雇い主という説もあるが…）。多分タイムリミットはあと３・４年ですが納得のいく結論が得られるように頑張りますので、応援等宜しくお願いいたします。あ、その後もInnoDBの改善は続けますよ勿論。最早ライフワークですから。
2011年12月5日月曜日
2011年10月7日金曜日
さらなる更新系処理の並列実行性の向上について
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側か…。
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では動作しない）状態なのでリリースにはまだ遠いですが性能は大きく変わることは無いと思います。デッドロック検出関係が少し不安ですが、思ったよりも今動いてるので多分大丈夫でしょう。
…数字？出しませんよ。性能フリークなら、性能は自分で試す癖をつけましょう。私も他人の結果は信用しないのです、大抵分析不足なので。最悪の場合、プロモーション用に極端なケースのみが切り取られていたりします。
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側か…。
2011年4月15日金曜日
頂いた件の御挨拶
（読者も少ないと思うし、日本語なので、独り言的なプライベートな感じですが。）
InnoDBに惚れ込み、その伝導のためにInnoDBのポテンシャルを可能な限り引き出す。それがこの５、６年の活動の根底にありました。その内のCPUスケーラビリティの問題を解析するための集大成とも言える（個人的に）セッションをMySQL CE 2010 (前回) で持たせて頂きましたが、一部の突出したユーザー極数人を除いては反応はあまり良くなかったのを覚えています。なので、自分の活動が一般のユーザーに分かる形で評価されることは無く、これは陽のあたらない縁の下の闇家業のようなものなのだと感じていたたところです。この一年は性能改善の進歩はあるのですが、一般ユーザーに説明すべき新しい知見は特に得られていなかったので、プライベートの問題解決を優先して MySQL CE 2011 の参加は見送っていました。
そのような状況下で、賞を頂いた報を受け、素直に驚き喜んでいます。
これ以上活動を続けることが実はあまり誰の役にも立ってないのではないか、という疑心暗鬼な状況は解消されました。先へ進むGOサインを頂いたと受け取っています。
オープンソースの醍醐味は、私のような、多くの外野の開発者がフットワーク軽く誰の承認も無く個人のやり方で問題解決を試み、公開することができることだと思います。
そんな外野の私を支持してくれる、雇い主のPercona社、
そしてFaceBook社、RightNow社を筆頭に会社の最深部（？）の私に届くほど困難な仕事をいつも依頼してくれる超エキスパートユーザーの方々、
さらにすべてのXtraDBのユーザーに感謝します。
むむむ。全員日本語は通じないかな？日本じゃ誰もXtraDB使っていないかもしれないし…
では、こっそり心の中で感謝しています。:-)
外野開発をビジネス的に支援してくれるユーザーがいる限り、外野開発者が欲をかいてそれを裏切らない限り、オープンソースソフトウェアはオープンソースソフトウェアとして死んでしまうことは無いと確信しています。大丈夫。これで、まだ何年でも闘えそうです。
※SSDも大体分かってきたので、次はHandlerSocket向けのチューニングとかにも手を付けてみたいのですが、ベンチマークソフトが無いので先ずははそこからです。誰か作ってくれないかな…。目下、余力が無いのですよ＾＾；
InnoDBに惚れ込み、その伝導のためにInnoDBのポテンシャルを可能な限り引き出す。それがこの５、６年の活動の根底にありました。その内のCPUスケーラビリティの問題を解析するための集大成とも言える（個人的に）セッションをMySQL CE 2010 (前回) で持たせて頂きましたが、一部の突出したユーザー極数人を除いては反応はあまり良くなかったのを覚えています。なので、自分の活動が一般のユーザーに分かる形で評価されることは無く、これは陽のあたらない縁の下の闇家業のようなものなのだと感じていたたところです。この一年は性能改善の進歩はあるのですが、一般ユーザーに説明すべき新しい知見は特に得られていなかったので、プライベートの問題解決を優先して MySQL CE 2011 の参加は見送っていました。
そのような状況下で、賞を頂いた報を受け、素直に驚き喜んでいます。
これ以上活動を続けることが実はあまり誰の役にも立ってないのではないか、という疑心暗鬼な状況は解消されました。先へ進むGOサインを頂いたと受け取っています。
オープンソースの醍醐味は、私のような、多くの外野の開発者がフットワーク軽く誰の承認も無く個人のやり方で問題解決を試み、公開することができることだと思います。
そんな外野の私を支持してくれる、雇い主のPercona社、
そしてFaceBook社、RightNow社を筆頭に会社の最深部（？）の私に届くほど困難な仕事をいつも依頼してくれる超エキスパートユーザーの方々、
さらにすべてのXtraDBのユーザーに感謝します。
むむむ。全員日本語は通じないかな？日本じゃ誰もXtraDB使っていないかもしれないし…
では、こっそり心の中で感謝しています。:-)
外野開発をビジネス的に支援してくれるユーザーがいる限り、外野開発者が欲をかいてそれを裏切らない限り、オープンソースソフトウェアはオープンソースソフトウェアとして死んでしまうことは無いと確信しています。大丈夫。これで、まだ何年でも闘えそうです。
※SSDも大体分かってきたので、次はHandlerSocket向けのチューニングとかにも手を付けてみたいのですが、ベンチマークソフトが無いので先ずははそこからです。誰か作ってくれないかな…。目下、余力が無いのですよ＾＾；
2011年2月22日火曜日
S4だけど意外に重要なバグ
性能関係情報（特にベンチマーク結果に影響がありそうなもの）です。
以前から、ベンチマーク中のInnoDBのIOに多少の違和感（引っかかり？）を感じていたのですが、そんなに影響も大きくないので私は放っていたのですが（優先順位の問題です^^;）、多分 FaceBook の Mark Callaghan が発見したこれが原因かも知れません。流石 Mark Callaghan。
Auto-extension of InnoDB files (blocks the other IO)
とりあえずそこに修正案を投稿しておきました。(fix_suggestion_56433.patch)
これで、InnoDB の IO はよりスムーズになるはずです。file_per_table が有効でINSERTが多い場合は結構影響が大きかったはず。
以前から、ベンチマーク中のInnoDBのIOに多少の違和感（引っかかり？）を感じていたのですが、そんなに影響も大きくないので私は放っていたのですが（優先順位の問題です^^;）、多分 FaceBook の Mark Callaghan が発見したこれが原因かも知れません。流石 Mark Callaghan。
Auto-extension of InnoDB files (blocks the other IO)
とりあえずそこに修正案を投稿しておきました。(fix_suggestion_56433.patch)
これで、InnoDB の IO はよりスムーズになるはずです。file_per_table が有効でINSERTが多い場合は結構影響が大きかったはず。
2011年1月12日水曜日
性能調査は続く。。。
SSD向けのチューニングは一段落ついたので、今回は別の話題です。
チーム内部では5.5版のXtraDBが色々ベンチマークされていて、その中で興味深い事象が発生しました。
ストレージはRAID10。SSDではないです。
書き込みも読み込みも両方のIOが激しくなる条件でベンチマークすると、書き込みが疎かになって modified_age が肥大化して同期flushを伴うチェックポイントが頻繁に発生してスループットが安定しないと言うのです。。。
「そんなのは、XtraDB側の問題じゃなくて OS/ハード の問題だろ！」
とは思ったのですが、読み込みIOのスループットを制限するパッチを作ってみました。modified_ageが大きくなったときに指定された割合で過去の最大スループットをベースに制限します。。。。
なかなか興味深いパッチができたのですが、その前に先方では解決した模様でした。
件の事象は xfs 固有のもので、ext4 では起こらない
と言うのです。
というわけで、とりあえず「xfs を使わない」で解決です。
xfs には何かRDBMS向きではない部分が有るのかも知れません。
世間で行われているベンチマークは単純なものが多く、RDBMSのような各IOに意味があって依存関係があるような条件では成されていないということでしょうか。
やはりベンチマークは自分でやるまで信用できないものですね。気をつけましょう。
RDBMS性能フリークは xfs に気をつけろ。
というわけで、今回は新機能は無し。パッチはとりあえずお蔵入りです。。。
※ディストリビューションは CentOS5.5 です。私のサーバーじゃないので、私の趣味ではありません。xfs が古かったりするのかも。nobarrierは使用してます。そのせいではありません。
※IO read スループット制限パッチは DBインスタンス/VM が１個のサーバーに相乗りの場合は有効かも。要望が有れば復活もあるかも。
チーム内部では5.5版のXtraDBが色々ベンチマークされていて、その中で興味深い事象が発生しました。
ストレージはRAID10。SSDではないです。
書き込みも読み込みも両方のIOが激しくなる条件でベンチマークすると、書き込みが疎かになって modified_age が肥大化して同期flushを伴うチェックポイントが頻繁に発生してスループットが安定しないと言うのです。。。
「そんなのは、XtraDB側の問題じゃなくて OS/ハード の問題だろ！」
とは思ったのですが、読み込みIOのスループットを制限するパッチを作ってみました。modified_ageが大きくなったときに指定された割合で過去の最大スループットをベースに制限します。。。。
なかなか興味深いパッチができたのですが、その前に先方では解決した模様でした。
件の事象は xfs 固有のもので、ext4 では起こらない
と言うのです。
というわけで、とりあえず「xfs を使わない」で解決です。
xfs には何かRDBMS向きではない部分が有るのかも知れません。
世間で行われているベンチマークは単純なものが多く、RDBMSのような各IOに意味があって依存関係があるような条件では成されていないということでしょうか。
やはりベンチマークは自分でやるまで信用できないものですね。気をつけましょう。
RDBMS性能フリークは xfs に気をつけろ。
というわけで、今回は新機能は無し。パッチはとりあえずお蔵入りです。。。
※ディストリビューションは CentOS5.5 です。私のサーバーじゃないので、私の趣味ではありません。xfs が古かったりするのかも。nobarrierは使用してます。そのせいではありません。
※IO read スループット制限パッチは DBインスタンス/VM が１個のサーバーに相乗りの場合は有効かも。要望が有れば復活もあるかも。
登録:
投稿 (Atom)