先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
InnoDB Deep Talk #2 (仮) に引っ張りだされました。
先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
再出発します。
ご無沙汰しています。 作ってから公開されるまでのタイムラグで思い出してまで書く余裕が無くて暫く更新をお休みしていました…。 その代わり、MySQL-5.7では細かい修正も含めてある程度思っていた通りのInnoDBの改善ができたのではないかと思います。 で、本題。唐突ですが、先月末でInnoDBチームを辞しました。理由は色々ありますが、ネガティブな理由は一個もありません。願わくば、体がもう一つ欲しいくらいです。 もう一度、自分のユーザー視点を現在のものにアップデートするべく、一般ユーザーに戻ります。その方がInnoDBを更にフットワーク良く改善できると考えたからです。とはいえ、今の立場で大きな案件があるまで、新しい領域には踏み込めないでしょう。暫くはInnoDBチーム在職中に行った変更で、リリース済みのものについて解説していきます。 その後、実用的な技術情報やツール（もしも作ったら）を共有し
転職等、状況のご報告
一部の関係者や、勘の鋭い方はお気づきだと思いますが、11月にPerconaを辞して、12月よりInnoDB teamの一員として働くこととなりました。XtraDB等Perconaの製品については少なくとも現職にある限りは、関与することは今後基本的にありません。 XtraDBは私にとっては、InnoDBという優れたアーキテクチャの持つポテンシャルを引き出す手段を素早く積極的に世に問うための重要なチャネルでした。しかし利用者が増えるに連れ、利用者や会社にとっては製品としての位置づけが強くなってしまったようです。この立場の違いが、開発の方針のあらゆる面での意見の相違を生んだと思います。迅速な進歩を失ってしまっては、永続的な存在意義は無いと、例え現在満足していても、将来問題に直面したときに小手先で解決できることなどもう無いのです、先に手を打たなければ。体裁を気にして将来の継続的なメンテナンスコスト
性能調査は続く。。。
SSD向けのチューニングは一段落ついたので、今回は別の話題です。 チーム内部では5.5版のXtraDBが色々ベンチマークされていて、その中で興味深い事象が発生しました。 ストレージはRAID10。SSDではないです。 書き込みも読み込みも両方のIOが激しくなる条件でベンチマークすると、書き込みが疎かになって modified_age が肥大化して同期flushを伴うチェックポイントが頻繁に発生してスループットが安定しないと言うのです。。。 「そんなのは、XtraDB側の問題じゃなくて OS/ハード の問題だろ！」 とは思ったのですが、読み込みIOのスループットを制限するパッチを作ってみました。modified_ageが大きくなったときに指定された割合で過去の最大スループットをベースに制限します。。。。 なかなか興味深いパッチができたのですが、その前に先方では解決した模様でした。 件の事象は
XtraDB 5.5版 性能調整中
色々ありましたが、最近、やっと 5.5.x 版のXtraDBを開発中で性能を確認しています。 SSD で試したりもしているのですが、今まで気にしていなかったことが意外に重要なことに色々気づいたので覚え書き。 SSD で更新系が多い処理で高性能を出すコツ １．Linux native AIO を利用する。 (5.5 共通) SSDはIOが速いので（？）、今まで通りInnoDB内部のaioを使うとちょっと非効率で、運が悪いと暫く処理されないリクエストが出てくる可能性がありそうです。5.5 ではもう内部のaioにはパッチを当てずにデフォルト通り Linux native AIO を使うことを推奨します。使えない環境の人は、なんとか使えるようにしてからビルドしてください。。。 ２．圧縮機能を利用しない。 データページの圧縮機能はSSDの折角速いIOレスポンスを殺します。もしもデータの容量がSSDに
InnoDBの超高負荷更新処理安定性
最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。 まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。 今回もサクサクとポイントだけ。 （IOスレッドを増やす とか、他でも語られている既知のものは省略します。） 今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイもの
InnoDBの性能改善版
しばらく間があいてしまいました。 今回は、地味な話で少し遅れてしまった話題ですが、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の並列性能、データ量、処理内容、チューニング等々で性能差
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
