OSS iPedia

2006-03-31 ミラクル・リナックス(株)

1.はじめに

1.1.目的

OSS-DB 開発基盤 WG において過去に MySQL サーバーの測定例がない CPU アーキテクチャである Intel Xeon デュアルコア版および AMD Opteron を搭載したマシンを用い、 MySQL データベースサーバーのパフォーマンス測定を実施し、各アーキテクチャの特性の分析と考察を行なう。

本書では AMD Opteron の測定結果を取り扱う。

1.2.測定環境

1.2.1.システム構成

マシン 1台の上で測定対象の MySQL サーバーと測定ツール DBT-1 を動作させて測定を実施した。

1.2.2.ハードウェア

以下のハードウェア構成のマシンを用いた。

• Sun Fire X4100
  • CPU: AMD Opteron 254 x 2 (2.8GHz, AMD64, L2 1MB)
  • Memory: 8GB (DDR/400, ECC)
  • Storage: 73GB (RAID1, 73GB x 2, SAS, 10000rpm, 2.5inch)
  • 特徴:
    • シングルコア Opteron の最上位版 (2006年3月現在)
    • AMD64 (x86-64) 対応
    • SAS (Serial Attached SCSI) 接続で2.5インチのハードディスク

1.2.3.ソフトウェア

OS と MySQL は 64 bit (x86-64)、DBT-1 は MySQL Connector/ODBC が 64bit 対応していないために 32bit (IA32) とした。

• OS
  • 名称: MIRACLE LINUX V4.0 (Asianux 2.0) for x86-64
  • カーネル: Linux 2.6.9-11.25AXsmp
  • アーキテクチャ: x86-64 (64bit)
  • ファイルシステム: ext3
  • 備考: 2006年2月1日時点での最新パッケージを適用
• RDBMS
  • DB サーバー: MySQL 5.0.18 (64bit バイナリ)
  • DB ドライバ: MySQL Connector/ODBC 3.51.12 (32bit バイナリ)
  • 測定ツール: OSDL DBT-1 v2.1 MySQL(ODBC) 1.0 (32bit バイナリ)

1.2.4.環境設定

2005年度上期「『OSS 性能・信頼性評価 / 障害解析ツール開発』 DB 層 〜 OSDL DBT-1/3 による DBMS 評価編」に沿って環境構築を行なった。それ以外の環境については、基本的にすべてデフォルトとしてある。

MySQL サーバー (mysqld) のパラメーターは以下のように設定した。2005年度上期後にリリースされた MySQL 5.0.8 以降で innodb_thread_concurrency のデフォルト値が 8 から 20 に変更されたため、条件を一致させるためにパラメーターを追加した。

• max_connections=120
• innodb_thread_concurrency=8
• innodb_buffer_pool_size=1024M
• read_buffer_size=1M
• query_cache_size=12M

CPU の構成は次の 2 種類の状態で測定を行った。

• UP (CPU 数 1)
  • カーネルパラメーター maxcpus=1 を指定
• SMP (CPU 数 2)
  • カーネルパラメーター maxcpus=2 を指定、あるいは指定なし

2.測定手順

2005年度上期「『OSS 性能・信頼性評価 / 障害解析ツール開発』 DB 層 〜 OSDL DBT-1/3 による DBMS 評価編」を参照のこと。

3.2005年度上期チューニング後パラメータにおける測定

3.1.測定内容

MySQL サーバーに 2005年度上期のチューニング後パラメーターを設定し、EU を変化させたときの性能を測定した。

3.2.測定結果

3.2.1.BT/s

2005年度上期までのすべての測定結果を上まわる好成績となった。

ただし、2つの欠点らしき傾向がある。1つは CPU がボトルネックであるにもかかわらず、UP → SMP 時のピーク性能が僅か 126% にしか伸びない点。これは Intel Xeon の UP→ SMP 時の 168%、Xeon デュアルコアのコア 1 →コア 2 時の 150% に比べ、極めて悪い。もう 1つは、ピーク性能以上の EU において、性能の劣化が若干大きい傾向にある点だ。

3.2.2.CPU 利用率

いずれの傾向も Intel Xeon とほぼ同じとなっている。あえて違いを挙げるならば、若干ではあるが I/O 待ちが多い傾向にある点、そして SMP の場合のピーク性能時のアイドルが 2〜3% ほど多い点が異なる。

3.2.3.平均応答時間

3.3.考察

3.3.1.UP → SMP 時の性能の伸び率の低さ

過去に発表された各種ベンチマーク結果や経験によれば、一般的に、UP → SMP の性能の伸びは少なくとも 150% 程度にはなる (CPU 性能がボトルネックの場合)。これに対してわずか 126% しか伸びていないため、明らかに異常な数値に感じられる。Opteron の特性に合わせた最適化により改善する可能性はあるが、現時点では Opteron SMP の限界である可能性も否定できない。

3.3.2.CPU 利用率の I/O 待ち割り合いの多さ

ストレージに 2.5インチのハードディスクを採用しているため、同等スペックの 3.5インチハードディスクよりも性能が低いことが起因しているものと思われる。比較的新しい規格である SAS を採用していることから、デバイスドライバの完成度にも疑問が残る。

3.4.今後の課題

過去に Opteron における測定例がないことから、今回の測定で観測できた特性が正常なものなのかの判断がついていない。今後より多くの測定と分析を重ね、確証を得る必要がある。

4.MySQL チューニングパラメーター変更に対する性能への影響

4.1.測定内容

2005年度上期のチューニング後パラメーターを基本とし、代表的なチューニングパラメーターのほか、CPU アーキテクチャの違いにより効果が異なる可能性があるパラメーターを追加あるいは変更して DBT-1 を測定した。

EU の値は、BT/s の値が理論値を下回り、ほぼピーク性能に近い BT/s を記録した 3000 を採用した。

なお、マシンを利用できる時間が限られていたため、今回は CPU が 1つの場合の測定は見送った。CPU 2 つの場合についても必要最低限のパラメーター値だけ測定した (デフォルト値とデフォルト値前後の値のみ)。このため、パラメーター値変動による効果は観測できたものの、ピーク性能を判明するには至っていない点をおことわりしておく。

4.2.測定結果

性能の影響が認められたパラメーターの結果のみを示す。性能向上が認められた値には網掛けと太字で示してある。

パラメーターの意味は以下の通り (MySQL 5.0 の英語版オンラインマニュアルより):

• innodb_concurrency_tickets InnoDB の処理に同時に入ることのできるスレッドの数は、innodb_thread_concurrency の値に制限される。InnoDB 処理中のスレッド数がこの値に達していると、新たに InnoDB に入ろうとするスレッドはキューに入れられる。スレッドが InnoDB の処理に入れる状態になると、スレッドに innodb_concurrency_tickets の数だけ「自由利用チケット (free tickets)」が発行され、チケットの回数だけ自由に InnoDB の処理に出入りできるようになる。チケットがなくなると、再び同時スレッド数の制限が課せられる。
• innodb_sync_spin_loops InnoDB mutex が開放されるのを待つとき、スレッドを一時停止する前に実行するスピンロックの試行回数である。
• innodb_thread_concurrency InnoDB の処理を同時に実行できるスレッド数の上限値である。MySQL 5.0.8 以降にデフォルト値が 8 から 20 に変更され、無制限を意味する値が 500 から 20 に変更されている(つまり、デフォルトは制限なし)。
• innodb_thread_sleep_delay スレッドが InnoDB のキューに入る前にどのくらいの期間スリープするかを指定する。単位はマイクロ秒。

InnoDB の最大スレッド数を無制限に設定した場合 (innodb_thread_concurrency=20) はスレッド数のチェックやスレッドが InnoDB キューに入ることはなくなり、innodb_concurrency_tickets と innodb_thread_sleep_delay パラメーターの効果はなくなると思われるが、確認はしていない。

以下のパラメーターについては測定結果への特異な影響が見られなかったため、ここでは省略する。必要であれば、別途、個別の性能データを参照してほしい。

• innodb_additional_mem_pool_size
• innodb_buffer_pool_size
• innodb_checksums
• innodb_commit_concurrency
• innodb_doublewrite
• innodb_file_io_threads
• innodb_flush_method
• innodb_max_dirty_pages_pct
• innodb_support_xa
• join_buffer_size
• key_buffer_size
• query_cache_size
• read_buffer_size
• sort_buffer_size

4.3.考察

4.3.1.innodb_concurrency_tickets
innodb_sync_spin_loops
innodb_thread_sleep_delay

Intel Xeon と同様、値を調整することで性能を上げられる見込みがあるようだ。測定データが不足しているため、どこまでピーク性能が伸びるか観測できなかったのが残念である。

4.3.2.innodb_thread_concurrency

最大スレッド数を無制限にすることで 10% 程度性能を上げることができた。CPU の利用率は 100% に近づいており、逆に利用率が下がった Intel Xeon デュアルコア (HT 無効の場合) とは異なる結果となった。

4.4.今後の課題

マシンスケジュールの都合で判明できなかったピーク性能を測定し、Xeon との比較をより深く分析したい。

今回は単一のパラメーターだけに注目して測定したが、複数のパラメーターを組み合わせることでさらなる性能向上も期待できる。パラメーターの組み合わせによっては相乗効果を生んだり打ち消し合うものが考えられるため、各パラメーターの効果を理解した上で組み合わせ、より質の高いチューニングを実施するとよいだろう。

このデータの性能データ

関連する考察データ