mysql:10993

http://software.newsforge.com/article.pl?sid=04/12/27/1238216

MySQLを使ってＯＳの性能のベンチマークを測る
2005年2月8日（火曜）

Tony Bourke著

*nix ＯＳの系統にとっては嬉しいこの頃です。*nix
系統のＯＳの中で、機能が拡大され、性能も改善された版が
多くを発表されているからです。GNU/Linux, OpenBSD, NetBSD, FreeBSD, また
はSolarisをデータベース・サーバーに使っているのであれば
市場のハイプなどを聞いて、このリスト上にある他のＯＳに変更
しようかと思ったことがおありになるかも知れません。この記事では
MySQLを使ってこれらのOSの性能のベンチマークを測る方法
を示します。この方法で全体のシステムの性能や全体の
データベースのアプリケーションの性能を測れるという
わけではありませんが、与えられたプラットフォーム上で
MySQLの性能が分かります。

以下のプラットフォームを使用して比較します。

    * FreeBSD 4.11
    * FreeBSD 5.3
    * NetBSD 2.0
    * Linux 2.6
    * Linux 2.4
    * Solaris 10 x86 (build 69)
    * OpenBSD 3.6

それぞれのＯＳをテストするために、以下のハードのセットアップを
全てのテストに使用しました。

    * (2) 1 GHz Pentium III processors, 256 KB cache
    * 512 MB ECC Registered RAM (2x256 MB)
    * (1) 9 GB SCSI-160 (7200 RPM)
    * SuperMicro 370 Motherboard
    * AIC-7899 SCSI Bus

他の実験と同様、問題は同じハードのセットアップで
色々なＯＳでデーターベースの性能がどうなるのかと
いうことです。CPUはドュアル・システムなので、言い方
を変更して１つか２つかのCPUで実行されるＯＳ上での
データベースのソフトがどのような性能を示すかとします。

注意

ＯＳに関係する性能ベンチマークは非常に議論が多く
物議をかもします。ベンチマークは背後にある動機の
ために派手にまた誇大に使われてきました。ベンチマークを
批判するのは簡単です。というのも、ベンチマーク
であるので、スコープが限られており、結果に異議を唱える
際にこのスコープの狭さを利用できるからです。

MySQLテストは実際の全ての条件をテストできる訳では
ありません。また全ての負荷をシミュレートできるわけでも
ありません。MySQLは様々なタスク用に多くの実行環境
で使用されています。例えば、ウエブのコンテンツの管理
システム、オンライン・メッセージやウエブに関係のない
ウエアハウスなどです。

もしうまく測定されるのならベンチマークは自分のインストレーション
でシステムがどのような性能を発揮するかを予測できます。しかし、
テストがあなたのインフラと全く同じ環境でなければ違うシステム
では違う結果を出すでしょう。

ベンチマークを選択する

最初は様々なデータベースのアプリケーションを使用して
PostgreSQLとMySQLを使ってベンチマークをとろうと思いました。
目的は２つを性能の点から比較しようとしたのではなく、ＯＳに
もっと変化のある負荷を掛けてそれぞれのシステムの性能を
測ろうとしたものです。しかしながら、適当なベンチマーク
を探し、それぞれに６つのＯＳの場合を考えると、掛かる時間を考慮すると
明らかに時間が掛かりすぎるので、MySQLに限りました。

ベンチマークを測る際の根本的なチャレンジは実社会の
シナリオをどれだけ正確にシミュレートするかということです。
チャレンジは多くのＯＳに適応できて一貫した結果を
出すことのできるテストを探すことです。

PostgreSQLのpgbench

PostgreSQLのテスト用にpgbenchを検討してみました。これは
PostgreSQLにしか適用できません。複数のプラットフォーム
上でコンパイルできましたが、結果は30-100%のばらつきがありました。
それはどちらかというと実行毎のばらつきです。これだとあまり
結果を信用できません。でもこれは私だけが言っているので
はなくほかのユーザも同じことを言っています。結果が一定で
ないので、これは採用しないことにしました。

MySQLのsql-bench

sql-bench はPerlで書かれてデフォルトでMySQLに含まれます。今までに
試したＯＳの上では問題なくsql-bench を実行できました。あまり
現実的ではないかも知れないが包括的な負荷を集めてあります。
MySQLのPeter Zaitsev は私がこの記事を書くためにコンタクトした
際に私のsql-benchの選択について、「誰がループを使って
同じテーブルに1000回もALTER TABLEコマンドを発行するもんですか。」
と語りました。

OSDB

Open Source Database BenchmarkはI/Oのスループットとアルファ
プロセッサ上でLinuxの処理をテストするのに設計されました。
後に他のアーキテクチャーにも拡張されました。残念ながら
OSDBのテストをクラッシュせずにLinux上で実行できず
にいます。他のＯＳ用にコンパイルすることもうまく行きません。
OSDBは現在アルファです(sourceforge のページを参照)。だから
でしょう。なかなか有用に見えますが今回は見送りました。

Super Smack

Super Smackはsql-benchと一緒に使用すると有益です。ウエブが
絡んだデータベースの使う時によくあるselectとupdateの
オペレーションを提供するからです。コンパイルするのには
ちょっとばかり工夫がいります。 FreeBSD 4.10と 5.3,
OpenBSD 3.6, NetBSD 2.0 、 Linux 2.6 と 2.4の上でコンパイル
に成功しました。以下にそれぞれのＯＳ上で実行できるために
施した変更をドキュメントします。

SysBench

この記事を書くためにリサーチを行っているときに
MySQLのPeter Zaitsevから情報を得ました。Peterから２つばかり
新たなベンチマークを聞きました。その１つはSysBenchです。
これはMySQLと一緒に実行できOLTPベンチマークを測ることができます。
（これは他のデータベースにも適用できますが、今回は
他のデータベースには適用していません。）これはI/Oインテンシブ
な負荷の他CPUインテンシブな負荷(Super Smack同様) も掛けることができます。

リモートとローカル

他に考慮することはベンチマークをリモート（ＴＣＰ）で実行するか
ローカルに実行するかです。リモートに実行するのはベンチマークの負荷を
含まずにデータベースの負荷を生成できる恩恵があります。
しかし、MySQLはＴＣＰを介するよりもローカルのソケット
で実行する方が数段速いです。(大体Super Smackのテストより25%遅いです。
もっともそれはクエリを速い率で送った場合ですが）

Super Smackをリモートで実行した場合、結果はＯＳに関わらず
大体均一でした。ローカルで実行するとばらつきがあるので
変だと思いました。もっと変なのはローカルのテストが
ある場合はリモートの2倍の性能を示したことです。 TCPのとソケット
の速度の違いを考慮しても、リモートのテストでに性能は
これより良いはずです。

良く調査するとパケットの率が高すぎました。毎秒イーサーの
フレームが8500程度でした。これは非常に高い割り込みを
引き起こし（毎秒16800回）ます。これはどのNICを使用するかには
関係がありません。ちなみに私はビルトインのIntelの10/100と
SysKonnect系のギガビットのカードを使いました。クエリ高速率
がペイロードの大きさを小さくして(125 Byte程度) おり、
そのためパケットの数が多くなっていました。

私はSysBenchをリモートで実行することは出来ました。
生成された負荷はもっとコントロールできるパケットの率
になりました。これは重要です。というのはSolaris上で
Super Smackをコンパイルできないので、SysBenchのみ
がSolaris用です。

方法

それぞれのＯＳについては、前のインストレーションをハードドライブ
から除去して、クリーンにして新たにインストールしました。テストには
同じハードドライブを使用しました。完全にクリーンにすることで
全てのＯＳが公平にハードドライブを使用できることが出来ました。全部のＯＳに
関して同じようにファイルシステムをセットすることで(swap スペース
を最初の512 MB, ルート用に1.5 GB, 最後に /usr)、環境を
同じようにセットすることができました。この欠点は追加のテストを
実行する場合はまた再インストール必要があることです。そのために
余計な時間が掛かりました。

それぞれのＯＳのインストレーションはデフォルトのオプションを
使いました。必要に応じてカーネルを再コンパイルして、例えば
FreeBSDにSMPのサポートを追加したり、メモリーのサイズ
を増加したり。たいていの場合はMySQL用に薦められている以外
の変更は加えていません。ＯＳに加えた変更は以下にまとめてあります。

全てのＯＳは512 MBのswapがあります。 (ほとんど、使われませんでしたが。）
全てのBSDはアップデートオンにしてありました。Solarisは
UFS loggingがオンになっています。

MySQL

最新の版(これを始めた時）であるMySQL 4.0.22 tarball をMySQL
のサイトからダウンロードして使用しました。あるＯＳはすでに
コンパイルされていんましたが、BSDはコンパイルすることの
できるコードでした。あるものは少し古い版のMySQL (例えば4.0.20)
で色々と異なったオプションでコンパイルしているため、一貫性
に欠くところもあります。しかし、どちらにしろこのテストの
目的はＯＳのテストでMySQLのバイナリー版をテストするわけ
ではなく、ましてソースのビルドをテストしているわけでも
ありません。

my-large.cnfを基本的な MySQLコンフィギュレーション・ファイル
にしました。512 MB のRAM を薦められています。Peter Zaitsev
に薦められてInnoDB 用に幾つかのオプションを追加しました。

innodb_buffer_pool_size=256M
innodb_log_file_size=128M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1

リプリケーションはしないので、log-binをオフにしました。

ソースから MySQLをビルドするので、それぞれのプラットフォーム
に関してコンパイルのオプションをコントロールすることで
ＯＳだけが変数となるように出来ました。

ベンチマーク

最終的に２つのベンチマークを選択しました。
SysBenchと Super Smackです。

Super Smackに関しては予め用意されていた２つのsmackファイル
を使用しました。update-select.smack とselect-key.smackです。
10クライアントで10,000クエリで実行あたり全部で200,000クエリです。
それぞれのＯＳに関してsmackのファイルを3度実行して
結果を平均しました。

SysBenchに関しては,Peter Zaitsevのお勧めのとおり
２つの異なったセットのテストを実行しました。最初のセットは
テーブルの大きさは100万行でキャシングのためにCPUインテンシブ
な結果を期待できます。このテストは3回実行して結果を平均しました。

2番目のテストは1000万行でI/Oインテンシブの結果を出します。
ディスクのオペラーションが予想どうり大きいでしたが、
トランザクションの率はもっと低かったです。それぞれの
テストを実行するのにあるＯＳには一時間程度掛かり、2度しか
実行して平均を取りました。

全てのＯＳの上のテストでは個別の結果は驚くくらい
一貫していました。(だからこのテストを選択しました。)
それで、それぞれのテストの実行間の結果のばらつきは
あまりありませんでした。結果はOpenOfficeでは100ページにわたりました。

ＯＳのセットアップ

NetBSD と２つのFreeBSDsに関しては、MySQLのプロセスにメモリーを
増加するためにカーネルを再コンパイルしました。これは「error 12」
が多数観察されたためです。これはMySQLがmallocしようとして出来ない
ことを示します。BSDは全て１つのプロセス・サイズであると言う制限の
ためです。デフォルトは512MBです。サイズを増加させるには再コンパイルが必要です。 

1000万行のSysBenchテストを行う際、MySQLは必要とするメモリーの
サイズは600 MB に達してきます。大して512MBより大きくありませんが
問題を起こすには十分大きいです。

このカーネル・オプションを使用しました。

options MAXDSIZ="(896*1024*1024)"
options MAXSSIZ="(896*1024*1024)"
options DFLDSIZ="(896*1024*1024)"

OpenBSD 3.6 はデフォルトで1 GBのリミットとなっています。それで
これに関しては変更の必要はありません。それぞれのBSDに関しては
２つの異なったカーネルを使います。SMPサポート版とSMPがない
版です。GENERIC コンフィギュレーションを変更なしで使用しました。
（上の変更とSMPサポートを追加すること以外は）

OpenBSD 3.6

1プロセッサのテストにはstock BSDを使い、SMPテストには
stock bsd.mp kカーネルを使用しました。ファイルシステムは
OpenBSDのFFSでソフトアップデートがオンになっています。

Super Smackはデフォルトでは OpenBSD上ではコンパイルしません。
それはOpenBSDの定義がないからですが、幾つかフィックスを
client.ccに追加すると解決できます。

37行目のclient.ccで,  __FreeBSD__ を __OpenBSD__に変更。
同じファイルの51行目、 __FreeBSD を__OpenBSD__に変更。
これでSuper Smackはx86 とSPARC64（他のアーキテクチャー
はテストしていません）のどちらのアーキテクチャー
でも OpenBSDの3.4, 3.5, と3.6版でコンパイル可能となります。

NetBSD 2.0

NetBSD 2.0上でMySQLをコンパイルするのは容易で何の変更も
必要ではありませんでした。 Super Smackは少し困難でした。上記で
述べたOpennBSD の変更(__FreeBSD__ から __NetBSD__に変更) が
必要で、src/client.ccにヘッダーファイルを追加することと、小さな
ヘッダーファイルにLinuxの /usr/include/linux/sem.hから
次を加える必要があります。

union semun {
int val; /* value for SETVAL */
struct semid_ds *buf; /* buffer for IPC_STAT & IPC_SET */
unsigned short *array; /* array for GETALL & SETALL */
struct seminfo *__buf; /* buffer for IPC_INFO */
void *__pad;
};

この変更を加えてSuper Smackはクリーン・コンパイルし、テストを実行
出来ました。

FFS2 ファイル・システムはソフトアップデートがオンでNetBSD 2.0 の全てのパティション 

に使用されています。２つの異なったカーネルを作ってみました。
１つは１CPUで片方は２CPUです。これらはGENERIC ベースで上記の
プロセス・サイズの増加を含みます。

FreeBSD

FreeBSDに一番時間を使いました。というのはこのプラットフォームで
はMySQLの実行に色々なオプションがあるからです。これを
説明するためにMySQLを実行するのに問題があった古いFreeBSD
に付いて触れます。Jeremy Zawodnyの2002年9月のブログが
これを良くまとめています。（Jeremy ZawodnyはSuper
Smackを保守し、また「高性能MySQL」の共著もあります）
「FreeBSDは素晴らしいＯＳです。しかし、MySQLを使って
よく示せる問題点があります。スレッドのサポートです。
FreeBSDのスレッドの実装はあまり良くありません。全然だめ
だとは言いません。というのももっとひどくなり得るからです。」

これは2002年当時のFreeBSDに関して述べたものです。Zawodnyは
その後新たに投稿して、どの様にしてこの大きなスレッドの問題が
linuxthreadsとして知られている別個のスレッド・ライブラリー
を使用して解決できるかを示しました。FreeBSD の性能に
関する論争はメーリングリストで時々持ち上がります。これは特に
FreeBSDがLinuxと比較されるときに。

今日FreeBSD 5.3には幾つかの異なったスレッド・ライブラリーがあります。
KSEは5.3版ではデフォルトのスレッド・ライブラリーです。 linuxthreadsは
LinuxスレッドのFreeBSDでの実装です。libc_rはFreeBSD 4.11
のネイティブスレッドです。これらが全てではありません。ですが
この３つがベンチマークのテスト・プロジェクトで考慮されます。
FreeBSD-5ではプリエンプションやプロセス対システム　スレッド
のオプションがあります。

ご覧のように、MySQLが実行できるスレッド・ライブラリー
や環境要素のコンビネーションは幾つもあります。この記事の
全てをこのコンビネーションのために費やすことも可能です。
テストは数時間掛かるため、コンビネーションをメインなものに
限り他の人が成功裏に実行したテストのコンビネーションに
限りました。FreeBSD 5.3に関しては KSE (デフォルト)
とlinuxthreadsに. FreeBSD 4.11にはlibc_r (デフォルト)
とlinuxthreads.

MySQL 4.0.22版をデフォルトのKSE スレッド（容易）と
linuxthreads （少し複雑)のどちらとも使用してコンパイル
しました。FreeBSDにはPortsに何種類かのMySQLのサーバーの
版があります。この場合も同じデーターベースを使用してＯＳの
比較をしているのであって、ＯＳのパッケージのソフトを比較
しているのではありません。

標準のKSEを使用してMySQLをコンパイルするのは容易です。
MySQL 4.0.22 tarball　に含まれるコンフィギュアー・スクリプトを
実行して全てをセットし、makeで全てクリーン・コンパイルしました。

linuxthreadsに関しては、MySQL 4.0のPort版はlinuxthreads サーバー
をビルドするオプションを与えてくれます。これはかなり簡単
なプロセスです。しかし、これは少し古いMySQL 4.0の版です。
全体に一貫性をもたせたく、tarballのソースからコンパイル
することにしました。 Portsシステムを使ってlinuxthreads
ライブラリーをインストールしました。（場所は
/usr/ports/devel/linuxthreads). ここから、linuxthreads
ビルドのためのPortsインストール・コンフィギュレーション
を覗いてみました。そしてlinuxthreadsドキュメンテーションを
読みました。少しいじくってソースのtarballからlinuxthreads MySQL
バイナリーをビルドできました。他の方法は/etc/libmap.conf
を変更してlinuxthreadsをKSE-builtバイナリーにマップすること
もできます。(KSE-builtバイナリーはFreeBSD 4.10では
正しく作動しません。それで4.11では試していません).

ビルドを使うのであれば BUILD_OPTIMIZED=yesオプションを
使用してください。Ports ビルドのビルドの環境をチェックしていて
/usr/ports/databases/mysql40-server/のMakefileがGCCコンパイラー
オプティマイゼーションのオプションとして-0をデフォルトとして
していることに気ずきました。これはオプティマイゼーションと
しては軽い方です。これでは遅いMySQLサーバができてしまいます。
BUILD_OPTIMIZED=yesをセットすることで、より強健なGCCオプティマイゼーション
を設定できます。MySQLのコンフィギュレーションのスクリプトは
デフォルトで-03をオンにします。これはGCCにとっては最大の
オプティマイゼーションです。それでそれを使用しました。

どちらのFreeBSDにとってもlinuxthreads同様ネイティブ
のスレッドの結果も含みました。(5.3にはKSE 4.11にはlibc_r)

Super Smack はFreeBSD 5.3下ではclient.ccに簡単なフィックスを
加えるだけでクリーン・コンパイルしました。 FreeBSD 4.11 は
同様のフィックスを必要として、getopt.hを必要としました。
それでPorts collectionからlibgnugetopをインストールしました。
一旦インストールされ、Makefileに調整がなされると Super Smack
はクリーンコンパイルしました。

あるベンチマークを実行していると(この記事には含まれていませんが）
「Too many connections」の問題に遭遇しました。他のＯＳでは
全く問題になりませんでしたが。良く調べてみるとJeremy Zawodny
がMySQLのリストに投稿した問題と関連していることが分かりました。
しかし、問題の解決方は述べられていませんでした。グーグルサーチ
の結果MySQLのマニュアルの中に1000以上の同時セッションをLinux
上で実行させる解決方を発見しました。linuxthreadsのことに
触れているので、linuxthreadsを実行するFreeBSDにも適用されます。
それでそのフィックスを/usr/ports/devel/linuxthreadsにも適用しました。
その後テスト接続テストを成功裏に終わりました。FreeBSD-4で
1000以上の同時セッションを実行するのであれば、このことを
覚えておくと良いでしょう。

Solaris Express (build 69)

Solaris 10に関しては同じカーネルをどちらのテストにも使いました。
使用したファイルシステムはUFSでロギングがオンになっています。
(ZFSはまだ後数ヶ月かかります。）

GCC 3.3.2 パッケージはSun Freewareのサイトから入手して古い
ベータリリースのSolaris Expressの元でビルドしました。幾つかの
ヘッダーの問題があり全然コンパイルできません。Solarisは
コンパイラーを含んでいません。Sunフォーラムからのフィックス
を見つけて使いました。（現在Freeware サイトにポスト
しました。）その後はMySQLはクリーン・コンパイルしました。

Super Smackをコンパイルするのは非常な困難に遭遇しました。Super Smack
はflock()を利用しますが、これはSolarisでのサポートは乏しいです。
(これはBSDコンパチを通してのみです). libucbを使用すると
いう方法は他の方法と同様失敗しました。そのためSolaris 10
に関してはSuper Smackの結果はありません。

Linux

Linuxに関しては2.4と 2.6 のカーネルを使用しました。幾つもある
LinuxのディストリビューションのうちGentoo を使用することに
なりました。他のディストリビューション（例えばFedora Core)は
私が使用しているマザーボード上のAGPインターフェースに問題
があるため、使用できません。それでインストールしたカーネルがブートしません。
2.4に使ったカーネルのソースは2.4.29-gentoo-r5で2.6には
2.6.10-gentoo-r6. Gentooに関しては2.6用のNPTLをインストールする
のは比較的簡単でした。これは2.6のテストに使いました。
(もっともこれはNPTLでない2.6の結果と比較しても殆ど
変わりがありませんでした。） MySQL 4.0.22 のソースからの
コンパイルに問題はありませんでした。

Solaris とBSDに関しては１つのファイルシステムを利用しました。
(UFS/FFS). Linux ではいくつものファイルシステムを利用できます。
それは ext2, ext3, ReiserFS, JFS, XFS, やその他です。
それらのテストには ReiserFS (3版で Resier4ではありません)を使用しました。.

結論

MySQL.comのPeter Zaitsevに協力して頂き感謝したいと思います。
最初に彼にコンタクトをしたときはもう既に記事を書き終えていましたが、
テストのやり方にコメントを貰ってやり直しました。

色々な要素をつなぎ合わせるにはかなりの仕事量でした。そのため
時間も掛かりました。(OSのインストレーション, MySQLのセットアップ, テスト
の実行, そして繰り返し、そして繰り返し、そして繰り返し）しかし、
これはフリーかコマーシャルに関わらず同じハードと同じデータベース
を使用したUnixとUnixのようなＯＳのテストとしてはかなり
包括的なテストだと思います。このプロセスは数週間かかり
（2回は全く最初からやり直しで）30のCD-Rを使用しました。

全てのテストを終えて、結果をまとめて、一般に信じられている
どのＯＳが一番良いかという仮定に対するチャレンジできる
十分な結果が出たように思います。
次の記事で６つ全てのＯＳに関して発表します。
---------------------
Zen Kishimoto                        zen@xxxxxxxxxx
IP Devices, Inc.                       (408) 567-9391
2175 De La Cruz Blvd., Suite 10  (801) 720-8847 (FAX)
Santa Clara, CA 95050