ＤＢ改造屋雑記

転職等、状況のご報告

2011-12-05T20:02:00.003+09:00

一部の関係者や、勘の鋭い方はお気づきだと思いますが、11月にPerconaを辞して、12月よりInnoDB teamの一員として働くこととなりました。XtraDB等Perconaの製品については少なくとも現職にある限りは、関与することは今後基本的にありません。

XtraDBは私にとっては、InnoDBという優れたアーキテクチャの持つポテンシャルを引き出す手段を素早く積極的に世に問うための重要なチャネルでした。しかし利用者が増えるに連れ、利用者や会社にとっては製品としての位置づけが強くなってしまったようです。この立場の違いが、開発の方針のあらゆる面での意見の相違を生んだと思います。迅速な進歩を失ってしまっては、永続的な存在意義は無いと、例え現在満足していても、将来問題に直面したときに小手先で解決できることなどもう無いのです、先に手を打たなければ。体裁を気にして将来の継続的なメンテナンスコストを犠牲にするような実装は開発リソースが少ないのだからいくら顧客がお金を払うといってもやるべきではなかったと思います。顧客が直接お金を払って前に進む形式では未来の問題は解決できず、満足した時点で終了。つまり、XtraDBのInnoDBへの提案という役割は一定の成果は得たものの、もう終わったのだと判断しました。開発リソース豊富な本家の進歩に追いつくことはもうできないのではないかと思います。

今回幸運にも、本家に参加する機会を得ました。今まで、ソースコードのみを教師に孤独に我流で腕を磨いてきましたが、これからは、自分よりもInnoDBに詳しい方々と、垣根無く議論し前へ進んでいけるのだと思うと、非常に期待と興奮を覚えます。皆さんも期待してもらっていいと思います。

反骨精神の私を今でも突き動かすのは、確か６・７年前(？)、某社有名CEOが「１０年経とうがオープンソースのデータベースは商用のものには追いつくことは無い」という公式発言をしたことです（次の雇い主という説もあるが…）。多分タイムリミットはあと３・４年ですが納得のいく結論が得られるように頑張りますので、応援等宜しくお願いいたします。あ、その後もInnoDBの改善は続けますよ勿論。最早ライフワークですから。

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

2011-10-07T12:00:00.008+09:00

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側か…。

頂いた件の御挨拶

2011-04-15T00:15:00.003+09:00

（読者も少ないと思うし、日本語なので、独り言的なプライベートな感じですが。）

InnoDBに惚れ込み、その伝導のためにInnoDBのポテンシャルを可能な限り引き出す。それがこの５、６年の活動の根底にありました。その内のCPUスケーラビリティの問題を解析するための集大成とも言える（個人的に）セッションをMySQL CE 2010 (前回) で持たせて頂きましたが、一部の突出したユーザー極数人を除いては反応はあまり良くなかったのを覚えています。なので、自分の活動が一般のユーザーに分かる形で評価されることは無く、これは陽のあたらない縁の下の闇家業のようなものなのだと感じていたたところです。この一年は性能改善の進歩はあるのですが、一般ユーザーに説明すべき新しい知見は特に得られていなかったので、プライベートの問題解決を優先して MySQL CE 2011 の参加は見送っていました。

そのような状況下で、賞を頂いた報を受け、素直に驚き喜んでいます。

これ以上活動を続けることが実はあまり誰の役にも立ってないのではないか、という疑心暗鬼な状況は解消されました。先へ進むGOサインを頂いたと受け取っています。

オープンソースの醍醐味は、私のような、多くの外野の開発者がフットワーク軽く誰の承認も無く個人のやり方で問題解決を試み、公開することができることだと思います。

そんな外野の私を支持してくれる、雇い主のPercona社、
そしてFaceBook社、RightNow社を筆頭に会社の最深部（？）の私に届くほど困難な仕事をいつも依頼してくれる超エキスパートユーザーの方々、
さらにすべてのXtraDBのユーザーに感謝します。

むむむ。全員日本語は通じないかな？日本じゃ誰もXtraDB使っていないかもしれないし…
では、こっそり心の中で感謝しています。:-)

外野開発をビジネス的に支援してくれるユーザーがいる限り、外野開発者が欲をかいてそれを裏切らない限り、オープンソースソフトウェアはオープンソースソフトウェアとして死んでしまうことは無いと確信しています。大丈夫。これで、まだ何年でも闘えそうです。

※SSDも大体分かってきたので、次はHandlerSocket向けのチューニングとかにも手を付けてみたいのですが、ベンチマークソフトが無いので先ずははそこからです。誰か作ってくれないかな…。目下、余力が無いのですよ＾＾；

S4だけど意外に重要なバグ

2011-02-22T10:49:00.002+09:00

性能関係情報（特にベンチマーク結果に影響がありそうなもの）です。

以前から、ベンチマーク中の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-01-12T11:36:00.002+09:00

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 が１個のサーバーに相乗りの場合は有効かも。要望が有れば復活もあるかも。

XtraDB 5.5版性能調整中（続報）

2010-12-09T19:42:00.004+09:00

SSD 更新系処理の性能が明らかに上がったようなので、続報。

SSD で更新系が多い処理で高性能を出すコツ（追加分）

７．innodb_log_block_size (今日作った) をデバイスのブロックサイズに合わせて拡大する。

ご存知とは思いますが（？） InnoDB のトランザクションログの書き込みは 512 バイト単位で行われます。しかし、最近の記録デバイスはそれより大きい記録単位を持っていることが多くなってきました(1K〜4Kバイトくらい)。この時デフォルトの512バイトでは書き込みIOの効率が悪くなっていたようです。
例えば、4Kバイト単位のデバイスに 512 バイトの書き込みをする場合、他の部分の内容を保持するために、4Kバイトの読み込みの後に該当個所 512バイト上書きして、4Kバイト書き込むという動作が必要になります。たとえ、アプリケーションの側からは見えなくても、ドライバやハードウェアの階層でこのような処理が必要となります。4Kバイト単位IOのデバイスには log_block_size も4KBにするのが最適です。単純に 4KB の読み込みが減るのでトランザクションログ書き込みの効率が上がります。(特に innodb_flush_log_at_trx_commit = 1 の場合は各トランザクションが書き込みを待つため性能が顕著に違うようです。)

このオプションも5.5ベースのXtraDBには実装する予定です。
「もう待てない。是非試したい！」という諸兄は、
bzr branch lp:~percona-dev/percona-server/5.5.7
で開発中バージョン（まだ私の持ち分のパッチだけ(XtraDB + α)）が取得できるので、ビルドして試してみてください。

<追記：12月13日>
innodb_adaptive_checkpoint=keep_average と innodb_log_block_size を 5.1系にバックポートしました。次のリリースで多分使えるはずです。

しかし、、、動作確認がてら、BP十分更新系の負荷をかけたら 5.1 の方が 5.5 よりも 3%くらい速いような。 5.5 はノーマルでは 5.1 より良いのかも知れないが、潜在能力は下がっている。。。ということかも知れない。

XtraDB 5.5版性能調整中

2010-11-30T19:35:00.005+09:00

色々ありましたが、最近、やっと 5.5.x 版のXtraDBを開発中で性能を確認しています。
SSD で試したりもしているのですが、今まで気にしていなかったことが意外に重要なことに色々気づいたので覚え書き。

SSD で更新系が多い処理で高性能を出すコツ

１．Linux native AIO を利用する。 (5.5 共通)

SSDはIOが速いので（？）、今まで通りInnoDB内部のaioを使うとちょっと非効率で、運が悪いと暫く処理されないリクエストが出てくる可能性がありそうです。5.5 ではもう内部のaioにはパッチを当てずにデフォルト通り Linux native AIO を使うことを推奨します。使えない環境の人は、なんとか使えるようにしてからビルドしてください。。。

２．圧縮機能を利用しない。

データページの圧縮機能はSSDの折角速いIOレスポンスを殺します。もしもデータの容量がSSDに入りきらないほど大きく、IOも多いと予想されるなら、普通にRAIDを使った方が速いことが多いでしょう。圧縮機能は結局CPUスケールも悪いので。XtraDBでは、圧縮機能を利用した場合にはいくつかのmutex最適化ができなくなるためそれらは無効になります。（元々InnoDB内部でも block->mutex に当たる物は全体で 1個なので、CPUスケールは諦めましょう）。この機能は性能を大幅に犠牲にしてディスク上／メモリ上の格納効率を上げる物です。性能を気にするなら利用しないでください。

３．innodb_buffer_pool_instances = 1 。増やさない。

この5.5からInnoDBに実装された buffer pool の個数を増やす機能は、残念ながら現在のところは圧縮機能のCPUスケールを増やすために苦し紛れに実装されたものでしか無いようです。増やすと、buffer pool 毎の last modified age 制御を行う必要があるわけですが、独立して扱うことはできないので flush 制御が増やした分だけ不正確になって更新系のスループットが安定しないようです。上記"２．"で圧縮機能は使わないわけですからこのパラメータには触らない方がいいでしょう。

４．innodb_flush_neighbor_pages = 0 (XtraDB)(SSD限定)

SSDはランダムアクセスのコストが無いので、纏め書きは無駄なだけです。そのとき、最も書き出す必要がある物を選ばないと（最も古い更新を含むblock）、書き込みIOのスループットを last modified lsn を進めることに効率良く利用することができません。これが意外に重要で、これをやらないと flush 量の見積もりが狂うので、一部の adaptive_[flushing/checkpoint] で長時間のスループットが安定しないようです。

５．innodb_read_ahead = none (XtraDB)(SSD限定)

読み込みも書き込み同様、纏め読みの意味は少ないです。SSDの読み込みIOは十分速いので、先読みの必要はないでしょう。折角 buffer pool に確保している block を無駄に捨てないように無効にしたほうがいいでしょう。

６．innodb_adaptive_checkpoint = keep_average (先週新しく作ってみた。5.5版のXtraDBから実装予定)

新しい方式を作ってみました。自分がSSDで試している限りは他のどの方法よりも最適なスループットに速く落ち着きます。今の"estimate"よりも動作が軽く、flush量もソフトなので、5.5系ではこれをデフォルトにしようを考えています。計算する対象は InnoDB本体の adaptive_flushing と似てるのですが、単位時間当たりの動作回数を増やして細かく制御するようにして、他の flush アクティビティの量も正確に割り出して無駄な flush も抑制します。某所で評判がよければ、5.1系にもバックポートすることになると思います。

と、いうわけで、
近々 5.5系ベースのXtraDBを出すと思います。
性能フリークの方々はお楽しみに！

追記）
あと、SSDではシーケンシャルアクセスの利点が無いので、doublewrite_bufferの影響が如実に出ます。（なぜならデータページの書く量が倍になるわけだから。。。）
イヤなら無効にしましょう。もしくは innodb_doublewrite_file (XtraDBのオプション) で別の書き込みの速いデバイスに doublewrite_buffer 専用ファイルを置きます。

Save MySQL!

2009-12-31T04:43:00.003+09:00

バラバラにECにメールを送っても、効果があるのか疑問でしたが、こんなサイトが立ち上がったようです。

http://helpmysql.org/

各国語のページがあり、日本語も一応あるので、『英語はちょっと…』という方も大丈夫。
是非、主旨をご理解の上ご協力できる方は署名をお願いします。

XtraDB １周年

2009-12-18T11:44:00.003+09:00

そういえば、XtraDBのリポジトリにcommitしだしてから先日丁度１周年になりましたので、
XtraDB１周年
ということになりました。「冒険家」の少ない日本では残念ながら効果を実感されているユーザーは少ないかも知れませんが、いつの日か急に吃驚してもらえるように来年も磨き続けていきます。

Plugin-1.0.6 ベースのXtraDBの調整は現在ほぼ終わっていて、テストが済み次第リリースされると思います。お楽しみに！
とはいえ、更新をサボっているうちに紹介すべき小ネタ新機能も溜まってきましたね。。。

XtraBackup Windows版

2009-11-06T17:34:00.002+09:00

今回は、速報なので短いです。

「Linuxだけでたまたま動いていた感」のあるXtraBackupですが、私がいろいろ直しているうちに、最新revisionはWindowsでも動くようになったそうです！次のリリースではWindows版も出てくると思います。乞うご期待！！

「そうです」というのは、私はWindowsの開発環境を持っていないし良く分からないので、寄せられたスタックトレースだけを頼りに気合いで直しています。しかし、それで良く動いたものです。。。。

InnoDBの超高負荷更新処理安定性

2009-10-09T01:26:00.004+09:00

最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。

まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。

今回もサクサクとポイントだけ。
（IOスレッドを増やす　とか、他でも語られている既知のものは省略します。）

今回のチューニングの方針は、「mutexやrw_lockなどの競合をできるだけ避ける」ということと「あまり沢山溜めてはイケナイものを溜め込まない」ということです。

まず、最大スループットを上げるために、更新系で競合を回避するポイントをいくつか。

"rseg->mutex" の競合：
ロールバックセグメントを増やしましょう。XtraDB には、innodb_extra_rsegments というオプションがあり、InnoDBの初期化の時に限り、指定数の追加ロールバックセグメントを作成できます。information_schema の INNODB_RSEG ビューで状況確認可能です。

"index->lock" の競合：
その索引全体に対するロックです。5.1のパーティション機能で分割することにより回避できるかも知れません。表定義時に "PARTITION BY HASH(xxxx) PARTITIONS 16" の様にします。db_STRESSの場合、パーティション化するのは HISTORY 表のみで良いでしょう。

"dict_operation_lock" の競合：
パーティションを利用すると多く発生するようです。tablespaceの空き領域を算出する処理がパーティション分増えてしまうのでしょうか。今回は空き領域表示の正確性よりも性能が大事なので、切ってしまいましょう（ぁ）。XtraDBの次バージョンで innodb_stats_update_need_lock に 0 を指定しましょう。動的パラメータなので、空き領域を正確に知りたいときは 1 に戻せます。

以上で db_STRESS のRW=1のスループットがかなり上がったと思います（…）。

あ、はい。どうやって競合を確認するか、ですね？
以前何処かでお話ししたかもしれませんが、少々乱暴な判断法ですが、SHOW INNODB STATUS を何回か実行して、SEMAPHORE セクションに沢山出てくる行を見て、ソースと照らし合わせて何の競合か判断します。結構、的を射た結論が得られます。

さて次はそのスループットを維持／安定化することを考えます。

忘れられがちなポイントを３つ挙げます。

古いダーティブロックを溜めすぎない：
トランザクションログの許容量ぶんよりも古い更新はflushしないままにはしておけません。なので大量に溜め込んでいると、ある時突然大量のデータブロック書き込みが発生する場合があります。普段からコツコツ書き出して減らしてバランスを取る必要があります。
Plugin-1.0.4 から追加された innodb_adaptive_flushing かそれともこれを無効化して、XtraDB の "innodb_adaptive_checkpoint = estimate" を指定すると適切な量の書き出しをコンスタントにするようになります。どちらのオプションが最適かは、サーバーの性能と処理内容とその他設定のバランスに依存するようですので、試してみてください。
XtraDBだと SHOW INNODB STATUS の出力の LOGセクションに Max checkpoint age と Modified age が表示されるので容易に確認できます。

insert bufferを溜めすぎない：
InnoDBは主キー以外の索引列に対する変更は、insert bufferに挿入して整合性を取りながら、後で実際の変更を実施します。しかし、InnoDBは insert buffer が buffer pool の半分の大きさまで肥大化しないと本気で処理しないようです。XtraDB のオプション innodb_ibuf_active_contract = 1 でいつも本気で insert buffer を減らそうとします。

history listを溜めすぎない：
これが起こるのは相当更新の激しい処理です。ロールバックセグメントの中身に対する後処理が新しくエントリを発生するスピードに追いつかずに肥大化した状態かと思われます。ロールバックセグメントが巨大化してしまうと、処理が重くなります。
そのpurgeと言う後処理を専任で実行するスレッドをつくると言うアイデアもありますが、db_STRESS は1CPUのpurge threadではその他CPU全ての更新処理は受け止めきれないようです。
XtraDBの次のバージョンでは、このpurge threadにさらに子分のスレッドをつけて"purge力"を上げることができます。例えば innodb_use_purge_thread = 4 の様な感じで親分1+子分3 の構成でpurgeするようになります。(この設定で16コアのマシン上の32セッションの並列処理に対応できました。)
苦し紛れの innodb_max_purge_lag 指定はもう必要無くなるのではないでしょうか？

以上です。
最後のpurge threadの効果を中心とした実際のデータは、近いうちに mysqlperformanceblog で見ることができると思います。

では、MySQLマニアの皆さんも快適なベンチマークライフを！
（検証用に急に良いマシンを借りれてしまったときに失敗せぬように！）

【注意】PowerPCのマルチプロセッサとInnoDB

2009-09-09T19:11:00.002+09:00

多分、関係ある人にはクリティカルな内容なので、急いで報告します。

ここ２週間くらい、とある案件で頭を悩ませていました。
POWER5 の 8コア構成の IBM のサーバ(Linux)でMySQL(InnoDB)を利用すると、どのバージョンでも（ビルトインInnoDBでも、InnoDB Pluginでも、GCC atomic builtin を使わなくても）しばらくするとハングアップ／クラッシュするそうなのです。

紆余曲折ありましたが、どうも自分の仮説が正しそう（作ったパッチが効果ある模様）なので、先ほどバグレポートを報告しました。

All InnoDB (builtin and plugin) is unstable at PowerPC SMP server

簡単に言うと、InnoDBのコードはIntel CPUのSMPの仕様に依存した作りになっています。Intel系CPUのSMPでは、メモリへの書き込みは他のCPUのキャッシュにも自動的に影響して一貫性を保つのですが、PowerPCではCPU間のキャッシュの一貫性確保を明示的に行う必要があるのです。

結論から言うと、残念ながら、PowerPCのマルチプロセッサ構成でInnoDBを利用するのは危険。ということになります。

もう引き下がれない人や、既にハングアップに悩まされている人は、とりあえず当該レポートにアップロードしておいたパッチで InnoDB Plugin 1.0.3 を使ってみてください。ハングアップの可能性はかなり減る筈です。

-------
(2009/10/9 追記)
大幅に改善したものの、ハングアップの可能性がまだあるようです。
うーむ、__sync_synchronize() は sync になるようだが、store に対する memory barrier にはなってないのかも。
該当個所を asm volatile ("isync") に書き換えてみるか…（独り言）

-------
(2009/10/20 追記)
現在のパッチを同じバグレポートにアップロードしておきました。
動作は今のところ大丈夫そうです。

InnoDBの性能改善版

2009-08-09T11:10:00.000+09:00

しばらく間があいてしまいました。

今回は、地味な話で少し遅れてしまった話題ですが、InnoDBの性能改善についてです。2009.4のMySQL UCの時点では「MySQL5.4よりも遅いんじゃないか？」と言われていた、XtraDB、5.0-highperf ですが、色々世界の皆様のパッチを参考に（いいとこ取り）して、且つ自分のパッチ（split_buf_pool_mutex）はXtraDBベースのlatching orderでちゃんと行儀良く（デバッグモードもちゃんと動作させる）書き直してデバッグして、環境（とチューニング［大事］）によっては5.4よりも多少良い性能が出るようになっているはずです。(例 Performance improvements in Percona 5.0.83 and XtraDB　：　CPUコア数、RAIDの並列性能、データ量、処理内容、チューニング等々で性能差は全く変わるとは思います。)

さて、一部の方から「某Googleのv4パッチは移植しないのか？」の質問を偶にいただくのですが、個人的にはGoogleパッチはInnoDBを書き換え過ぎと思っています。また多分同じ目的で違うアプローチのもっと単純なパッチはある程度含めているのでv4まで見る必要はないかなと思っています。（v3以前からは、IOスレッドのハンドリングと、log_sys->mutex競合対策は採用させていただいています。）先日、初めて（！）googleパッチをビルドして動かしてみたのですが、そのままではビルドできないし、パラメータも外から変えられない（他にもパッチが必要なのか？）し、新オプションを有効にしたらかえって重くなるしで、かなり疑問を感じています。。。一般的にベンチマークの結果は実施法やデータ整理の仕方、見せ方で人によって大きく結果が違ってしまいます。難しいモノですね。。。というわけで、当面はv4パッチの変更点(多分ibufのcontractやmodified blockのflush周り)については採用する予定は個人的にはありません。納得のいかない方は「v4パッチのどの部分のInnoDBのどんな部分に対する何の変更はどう？」という形でご意見をいただけると幸いです。:-)

さて、試していただくには勿論最新のバイナリを利用していただいてもいいのですが（XtraDB 1.0.3-6、5.0.83-percona）、常にバグフィクスをしている（つもり）ので、できればソースからビルドしてもらえれば多分間違いは少ないかと思います。また今、ごく一部で話題のクラッシュリカバリが速くなるオプション（近日日本語で詳細に紹介（英語は不得意なので。。））も今時点でのバイナリには入っていません。
最新のソースを得るためにはBazaarが必要です。(本家MySQLでも利用しているので説明は省略(!))


(XtraDB)
> bzr branch lp:~percona-dev/percona-xtradb/extensions-1.0

(5.0.84-percona)
> bzr branch lp:~percona-dev/percona-patches/5.0.84

とすれば最新のパッチファイルが得られます。新しい本家バージョンに対するbranchがある場合は古い方のメンテナンスは止まっているので注意してください。

パッチの適用の仕方ですが、それぞれのディレクトリ直下には「series」というファイルがあってパッチの適用する順番が書かれています。（[!]:XtraDBのseriesファイルの最後に「xtradb-dir.patch」という行がありますがこのパッチはビルトインのInnoDBとXtraDBを共存させようとするモノですが、まだ怪しい（し、私はまだ関知していないパッチ）のでこの行は削除してください）

パッチは手で１個１個適用しても良いのですが、seriesファイルを利用して


(XtraDB)
innodb_plugin-1.0.3の場所で> (cd パッチの場所/extensions-1.0; cat `cat series`) | patch -p1
  ("xtradb-dir.patch" は series ファイルから削除しておくこと)

(5.0.84-percona)
mysql-5.0.84の場所で> (cd パッチの場所/5.0.84; cat `cat series`) | patch -p1

とすれば簡単かと。（MySQL-5.0のビルドの説明は省略。innodb-pluginのビルドの説明は、、、この辺でお願いします。。。）

では、この辺（XtraDBで追加されるオプション）を見て興味のあるところを試してみてください。サーバーにCPUが１６個以上ある人やRAIDに数百万以上かけている方にはきっと特にご満足頂けると思います。。。

これら追加パラメータのチューニングについて一回全部「日本語で」触れた方がいいかも知れないですね。（いつか。。）

任意のテーブルの IMPORT TABLESPACE

2009-05-30T10:58:00.000+09:00

MySQL の ALTER TABLE コマンドには、IMPORT TABLESPACE というコマンドがあります。InnoDBでは、innodb_file_per_table オプションを有効にしている場合に"クリーンな" .ibd ファイルのバックアップに差し替えることが出来ます。でもこれは色々制限があるので、利用していらっしゃる方は数少ないと思います。内部の構造／ID等が全く同じでなくてはいけないのでバックアップしたファイルをIMPORTできるようにするためには、ALTER TABLE コマンドによる内部的な表の再作成等もしてはいけないのです。

そこで、任意の表をIMPORTできるようにXtraDBを拡張してみました(innodb_expand_import)。(現在branchは https://code.launchpad.net/~percona-dev/percona-xtradb/expand-import です)
まだ、メインのbranchにはまだマージされていませんが、次のリリースには組み込まれるはずです。

さて、リンク先を見ていただければわかるのですが、まだ制限があります。 .ibd ファイルと元のCREATE TABLE文だけでは表と成すための情報が不足しているのです。『索引名と索引ＩＤの対応』と『索引のroot page の場所』です。InnoDBは表、索引等を管理するための内部表を持っていてこれらの情報は SYS_INDEXES内部表に格納されているのでそれも元のInnoDBから抜き出してIMPORT時に利用する必要があります。

というわけで、このEXPORTにあたる対となる機能はXtraBackupに追加してみました(--exportオプション)。コピーしたトランザクションログとデータファイルを使ってリカバリーを行って利用可能なバックアップに変換する--prepareオプションと一緒に指定すると、insert buffer をちゃんと空にした"クリーンな" .ibd ファイルを索引情報を含んだ .exp ファイルも一緒に生成してくれます。

あとは、IMPORT先(要innodb_expand_import)で全く同じCREATE TABLE文で表を作成し、ALTER TABLE ... DISCARD TABLESPACEして、上記で生成された .ibd & .exp ファイルをその表の .frm ファイルと同じところに（アクセス権限に注意）置いて、ALTER TABLE ... IMPORT TABLESPACE するだけです。space_id, index_id, root page 位置の再登録などなど自動で変換してくれます。興味のある猛者はお試しください！

というわけで、興味の赴くままに書いていきますので、話の前提関係が多少滅茶苦茶ですが
（XtraDBって？XtraBackupって？などなど…）、書き続けていくうちに解決するでしょう。。。

ご挨拶

2009-05-30T10:33:00.000+09:00

昨年末くらいからInnoDBの改造で生計を立てている者です。
流石に日本語で触れていないネタが溜まってきたので、まったり紹介していけたらと思っています。
よろしくです。