需要が無いかもしれませんが、産まれて初めて、MySQL on Windows について触れます(起動したのも初めて)。
私自身はWindows上のMySQLを性能評価できる環境には無いのですが、
敢えてSQL ServerとWindowsという相手のホームグラウンドでアウェイ対決させよう、
という猛者のためにこのエントリを残します。
猛者向けですし、私は無責任でおねがいします。陰ながら応援します。
MySQL on Windows
MySQLの性能・スケールを追求・普及していく上で、Windows上での性能評価はやはり避けては通れないと思います。
（実際にどこまで使うかは別として、正確な要素比較は必要でしょう。）
しかし、標準APIを使わなければいけない「地の利が無い」状態では不安が残ります。
できるだけ不安要素は予め解消しておきたいものです。
経験上、不安要素は３つあります。
(1) メモリアロケータ
Linuxでも、glibcのmalloc()はコンパクトですがスケールがよろしくないので、
jemallocなどのスケールするメモリアロケータをLD_PRELOADで読み込まないと、
InnoDBはそのポテンシャルを発揮できません。
当然Windowsでも似たような状況であるはずです。
(2) ファイルIO
実際に遭遇したものを挙げると、fsyncとwriteの並列性が悪く、アプリケーション側でシリアライズしないと
性能が落ちてしまう事象に遭遇した(間接的にクレームを受けた)ことがあります。
更新が多く、トランザクションログの書き込みがボトルネックとなるような場合は注意が必要でしょう。
(3) イベント
InnoDBでは、内部のmutex/rw_lockのロック待ちでは、スピンとイベント待ちの２段構えです。
バッファプールのブロックあたり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のリテラルを含む３ファイル、
"
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に変換しようとする…
こんな感じ
--- 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;
}
バグの実害は多分ない、クラッシュリカバリ時にログにエラーが山のように残るだけ。。。
--- 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ではなんかリンクする順番が変わってしまうのか上手くいかなかったです。
今のところこれ以上調べる理由はないので私は追求しません。
疲れてきてコピペが雑になってきたので、
以上です
よろしくおねがいします >> 猛者共
