OSS iPedia

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

1.はじめに

1.1.目的

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

本書では Intel Xeon デュアルコアの測定結果を取り扱う。

1.2.測定環境

1.2.1.システム構成

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

1.2.2.ハードウェア

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

• DELL PowerEdge 1850
  • CPU: Intel Xeon x 1 (2.8GHz, Dual core, HT, EM64T,L2 2MB/core, FSB 800MHz)
  • Memory: 4GB (DDR2/400, ECC)
  • Storage: 146GB (RAID0, 73GB x 2, FC, 10000rpm, 3.5inch)
  • 特徴:
    • デュアルコア CPU
    • EM64T (x86-64) 対応

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日時点での最新パッケージを適用
• DB
  • 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 の構成は次の 3 種類の状態で測定を行った。

• CPU コア 1、HT 無効
  • カーネルパラメーター maxcpus=1 を指定
• CPU コア 2、HT 無効
  • カーネルパラメーター maxcpus=2 を指定
• CPU コア 2、HT 有効
  • カーネルパラメーター maxcpus=4 を指定、あるいは指定なし

2.測定手順

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

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

3.1.測定内容

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

3.2.測定結果

3.2.1.BT/s

結果全体の概観としては、Intel Xeon シングルコア搭載 SMP マシンの結果と類似したものとなった。

CPU コア 1つとコア 2 つで比較してみると、ピーク性能が約 150% 伸びている。この伸び率は、2005年度上期測定結果の Xeon シングルコアにおける UP → SMP 時の伸び率の 168% よりも低いが、2005年度下期測定結果と同等である。

HT (Hyper-Threading) の有無で比較してみると、これも上期と同じく性能差はほとんど認められない。HT 無効のほうがわずか 1% だけピーク性能が高いが、EU を増してゆくに従い同じ性能値に収束してゆく。マルチスレッドで動作する MySQL サーバーは HT との相性は良いと予想していたため、意外な結果となった。

3.2.2.CPU 利用率

これも Xeon シングルコアの UP / SMP と似た結果となった。コア 1つの場合は EU 増加に伴いほぼ 100% に収束してゆく一方、コア 2つのときは最高でも 95% 程度にしかならない。この傾向は HT を有効にした場合のほうがやや強い。

HT の有無で比較すると、ピーク性能以下の EU で若干ではあるが HT 有効のほうが利用率が低くなっている。

3.2.3.平均応答時間

HT の有無で比較してみると、性能 (BT/s) が理論値から下がり始めるまでの EU において、HT 有効のほうが応答時間が長くなっている。その差は EU の値が高いほど大きい。

3.3.考察

3.3.1.CPU コア 1 → コア 2 時の性能の伸び率の低さ

Xeon シングルコア SMP にはない Xeon デュアルコア特有のボトルネックが発生している可能性が考えられる。一口にデュアルコアといっても、L2 キャッシュを全コアで共有しているか各コアで独立して持っているか、キャッシュのコヒーレンシ制御を CPU 内部で行なうか外部のバスやチップセットを介して行なうか、バス (Xeon の場合は FSB, フロントサイドバス) とのインターフェイスを共有しているか独立して持っているかといった様々な違いがある。この違いはデュアルコア CPU と SMP 構成の CPU と比較した場合も同様であり、コアの性能は同じでもコア周辺の差により性能差が生じることは十分に考えられる。CPU 利用率や I/O 負荷などほかに顕著な差は見られないことから、こういった CPU の構造が影響している可能性が高いと考えられる。

なお、今回測定に用いた DELL PowerEdge 1850 に搭載の Xeon デュアルコア 2.8GHz は、次のようなブロック図になっている。

I/F: Interface, MCH: Memory Controller Hub, FSB: Front Side Bus

3.3.2.性能劣化が始まる前の EU における HT 有効時の応答時間の遅延

問題となっている EU の範囲のおいて CPU の利用率が低くなっていることから、MySQL サーバーが HT の特性を生かせていないと考えられる。

3.4.今後の課題

今回の測定によって様々な特性を観測できたが、その原因を特定するまでには至っておらず、今後の課題とした。より詳細な分析を行うには、周辺ハードウェアも含めて可能な限り近いスペックの Xeon デュアルコア CPU マシンと Xeon SMP マシンを用意し、DBT-1 に加えて OProfile などのより詳細な分析ツールを利用して両者を比較することになるだろう。

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

4.1.測定内容

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

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

なお、CPU コアが 1つの場合の測定は行なっていない。CPU 2 つの状態で HT の有無の 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

値を調整することで 5〜10% 程度性能を上げることができた。その一方で CPU 利用率が下がっているため、別のパラメーターを調整すれば、さらなる性能向上も可能であると考えられる。

全体的に HT 無効のほうが性能の絶対値も伸び率も高い傾向にあり、ここでも HT との相性の悪さを露呈してしまっている。

4.3.2.innodb_thread_concurrency

HT が無効の場合、最大スレッド数を無制限にすることで 10% 程度性能を上げることができた。その一方で CPU 利用率が下がっているため、別のパラメーターを調整すれば、さらなる性能向上も可能であると考えられる。

HT 有効の場合には著しく性能が低下してしまった。HT 有効の場合の分析と考察については、別途 OProfile による測定・分析結果 (FIXME: リンク) を参照のこと。

4.4.今後の課題

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

HT はほとんど効果がないどころか、パラメーターによっては使い物にならないくらい低下してしまう問題はかなり深刻である。もう一つの OSS DB の雄、PostgreSQL はバージョン 8.1 で大幅に性能向上を果たした上に HT の効果も増しており、MySQL が PostgreSQL より性能優位という神話は崩れさろうとしている。これからも両雄が互いに競い合い成長するためにも、この問題の解決に向けて真剣に取り組む必要があるだろう。

このデータの性能データ

関連する考察データ