調査はさらに深淵へ。。。

より詳しい説明や経緯は応援サイト

Patreonの私のページ

で有料会員向けに公開しているのですが、グラフだけ共有します。

 

どうも小手先のヒンティングでは回避できない様相です。
原因を特定するためにはLLVMの深淵に向かわなければいけなくなってきました…

MySQL RP-8.0 が現状、世界で最もCPU性能スケールが高いMySQLです！

MySQL RP (Restore Performance) として、成果をgithubで公開しながら(利用はMySQL Community Editionと同様のGPLライセンス) 個人でMySQLの性能回復を研究しています。

これまでは、第１段階として、OLTP処理で競合しそうな要素を狙ったSQLでのCPU性能スケールテストを行って、MySQL-8.0で問題のある箇所を修正してきました。RP008で目立った問題は解決したと思われるので、
第２段階として、PGOビルドなしでもシングルスレッド性能で、5.7のノーマルビルド（公平のため -DDISABLE_PSI_MEMORY=ON オプション付きビルド）を超えることを目指します。そうすれば限定句が少し取れて「世界で一番CPU性能が高いMySQL」となります。

(※MySQL-5.7のPSI_MEMORYのコードはperformance_schema=OFFでも非常に重く、5.7の性能を不当に下げています。)

< まず、お願い >

現状の比較結果を簡単に紹介しますが、その前にこの活動の持続のためのご協力のお願いです。

一つの手段は、Patreonのサポートサイトの有料会員になっていただくことです。今回の結果のもっと詳しい説明もありますし、活動の中間報告なども随時しています。RPxxxの各変更も、どの様に分析したかも説明してます。

もう一つの手段は、、、
「よくある事情」により、この活動は求職活動の一環と言う側面も暫くあるので、この活動(とういか生活…)の持続性のために、採用選考・採用面接などの実績もあると助かります。このRP開発活動との折り合いが良ければ実際副業にしますので。 buildup.db@gmail.com まで一報をお願いします。

あとは、結果が出始めたので、この活動について機を見て話題に上げて宣伝していただけると有り難いです。

よろしくお願いいたします。

 

< 現状の比較結果 >

では現状（第１段階完了）のベンチマーク結果を簡単に。

まずTPC-Cですが、ほんの少ししかベースの8.0と差がないので割愛します。

TPC-CはMySQLのOLTP性能を測る指標としては今はもう緩すぎるようです。個別の要素を調べなければなりません。

（※この20年弱、TPC-C同等処理のベンチマークをOLTP性能の指標にして性能改善を進めてきましたが、既に8.0では十分なスケールが得られているため、より厳しい指標でなければ、もう緩いTPC-Cでは性能が下がっても分からないようです。そのせいで、遅いコードを平気で書く人達が気づかなかった。これは我々開発に関わった人達のミスです。反省しています…）

というわけで、例によって Dimitriさんの BMK-kit の中から各個別要素に一番負荷をかけるSQLを選んでテストしていたわけです。

今までと同様 "Xeon(R) CPU E5-2699 v4 (22cores;44threads)" で 2ノードNUMA、
単純化してできるだけ純粋なCPUスケールを見るために、ストレージは ramfs、
REDOログの書き込み待ち設定 innodb_flush_log_at_trx_commit=0 で io wait を極力排除しています。

(まず、CPU性能を優先してるのは、誤魔化しようがないからです。IOは多少 Durability を犠牲にすれば可能なので後回し。)

比べたのは、これらのバイナリ、

• MySQL 8.4 Community Edition (mysql-8.4.5-linux-glibc2.28-x86_64.tar)

• MySQL 9.3 Community Edition (mysql-9.3.0-linux-glibc2.28-x86_64.tar)

• Percona Server 8.4 (Percona-Server-8.4.5-5-Linux.x86_64.glibc2.31.tar.gz)

• MariaDB 11 (mariadb-11.8.2-linux-systemd-x86_64.tar.gz)

あとは、私がノーマルビルド(但し -DDISABLE_PSI_MEMORY=ON)した、"MySQL-5.7.44"、"MySQL-8.0.42"、"MySQL RP-8.0[RP008]"。そして、MySQL RP-8.0[RP008] は PGOビルドも比較しています。

 

１．主キーランダム検索性能スケール

セカンダリ索引の範囲スキャンで、索引に無い値を取得するクエリは、１クエリで多数の主キーランダム検索を発生することができます。クライアント通信のラグなどを抑えて、より純粋な性能です。

BMK-kit でいうと、sb_exec/sb11-OLTP_RO_10M_8tab-uniform-s_ranges1-Rsize100-SecIDX-notrx-socket.sh 相当。

 

２．lock_sysの性能スケール

上記と同様のクエリに "LOCK IN SHARE MODE" 句を足せば、競合しないロック処理のみで lock_sys に負荷をかけられます。

 

３．log_sysの性能スケール

REDO log バッファへの書き込みは mini-transaction 単位で、それは１レコード毎です。
１クエリで多数のレコードを更新すれば、多数のmini-transactionを発生させて、
log_sys に負荷をかけられます。

BMK-kit でいうと、sb_exec/sb11-OLTP_RW_10M_8tab-uniform-upd_noidx1-upd_range100-notrx-socket.sh 相当。

 

４．purge_threadsの性能スケール

参照整合性取る必要のなくなった古いUNDOレコードを消すのがバックグラウンドのPurge処理です。innodb_max_purge_lag_delay を使えば、フォアグラウンドの処理がPurgeを置いていかなくなり、Purgeの処理性能が現れます。１クエリで多数のセカンダリ索引キー値を更新すれば、主キーレコードの更新やセカンダリキーレコードの削除・追加などで、大量のUNDOレコードを生成することになりPurge処理が増やせます。このテストは、purge_threads を変更して平衡するスループットを調べます。

BMK-kit でいうと、sb_exec/sb11-OLTP_RW_10M_8tab-uniform-upd_idx1-upd_range100-notrx-socket.sh 相当の最後の値です。

２.と３.は、１.を直したことで性能が高くなっているようです。
というわけで、
１.と４.の問題は、他のMySQLコードでは何も直していないようですので、
現状、世界で一番と言っても良いでしょう。：）

しかし低並列では、RP008ノーマルビルドは5.7ノーマルビルドの真の性能(-DDISABLE_PSI_MEMORY=ON)にまだ負けるので、それが次の課題です。

(PGOビルドはバイナリの再現性が少し良くないので、維持管理上不便なので。不便だとバグを取りこぼしたりビルドによって挙動が違う可能性があったり少し不安要素ですので。処理によっては遅くなるものもあるかも知れない。安全のためにはコード側でコントロールしたいところ。)

うまく行けば、PGOビルドよりも速くなるかも。

そして、ここからがこの活動の本番なのです。何か良い方法をこれから考えます。時間は掛かるかも知れませんが、応援してください。

第２段階のその後はIO性能とか何か劣化を取りこぼしてる処理など（有料会員優先で）募集したりします。

では、ご期待ください。

１つ目のベンチマークの性能スケールを改善しました。[MySQL RP]

 私の個人活動、MySQL RP (Restore Performance) で、１つベンチマーク結果を十分改善しました。区切りが良いので簡単に報告だけ。

 ベンチマークは、DimitriKさん ( http://dimitrik.free.fr/blog/ ) がメンテして公開している sysbench バイナリ & スクリプト BMK-kit ( http://dimitrik.free.fr/blog/posts/mysql-perf-bmk-kit.html ) でいうところの、sb11-OLTP_RO_10M_8tab-uniform-s_ranges1-Rsize100-SecIDX-notrx-socket.sh 相当で、

セカンダリ索引の１００行スキャンで、索引カラム以外のデータを返すクエリ

で、内部的に主キー検索が１００回起こる、純粋主キー検索に近い性能が出る処理です。特殊なクエリですが、実は基本的な処理のベンチマークになってるみたいです。(クライアント通信１回で100回主キー検索が発生するので)　Adaptive Hash Index も結構効きます。

 マシンは、Xeon(R) CPU E5-2699 v4 (22cores;44threads) の 2NUMA ノード構成 というレトロなのにコアが多い構成で、性能スケールは厳しい構成です。（7,8年前の超最高スペックサーバーが個人でもPC相当の価格で購入可能になりましたね） 厳しいので、ここでスケールすれば、何処に持っていってもスケール問題は出ないはず。

で、現状こんな結果です。 (X軸がスレッド数、Y軸がTPSです)

(AHI=off)

(AHI=on)

他に特別遅くなってるベンチマークがあれば見ていきます。でも参照系処理のスケールはこれでかなり直ってると思います。

より詳しい説明や、解析・修正の経緯は応援サイト
Patreonの私のページ
で有料会員向けに公開しています。

このような感じでこれからも続けていきますので宜しくおねがいします。
ブログでは、このように大きな案件の簡単な結果のみにします。

MySQL性能回復活動(MySQL RP)を独自に始めます

ようやく、MySQL性能向上開発に専念する体制が整いました。やっと開発作業に戻れます。

実質無所属なのは人生初なので、各種社会保障関係の手続きとか、どのサイトを使って組み合わせるか、どういう設定でアカウントをつくるかなどなど、開発環境も含めて全部自分で決めなければならず、結構時間を要してしまいました。すみません。

結果、本家在籍時と同様の使い勝手で自由に開発できるようになりました。

名前は、『MySQL RP (Restore Performance)』 としました。 ソースコードはMySQLのオープンソースライセンス(GPLv2ベース)で提供します。最初は劣化がもう増えない、劣化が少ないと思われる 8.0 からforkして直していきます。まだ空っぽですが、数日中に更新が増えていきます。
バイナリ提供は余裕が出てから考えます。まだ無理です。既存の互換バイナリ提供者がpullしてくれるようになれば、それもいいかなと思います。

フルタイムで独自活動を続けていくために、支援者も募集します。
buildup-db と言う名前で Patreon に登録しました。(※)
MySQL RP の性能改善修正毎に、ベンチマーク結果、問題解析、ソース変更点の説明を有料会員向けに行っていきます。内容に興味のある方、最新コードで性能向上を体験できた方は、ご支援ください。

長年、影に隠れてきましたが遂に一人で細々と矢面に立つ羽目になりました。
ご期待に応えられるよう善処します。
よろしくおねがいします。

 

※6月4日現在、Patreonのアカウントにトラブルがあったようです。問い合わせ中です。Patreon側がアカウントの内容をレビュー中なのかも知れません。しばらくお待ちください。 

※6月17日現在、Patreonのアカウントが復活しました。github側で進んだ分の解説をしていきます。

今日から『自由』にMySQLの性能改善始めます。（MySQL開発チームを退職しました）

前回の在籍も含めると、累計9年半、本家MySQLチームでInnoDBの性能改善をターゲットに開発の仕事してきました。5.7でのb-tree index scaleや、8.0の初期の新機能で入ってしまった性能問題の修正など貢献できましたが、ここ数年は開発が進む度に導入される性能劣化に追いつけなくなってしまいました。悪いコードを見つけて直そうとしても抵抗が大きいのも大きな要因です。（遅くしたいのでしょうか？遅いことが認識できないのでしょうか？）

この度、体制変更で退職を勧められたのを機に、別の営みでMySQL/InnoDBの性能を改善していくことにしました。どうせ、性能劣化に(私よりも)無頓着な現体制では私が性能を改善することは困難なので、成果は出ないでしょう。（直しても、同時に導入される新機能・修正による劣化に改善分を喰いつぶされることもしばしばあった、と考えています。キリがありません。そもそも、性能に悪い新機能を通すための性能改善回復ではないのに…）
8.0以降の性能に最も満足していないのは私自身です。このままでは終われません。

というわけで、
これは「終わり」ではなく「始まり」です。

これからは、8.0の性能回復を個人で、できればフルタイムでコツコツやっていきます。支援が生活持続上十分に集まるようなら、そのままセキュリティ問題修正なども続けて、延長サポート終了後も8.0性能修正版を使えるようにメンテ・性能改善していきます。(8.0の修正が終了して且つ8.4も相当性能に直せたら8.4への移行も検討します)

会社やチームに気を遣って表現・説明を抑えることも、
理解できない人に際限なく説明して許可を求める必要も、
悪いコードを認めたくない作者に邪魔されることも、
公開の別ブランチならばもうないのです！(あったとは明言はしない。一応。)
なので、本家在籍中よりもスムーズに直していけると思います。（思えば、会社には性能改善に役立つものは何もなく、もう障害・妨害しかないと感じていました。）

体制（各種アカウント開設等）は近日中に整えます。本編は日本語英語併記でやろうと思ってます。
当面は、
github上にブランチを作成して公開。(GPL MySQLなので GPL)
支援者のみに、
ベンチマーク解析内容・修正内容解説を随時公開（これが本編に当たる）
していきます。

改善点がある程度落ち着いてきてから（当初は何も受け付けられませんが）、
いずれ個別ベンチマークの処理改善要望も募っていこうと思います。

乞うご期待です。

* なんで8.0かというと、「性能改善」が多く「汚染」はまだ少なく、EOL間際なので今後も「汚染」は増えづらいから、です。まずは、ここから直して、徐々に進んでいきます。

* 量子コンピュータとか技術革新で暗号通信が安全でなくなったら基幹はオンプレ回帰するはずで、そのときにクラウドでしかまともに動かないというのは不味いと思います。

* そもそも既存の古いオンプレでスケールしなくなったら、クラウドでもスケールしなくなると思うのですが、何を見て開発してるのか。。。