2015年7月6日月曜日

DBT-2 で MySQL と他のRDBMSの性能比較をしている人に騙されないように注意

一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。

未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。

DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。

が、3年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘してきたのを契機にDBT-2のバグ(MySQL版にだけマイナスに働く)を調べて性能QAのチェックを改めてもらったことがあります。

その情報は、DBT-2の開発側にもフィードバックされたと記憶していますが、3年経った今もバグはそのままです。故意か過失かは不明ですが、DBT-2をMySQLを貶めるために嬉々として利用してきた人には悪意を感じてきました。

TPC-Cの仕様から見て間違っている箇所も何箇所かあるのですが、全RDBMSに共通な間違いはとりあえず触れません。

最も大きい問題の箇所は nonspでの、DELIVERY_1 クエリのあたりです。

DBT-2のnonspでは、
  • dbt2_sql_execute()でクエリを発行
  • dbt2_sql_fetchrow()で各行を取得
  • dbt2_sql_close_cursor()で終了
となっています。

deliveryトランザクションの最初のクエリは、
"SELECT no_o_id FROM new_order WHERE no_w_id = %d AND no_d_id = %d"
ですが、最初の最小の no_o_id しか必要じゃないのでdbt2_sql_fetchrow()が決め打ちで一回呼ばれて終了です。

さて、(方式の相性の)問題はMySQL版のdbt2_sql_execute()の実装がmysql_store_result()を含むことです。なので、件のクエリはMySQL版だけ全件取得されます。全体のスループットが高ければ高いほどその件数は増えるので、MySQL版だけスケールしない結果となります。(性能が上がるほど、見た目のスループットは下がることがある)

考えられる修正としては2通りあります。

1. SQLを明示的に結果を1行にする。

"SELECT COALESCE(MIN(no_o_id),0) FROM new_order WHERE no_w_id = %d AND no_d_id = %d"
※経験上COALESCE()とMIN()が使えなかったRDBMSは無いのでこれで問題はない。

2. mysql_store_result() をやめる。

しかしDBT-2としてはどちらも直す気は無いようです。

そもそも、MySQLをちゃんとチューニングできる人なら、件のSQLが重いことに気づきTPC-Cの仕様を確認して直すはずです。

なので、DBT-2はMySQLの性能チューニングに無知な人が作ったもである、もしくは故意にMySQLの性能を低く見せる意図があると言えると思います。

このような陰険な工作は、逆に味方も騙され油断し、進歩が止まってしまうのではないでしょうか?
私は、このような正々堂々と切磋琢磨しない人たちを
「過去の忘れられた歴史として葬るほど、MySQL/InnoDBの性能を進歩させればいい」
 それこそが正しい対抗策だと考えて前職・前前職で精進してきました。

しかし、今だにDBT-2でのRDBMS比較に触れる人がいると、当時名指しで現行犯で徹底批判しても良かったかなと思ったりします。(進歩のためにはそんな暇は無かったでしょうが。)

まぁ、とにかく一貫して言えるのは、「ベンチマークは自分でやるまで信じない」が安全なスタンスです。

2015年6月8日月曜日

MySQLプラグイン作成時のWindows版だけにある「シンボルの壁」

また、需要が無いかも知れない情報かもですけど、嵌ったのでメモ代わりに残しておきます。ちなみに、コンパイラの種類、バージョン、オプションをちゃんと合わせないとアライメントずれでバイナリ互換が無くなる等のプラグイン作成基礎知識には触れません。普段Linuxの人が、気楽にWindows版も対応しようとした場合の落とし穴についてのみです。あと、私のon Windows開発歴はほぼ0なので間違っていたらごめんなさい。

MySQLプラグインは基本的に、プラグイン側からmysqld側のシンボルを参照することが多いです。例えばストレージエンジンプラグインならmysqldの中のhandlerクラスを継承して実装する必要があったり、プラグインからmysqldの状態を知ろうとすれば、そのグローバル変数やら、保護しているmutexやらも必要になります。

基本的にLinuxでは、同じヘッダファイルさえ読めば公式配布バイナリでも大概のものにアクセスできますが、Windowsではそうはいきません。Windowsの実行形式(exeとかdllとか)では、ダイナミックリンク時にどのシンボルを見せるか(EXPORT)、見に行くか(IMPORT)を明示的に指定する必要があります。デバッグ用のシンボル(.pdb)はプラグイン読み込み時には関係ありません。

mysqld.exeからプラグインdllを読みに行く場合は、プラグインの情報を記述した構造体を見に行くだけですから問題にはあまりならないでしょう。(プラグインのサンプルに則ればプラグイン側の必要な情報はEXPORTされるはずで、変更の必要はまず無いはず。)

問題はその逆です。mysqld.exeのどのシンボルがプラグインから見えるかは、mysqld.exe のリンク時に決まります。ソースツリーを見ると、mysqld.exe のリンク時に mysqld.def を作って読ませています。win/create_def_file.js はその時に利用される、.libファイルからシンボルを抽出して .def ファイル形式に変換するもので、それは sql/CMakeLists.txt の中で使用されています。その対象は、

"FOREACH (CORELIB sql binlog slave mysys mysys_ssl dbug strings binlogevents_static)"

となっており、innobase.lib は含まれていないので、通常は mysqld.exe のInnoDB関連にはアクセスできません。この行に 'innobase' を加えると、InnoDBのシンボルも参照可能な mysqld.exe がビルドされます。

また、プラグイン側も適切にIMPORT設定しなければいけません。mysqld.exe のリンクの際に、リンクライブラリmysqld.lib(EXPORTの確認用ライブラリ)が出力され、プラグインの作成時にリンクされるようになっていて、エラーが出るので取りこぼすことは無いと思います。リンク時にエラーが出た参照は、インクルードファイルで 'extern' で読むところを、'extern MYSQL_PLUGIN_IMPORT' として明示的にIMPORTする必要があります(実体は"__declspec(dllimport)")。これはプラグイン側だけの問題で、mysqld.exeのビルドには関係しません。

という以上の事情から、たとえば「InnoDBの内部が見れる便利なinformation_schema作ったよ。みんな使ってみて!」と言っても(いや、まだ作ってないですが…)、Windows版だけは折角プラグインとしてビルドしても、mysqld.exeもビルドしなおさなければいけないわけです。

一応バグとして上げましたが、需要が無ければ直るかどうか。。。(Bug#77251)

直れば色々某プラグインとかもWindows用InnoDBダイレクトアクセス版とか作れるようになるのと思うのですががが。(handlerから使うとMySQL形式-InnoDB形式変換が意外と重かったと思うので。) いや、Linux版だけなら作れるわけですががが。

2015年4月13日月曜日

MySQL + jemalloc on Windows

需要が無いかもしれませんが、産まれて初めて、MySQL on Windows について触れます(起動したのも初めて)。 私自身はWindows上のMySQLを性能評価できる環境には無いのですが、 敢えてSQL ServerとWindowsという相手のホームグラウンドでアウェイ対決させよう、 という猛者のためにこのエントリを残します。 猛者向けですし、私は無責任でおねがいします。陰ながら応援します。

MySQL on Windows

MySQLの性能・スケールを追求・普及していく上で、Windows上での性能評価はやはり避けては通れないと思います。 (実際にどこまで使うかは別として、正確な要素比較は必要でしょう。) しかし、標準APIを使わなければいけない「地の利が無い」状態では不安が残ります。 できるだけ不安要素は予め解消しておきたいものです。

経験上、不安要素は3つあります。

(1) メモリアロケータ

Linuxでも、glibcのmalloc()はコンパクトですがスケールがよろしくないので、 jemallocなどのスケールするメモリアロケータをLD_PRELOADで読み込まないと、 InnoDBはそのポテンシャルを発揮できません。 当然Windowsでも似たような状況であるはずです。

(2) ファイルIO

実際に遭遇したものを挙げると、fsyncとwriteの並列性が悪く、アプリケーション側でシリアライズしないと 性能が落ちてしまう事象に遭遇した(間接的にクレームを受けた)ことがあります。 更新が多く、トランザクションログの書き込みがボトルネックとなるような場合は注意が必要でしょう。

(3) イベント

InnoDBでは、内部のmutex/rw_lockのロック待ちでは、スピンとイベント待ちの2段構えです。 バッファプールのブロックあたりmutexとrw_lockがあって、現状それぞれイベントを持ちますから、 ギガバイト単位のバッファプールを確保すると、10万〜100万個単位でイベントが作られます。 Linux/Unix系では今のところ目立った問題になったことは無いのですが、 過去Windows系で問題(イベント数が多いと性能が落ちる)になっているのを見たことがあります。 何かエディションの問題だったのかも知れませんが不安が残ります。

(3)については、mutex/rw_lock競合が少なければ多分深刻ではなく、(2)については更新の激しい要件を避ければ良さそうですが、 (1)はどんな処理でも関係することですので、解決しなければ安心できません。

jemalloc による標準malloc関係の差し替え

WindowsにはLinuxのLD_PRELOADみたいな機能は無いので、実際にビルドしてリンクする必要があります。 この手の議論は昔からあるみたいです。 (参考:Patching the Windows CRT)

議論のポイントを抜き出すと…
  • [主] Windows C runtime (CRT) で malloc を差し替えるには CRT の改変が必要ですごく面倒だ
  • [コメ] 俺Windowsの開発者だけど、malloc() 変えちゃえばいいだけじゃないの? 先にリンクしちゃえよ。そっち使うから。
  • [主] おいおい、strdup()-free()ってされたらどうするんだよ。
  • [その他] ザワザワ
結局、Mozillaでは、nsprでプラットフォーム毎のラインタイムの差異を吸収するしてるからそれでいいわけですが、MySQLではそうはいきません。

ブログの主は受け入れてませんが、このWindowsの開発者の方のコメントが重要ポイントです。 後からstrdup()をリンクするときに、strdup()がmalloc()を呼ぶ場合にjemalloc側のmalloc()を呼ぶ、ということです。 WindowsのCRT自体を変更する必要は無いわけです。

とはいえ、全く差し替えちゃうと多少の不整合は出てくるようなので、realloc()、free()等は、 HeapAlloc()なのかjemallocなのかポインタを見て多少交通整理してやる必要はあるみたいです。

パッチを作ってみました。jemalloc-3.6.0-windows4prelink.patch

ビルドの説明も後述しますが、これで、mysql-5.6.23のRelWithDebInfoのビルドで、"mysql-test-run.pl --suites=main,innodb" がパスするので大丈夫とは思います。 さて、これで前述の不安(1)は解決しそうです。

でも

私はこのパッチの権利を放棄します。権利を主張することはありません。自由に使ってください。

パッチの使用は自己責任です。私及びあなた以外の主体は一切の責任を負いません。

とはいえ、以下のビルドでスケーラビリティ確認してくれる猛者を求めています。;-)

偶々成功しただけかも知れないビルド手順

sakaikさんのエントリで解説されていることを前提にしますが、違うのは、
  • jemallocをリンクすること
  • 「日本語」ロケールのまま正しくビルドすること(面倒くさいから)
です。

インストールしておくもの

  • 適切な Visual Studio (少なくとも、2012"以外"じゃないと日本語ロケールでは正しくビルドできないらしい。)
       ※人生で初めて触ったので何が適切かよくわかりません。
  • コマンドプロンプトからパスを通してインストール (MySQLビルド用;パスにはスペースを含まない方がいい)
       cmake (とりあえず私は、cmake-3.1.3-win32-x86.exe)
       bison (とりあえず私は、bison-2.4.1-setup.exe)
       perl (mysql-test-run.pl実行するなら)
  • mozilla-build (jemallocビルド用)
       ※単にMinGWじゃなくてVCを使うMSYSとして使います。
       e.x.) Visual Studio 2013 で 64bit版 をビルドするなら、"start-shell-msvc2013-x64.bat"のコンソール

jemalloc-3.6.0 のビルド (malloc()差し替え用)

mozilla-build のコンソールで、"tar jxf"も"patch -p1"も使えるので、展開して前述のパッチを当てます。

configureします。
> export EXTRA_CFLAGS="-O2 -MT -favor:INTEL64"
> ./configure --enable-cc-silence --with-jemalloc-prefix=""
出力される "JEMALLOC_PREFIX :" の項目が空欄であることを確認。

※-MDだと後でうまくいかなかった。(リンク時にエラーor無視(リンクされない)。何故かはまだ知らない。)

ビルド
> make
使うのは、lib/jemalloc_s.lib です。どこか参照しやすいパスに置きます。

MySQL のビルド

  • "VS2013 x64 Native Tools コマンド プロンプト" を起動して、展開したソースにcd
  • ビルドするディレクトリをつくってcd (e.x. Win64 とか)
  • cmake を実行して プロジェクトファイルを生成する。
       ※CMAKE_EXE_LINKER_FLAGS= には、先ほどビルドしたjemallocのライブラリを指定
> cmake .. -G "Visual Studio 12 Win64"  -DCMAKE_EXE_LINKER_FLAGS="D:\objs\jemalloc_s.lib" -DCMAKE_C_FLAGS="-U_UNICODE -U_MBCS" -DCMAKE_CXX_FLAGS="-U_UNICODE -U_MBCS" -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DINSTALL_LAYOUT=STANDALONE -DFEATURE_SET=community -DWITH_EXTRA_CHARSETS=complex -DWITH_SSL=bundled -DWITH_ZLIB=bundled -DDISABLE_SHARED=ON -DWITH_EMBEDDED_SERVER=OFF -DDEBUG_EXTNAME=OFF
  • UTF-8 のリテラルを含むソースファイルに BOM をつけて、実行時文字コードを指定する #pragma を足す。
      (最低限、UTF-8のリテラルを含む3ファイル、
        "sql/sql_locale.cc"
        "storage/perfschema/unittest/pfs_connect_attr-t.cc"
        "strings/ctype-utf8.c"
       はつけたほうが良さそう。)
      (変換したらちゃんとdiffとかで差分が他に無いことを確認したほうがいい)

      "#pragma execution_character_set("utf-8")" という行を足さねばならない。
      (他のコードを壊さずに!)
        これがないと、折角UTF-8なリテラルをわざわざcp932に変換しようとする…
  • 日本語環境特有で悪さをするコードを削除する (Bug#76555 報告済バグの応急処置)
     こんな感じ
--- mysql-5.6.23_orig/mysys/charset.c   2015-04-03 10:37:16 +0900
+++ mysql-5.6.23/mysys/charset.c        2015-04-01 13:38:01 +0900
@@ -952,7 +952,7 @@ CHARSET_INFO *fs_character_set()
     */
     fs_cset_cache=
                 #ifdef HAVE_CHARSET_cp932
-                        !strcmp(buf, "cp932") ? &my_charset_cp932_japanese_ci :
+                        //!strcmp(buf, "cp932") ? &my_charset_cp932_japanese_ci :
                 #endif
                         &my_charset_bin;
   }
  • jemalloc使用で顕在化するバグを直してもいい (Bug#76670 報告済)
     バグの実害は多分ない、クラッシュリカバリ時にログにエラーが山のように残るだけ。。。
--- mysql-5.6.23_orig/storage/innobase/os/os0file.cc    2015-04-03 10:37:09 +0900
+++ tmp/mysql-5.6.23/storage/innobase/os/os0file.cc     2015-04-13 12:19:57 +0900
@@ -900,6 +900,8 @@ os_file_readdir_next_file(
 next_file:
        ret = FindNextFile(dir, lpFindFileData);

+       DWORD error = GetLastError();
+
        if (ret) {
                ut_a(strlen((char*) lpFindFileData->cFileName)
                     < OS_FILE_MAX_PATH);
@@ -940,7 +942,7 @@ next_file:

        if (ret) {
                return(0);
-       } else if (GetLastError() == ERROR_NO_MORE_FILES) {
+       } else if (error == ERROR_NO_MORE_FILES) {

                return(1);
        } else {
  • ビルドするディレクトリにできた MySQL.sln をダブルクリック
  • 画面上部「ソリューション構成」を "Debug"(デフォルト) から "RelWithDebInfo" に切り替える
  • 「ビルド(B)」-->「ソリューションのビルド(B)」
  • たぶん "0 失敗" で終わるはず。
  • "INSTALL" という名前のプロジェクトをビルドすると、デフォルトの"C:\Program Files\MySQL" 以下にインストールされる。 ※場所の指定はcmakeの時にできたはず。

テストmain.mysqldumpだけ日本語環境では.errにエラーが出てしまうようですが、
ヘブライ文字のファイル名にアクセスしようとして??????.frmがNOTFOUNDなエラーなら、
リリースバイナリでも多分同様なのでここでは気にしないことにします。


Debugではなんかリンクする順番が変わってしまうのか上手くいかなかったです。
今のところこれ以上調べる理由はないので私は追求しません。

疲れてきてコピペが雑になってきたので、
以上です
よろしくおねがいします >> 猛者共

2015年3月9日月曜日

InnoDB Deep Talk #2 (仮) に引っ張りだされました。

先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。

「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。

今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。


これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。

2015年2月4日水曜日

再出発します。

ご無沙汰しています。

 作ってから公開されるまでのタイムラグで思い出してまで書く余裕が無くて暫く更新をお休みしていました…。 その代わり、MySQL-5.7では細かい修正も含めてある程度思っていた通りのInnoDBの改善ができたのではないかと思います。

 で、本題。唐突ですが、先月末でInnoDBチームを辞しました。理由は色々ありますが、ネガティブな理由は一個もありません。願わくば、体がもう一つ欲しいくらいです。

 もう一度、自分のユーザー視点を現在のものにアップデートするべく、一般ユーザーに戻ります。その方がInnoDBを更にフットワーク良く改善できると考えたからです。とはいえ、今の立場で大きな案件があるまで、新しい領域には踏み込めないでしょう。暫くはInnoDBチーム在職中に行った変更で、リリース済みのものについて解説していきます。

その後、実用的な技術情報やツール(もしも作ったら)を共有していけたらと考えています。

 よろしくお願いします。
 これは寧ろ、MySQL-5.7は大丈夫だという証拠です。