日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

Linux on z Systems における MongoDB の性能評価
根岸 康

小原 盛幹

河内谷 清久仁Linux on z Systems の最新の IBM z13 プロセッサ上での MongoDB3.0 の性能について，Yahoo! Cloud
Serving Benchmark(以下 YCSB) を用いて 特に mongoDB デーモンの core スケーラビリティーに注目して評価した．また，同様の測定を Intel Xeon プロセッサ E5-2699 v3 上でも行い性能を比較した．
性能測定の結果，Linux on z Systems では Intel Xeon プロセッサの 1.7-2.2 倍のスループットが得られること，ハードウェアマルチスレッディングにより Xeon プロセッサの場合 22.6%，z Systems の場合 30.1%性能が向上することが分かった．また，YCSB による性能測定に際して，MongoDB により大きな負荷を与えるために YCSBプロセスを複数走らせることが有効であることが確認できた．
We evaluated performance of MongoDB on Linux on z Systems with IBM z13 processor by using Yahoo!
Could Serving Benchmark(YCSB) with focusing on core scalabiliy of MongoDB daemon. We also did similar
performance measurements on Intel Xeon Processor E5-2699 v3, and compared the performances on Xeon
and Linux on z Systems.
According to our performance measurements, we confrimed that throughput on Linux on z Systems is
1.7-2.2 times better than that on Intel Xeon Processor, and hardware multithreading improve the performance by 22.6% and 30.1% on Xeon processor and z Systems respectively. We also confirmed that it isuseful for generating larger workload on MongoDB to run multiple YCSB processes.

データベースシステムの統合に用いられる事例 [15] が1 はじめに多く，多数のシステムを 1 つに集約するシステム集約

従来の Oracle [19] や DB/2 [6] のような Relationalに多く用いられる Linux on z System 上と MongoDB

データベースに代わり，NoSQL データベースが普及との組み合わせは相性がよいと考えられるが，これましている．本論文では，NoSQL データベースの中でで性能評価は行われてこなかった．

最も普及しているデータベースである MongoDB [16]

本論文では，MongoDB の Linux on z System 上に着目し，Linux on z System 上 [9] での性能を評価での性能について，特に MongoDB のコア数に関すする．

るスケーラビリティーに着目して評価する．

Linux on z System は単純で柔軟なシステム構成と高い性能スケーラビリティーを持つが，これまでは Oracle や DB/2 等の Relational Database を用いた Transaction 処理に用いられることが多く，Mon-2 システム構成について
この章では，本論文で使用するシステムについて説明する．

goDB のような NoSQL データベースにはあまり用いられてこなかった．MongoDB は複数の Relational
Performance Evaluation of MongoDB on Linux on z
Systems
Yasushi Negishi, Moriyoshi Ohara, Kiyokuni Kawachiya,
日本アイ・ビー・エム (株) 東京基礎研究所, IBM Research - Tokyo.

2. 1 MongoDB について
MongoDB の特徴として以下のものが挙げられる．
1. (データ構造) スキーマを持たず，データを階層型データ構造で管理する．このため，データ構造の変更に柔軟に対応でき，複雑なデータ構造の表

現も比較的容易である．

ルで提供する．

2. (排他制御方式) MongoDB では同一マシン上で4. (投資の継続性) z Systems では最新のハードは isolated オペレータにより複数の文書に跨るウェア，ミドルウェア，アプリケーションをサ処理を一貫して行うことが可能であるが，この操ポートする一方で，従来のシステム・アプリケー作はクラスターではサポートされていない．このションを長期間サポートする．

ため複数のマシンに跨るトランザクション処理を

z Sytems のこのような特徴により，複数のシステ行う必要がなく，各マシンがデータを個別に扱うムを１台のメインフレーム上に統合することが容易ことが可能であるため性能がスケールアップしやになる．多数のシステムを集約することにより，デーすい．

タのやり取りのオーバヘッドやシステム・コア単位の3. (メモリ上で動作) ディスクではなく，メモリ上ソフトウェアコスト，運用・設置・エネルギーコストでの動作を前提としており，高性能を出しやすい．

を削減することが可能になる [4]．2013 年の IDC レMongoDB のこのような特徴は，多数のマシン上ポートによれば，z Sytems によるシステム集約によのシステムをより少ないマシンで統合するシステムり平均 57%の運用コストが削減された [12]．

統合に向いている．例えば，MetLife は従来 70 台のLinux on z Systems は z Systems 上で稼動する

Relational データベースで管理していた顧客情報をLinux システムである．以下のその特徴について説明

MongoDB で統合した [15]．

する．

今回の測定では，2015 年 3 月にリリースされた

1. (Distribution) 標準的な Linux Distribution，MongoDB3.0 を WiredTiger と呼ばれるストレージLinux カーネルがそのまま動作する．最新のメエンジンと共に使用する．この組み合わせでは，これインフレームである IBM z13 上では，現在 Redまでのデータベース単位のロックに代わりドキュメン

Hat Enterprise 7.1 と SUSE Linux Enterprise

ト単位のロックが採用されており，これまでの版と比12 がサポートされている．

較して，絶対性能・スケーラビリティーが大きく向上している [17]．

2. (仮想化方式) LPAR(Logical Partition) と呼ばれるハードウェア上で直接動作する仮想化環境と zVM と呼ばれる zOS が提供する仮想化環境

2. 2 Linux on z Systems についてがあり，必要とされる性能や仮想環境の数に合わ

z Systems はいわゆるメインフレームと呼ばれるマせて組み合わせて使用される [10]．

シンであり，以下の特徴を持つ．

1. (集中計算モデル) 性能，スケーラビリティー，可用性，信頼性，セキュリティーを 1 つのシステ

3. (スケーラビリティー)

File I/O やメモリバ

ンド幅，ネットワーク等が仮想化されており動的にアサインされる．

ムで提供する．集中計算モデルもたらす単純さにLinux on z Systems により，従来のメインフレーより管理・維持・セキュリティーコストが削減でム上のアプリケーションのみならずより多くのシステきる．

ムを一つのシステムに集約することが可能になる．

2. (高 い ス ケ ー ル アップ 性 能) z Systems で は ，

これまで Linux on z Systems は z OS 上の Rela-

CPU，キャッシュ，メモリ，ディスク等全てのtional データベース等を利用したアプリケーションの資源を共有し，高い性能で利用可能にする．こ移行等が多かったが，今後は MongoDB 等を利用しれにより，単純に必要な資源を追加することで，たシステム統合にも用いられることが多くなると考性能をスケールアップさせることを目標としてえられる．

いる．

3. (高可用性・高信頼性・災害対応) 可用性・信頼性・災害対応に必要な全ての機能をシステムレベ

H/W configuration for YCSB AǆƉĞƌŝŵĞŶƚĂůĞŶǀŝƌŽŶŵĞŶƚ

2. 3 MongoDB on Linux on z Systems
2. 2 節で述べたとおり，Linux on z Systems は標
準的な Linux ディストリビューションやカーネルを用いており，ほとんどのアプリケーションは再コンYCSB benchmark (client emulator)

MongoDB
daemon
1-8 CPU cores䠺

20 CPU cores
H/W configuration for YCSB B&C

パイルより移植可能である．また，アプリケーショ

MongoDBdaemon

YCSB benchmark(client emulator)

YCSB benchmark(client emulator)

ンが java 言語等のバイトオーダを規定している言語

1-8 CPU cores

14 CPU cores

14 CPU cores

で記述されている場合は移植不要である．MongoDB
は，C/C++言語で記述されており同一のアドレス

図1

測定環境の構成に異なるバイト長でアクセスする場合があるため，zSystems とインテル x86 プロセッサのバイトオーダ

YCSB に よ る MongoDB の 性 能 測 定 で は Mon-の違いに対応する必要がある．バイトオーダの違いへ

goDB に十分な負荷を掛けるために YCSB と Mon-の対応方法の詳細については [7] を参照のこと．

goDB と同一のマシン上で動作させることが多い [18]．

MongoDB の Linux on z Systems への移植に際し今回の測定でも図 1 のように YCSB を MongoDB とて，通信プロトコルやメモりマップトファイルへの対同一のマシン上に置くことにした．YCSB と Mon-応のためにメモリ上では常に x86 と同じリトルエン

goDB を同一マシン上に置くことにより，YCSB・ディアン形式でデータを保持しており，2 バイト以上MongoDB 間通信のスループットとレスポンスを向上のメモリアクセス毎にエンディアン形式を変更してさせ，より多くのワークロードを発生できる．また，いる．

YCSB が MongoDB からの応答待ちでブロックする

MongoDB は，2015 年 2 月にバージョン 3.0 への時間も削減できる．

メジャーアップデートが行われた．現在，Linux on z

同一マシン上で MongoDB と YCSB を動作させる

System 上ではメジャーアップデート後のバージョン場合，全てのコアに MongoDB と YCSB の両方の負3.0.4 が使用可能である [5]．

荷がかかり，コアスケーラビリティーを測定することができない．このため，MongoDB と YCSB が動作

3 ベンチマーク測定環境及び測定手順についてするコアを taskset コマンドより固定し，MongoDBに割り当てるコア数を変化させ性能を測定した．更マシンとしては，Intel Xeon プロセッサ E5-2699に Intel Xeon プロセッサ上では，使用するメモリのv3 [13] と IBM z13 [8] を使用する．また，ベンチマー割り当てを制御するために numactl コマンドを使用

クソフトウェアとしては NoSQL のベンチマークとしした．IBM z13 では numactl コマンドは提供されてて標準的な Yahoo! Cloud Serving Benchmark(以下いないため使用しなかった．

YCSB) [21] [3] を使用し，ワークロードとして，YCSB

3. 1. 2 シャーディングA(write-heavy), B(read-mostly), C (read-only) の 3

MongoDB のシャーディング機能は，データを複数つを用いて性能を測定した．Intel Xeon Core プロのサーバに分散して保持する機能で，この機能によりセッサと IBM z13 では可能な限り同一の条件を用い複数のマシン間で負荷を分散させ性能と対故障性をて測定を行う．

向上させることができる [20]．MongoDB2.0 ではロックがデータベース単位であったため，ロックにより十3. 1 ベンチマーク構成分なコアスケーラビリティーが得られない場合に単一

3. 1. 1 マシン構成

マシン上でシャーディング機能を使用してデータベー

本論文では，YCSB を用いて単一マシン上でのスを水平分割し，スケーラビリティーを向上させるこ

MongoDB の絶対性能とスケーラビリティーに着目して性能評価を行う．とがあった [2]．
今回の測定では，2015 年 3 月にリリースされた1

MongoDB3.0 を WiredTiger と呼ばれるストレージ

Intel Xeon プロセッサ: HP P440 RAID con-エンジンと共に使用する．2. 3 節で述べたとおり，こtrollerの組み合わせではデータベース単位のロックに代わり，IBM z13: DS8800 High Performance Storage

文書単位のロックを採用しており，絶対性能とスケー
ラビリティーが大きく向上した．このためシャーディ

3. 3 ソフトウェア構成

ングを使用しなくても，良好なスケーラビリティー

ソフトウェア構成は，z Systems で SMT2 を使用すを得ることができた．予備的な実験によれば，シャーるために用いた preliminaly 版の Linux kernel を除ディングを使用しない場合の方が，する場合と比較

き Intel Xeon プロセッサと z Systems で共通である．

してよりよい性能が得られたため，今回の測定ではシャーディングは使用しないことにした．

3. 1. 3 YCSB プロセス
今回の測定では，YCSB プロセスを 1 つもしくは 21. (Distribution)
Red Hat Enterprise Linux 7.1 (Maipo)
2. (Linux Kernel)
Linux kernel 3.10.0.229(Red hat Enterprise

つ使用して性能を測定した．YCSB プロセスを 2 つLinux 7.1 標準)

使用した理由は，特に YCSB B と C で MongoDB に(但し，z Systems で SMT2 の使用時は prelimi-

割り当てるコア数が大きい場合に MongoDB の CPU

nary 版カーネルを使用)

利用率が低くスループットが向上しない場合があり，その原因が YCSB プロセスが十分な負荷を発生していないことにあると考えたためである．YCSB プロセスを 2 つ使用した場合，出力結果の Throughput を

3. (ファイルシステム)
xfs
4. (YCSB ベンチマーク)
YCSB (0.2.0-SNAPSHOT 2015/06/19 版)

合計したものを全体の Throughput とした．YCSB

5. (YCSB 用 Java 環境)のプロセス数の違いによる性能については，第 4. 2 節

IBM SDK Java 7.1.3

で述べる．

6. (MongoDB)
MongoDB 3.0.4 with WiredTiger

3. 2 ハードウェア構成
IBM z13 では LPAR(Logical Partition) と呼ばれるハードウェア上で直接動作する仮想環境を用いた．

Intel Xeon Core プロセッサでは仮想環境は用いずに直接マシン上に Linux を動作させた．

1. (プロセッサ)
Intel Xeon プ ロ セッサ: E5-2699 v3 2.3GHz3.6GHz, コア数 18
IBM z13: 5GHz, 最大コア数 141
2. (ハードウェアマルチスレッディング)Intel Xeon プロセッサ: Hyperthreading
IBM z13: SMT2

3. 4 ベンチマークパラメータ
YCSB ベンチマーク実行時のパラメータは以下を用いた．

1. (ワークロード)YCSB A(write-heavey)，YCSB B(read-mostly)，
YCSB C(read-only)
2. (DRIVER)
mongodb-async
3. (RECORDCOUNT)
100,000
4. (OPERATIONCOUNT)

どちらも Enable した場合，しない場合の両方を10,000,000 * “mongoDB デーモンに割り当てた

測定コア数”

3. (メモリ)Intel Xeon プロセッサ及び IBM z13: 64 GB
4. (ディスク)5. (YCSB Thread 数)
予備実験にて各測定条件で最適な数を選択

YCSB による負荷を最大化するために mongodb-async driver を使用する [1]．mongodb-async driver

3. 5 システム設定

は mongodb からの応答を一定の回数まで待ち合わ

性能測定に当たっては，MongoDB のガイドのとせせずに次の要求を送信するために，YCSB が mon-おり，THP(Transparent Huge Page) を無効にした

godb からの応答を待ち合わせる時間を削減でき，より[14]．また，IBM z13 のディスク I/O 性能を改善する

多くのワークロードを発生できる．この async driver

ために HyperPAV [11] を使用した．HyperPAV は同は元々は YCSB へのパッチとして提供されていたが，一の LPAR から同じディスクへの複数の I/O 操作を

0.2.0-SNAPSHOT にて，標準の YCSB ドライバに並列に実行することを可能にするモジュールで，並列統合された．今回の測定ではこの統合された版を用い度 16 として使用した．

た．OPERATIONCOUNT は各測定の測定時間が約20 分となるように MongoDB デーモンへの割り当て

3. 6 性能データの取得コア数に比例して設定した.

性能測定に際しては，nmon コマンドを使用してプYCSB の引数として YCSB Thread 数が指定可能である．YCSB Thread 数は少なすぎると十分なワーロセッサ，メモリ，ディスク，ネットワーク使用率の時間経緯のデータを取得した．

クロードを発生することができず，多すぎると同期のオーバヘッドが増加するため，この Thread 数を調4 測定結果及び測定結果の考察整することで性能を最適化できる．今回の測定では，

図 2 は，各条件での測定結果を示したグラフであ

事前に 1/10 の LOOPCOUNT で YCSB の Threadる．グラフ中の noHT/HT は Intel Xeon プロセッサ数を変化させて測定を行い最もよい性能が得られたの HyperThreading 使用の有無，noSMT/SMT2 はTread 数で性能を測定した．

IBM z13 の SMT2 使用の有無，1ycsb/2ycsb は使用使用した Thread 数は以下の通り．

した YCSB プロセスの数を示す．
本章では，これらの測定結果について気づいた点をworkload

#core

Xeon

Xeon

z13z13-noHT-HT-noSMT-SMT2

まとめ考察する．

A

1412974. 1 CPU utilization

A

25444

最初に YCSB が MongoDB に十分に負荷を与えらA44444

れているかを確認するために MongoDB に割り当て

A84444たコアの CPU 負荷率について検討する．図 3 は，各B

144814B

285614B

4202089B89859C

196614C

278816C41618820C81818910

条件での CPU 負荷率を示すグラフである．

YCSB A(write-heavy) では CPU の負荷率は比較的低い傾向があるが，これはディスク書き込みの影響と考えられる．

YCSB B(read-mostly) と YCSB C(read-only) では mongoDB デーモンへの割り当てコア数が多い場合に 1YCSB プロセス使用時に CPU の利用率が低下しているが，2YCSB プロセス使用時には割り当てコア数が 8 の場合でも 85%以上を保持している．2YCSB
プロセス使用により CPU 利用率が向上する原因については現在調査中だが，MongoDB と YCSB 間のsocket 通信時になんらかの理由プロセス単位での性能の制約が発生していると考えられる．

WhhƚŝůŝǌĂƚŝŽŶͲ z^;ǁƌŝƚĞͲŚĞĂǀǇͿϭϬϬϬϬϬϱϬϬϬϬϬϭϮϰϴWhhƚŝůŝǌĂƚŝŽŶ;йͿdŚƌŽƵŐŚƉƵƚ;ƚƌĂŶƐĂĐƚŝŽŶƐͬƐĞĐͿz^;ǁƌŝƚĞͲŚĞĂǀǇͿϭϱϬϬϬϬϭϬϬϴϬϲϬϰϬϮϬϬϭEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚ
yĞŽŶͲŶŽ,dͲϭǇĐƐďyĞŽŶͲŶŽ,dͲϮǇĐƐďyĞŽŶͲ,dͲϭǇĐƐďyĞŽŶͲ,dͲϮǇĐƐďǌϭϯͲŶŽ^DdͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϮǇĐƐďǌϭϯͲ^DdϮͲϭǇĐƐďǌϭϯͲ^DdϮͲϮǇĐƐďϯϬϬϬϬϬϮϬϬϬϬϬϭϬϬϬϬϬ
ϬϮϰϴyĞŽŶͲŶŽ,dͲϭǇĐƐďyĞŽŶͲŶŽ,dͲϮǇĐƐďyĞŽŶͲ,dͲϭǇĐƐďyĞŽŶͲ,dͲϮǇĐƐďǌϭϯͲŶŽ^DdͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϮǇĐƐďǌϭϯͲ^DdϮͲϭǇĐƐďǌϭϯͲ^DdϮͲϮǇĐƐďWhhƚŝůŝǌĂƚŝŽŶͲ z^;ƌĞĂĚͲŵŽƐƚůǇͿϰϴWhhƚŝůŝǌĂƚŝŽŶ;йͿdŚƌŽƵŐŚƉƵƚ;ƚƌĂŶƐĂĐƚŝŽŶƐͬƐĞĐͿz^;ƌĞĂĚͲŵŽƐƚůǇͿϰϬϬϬϬϬϭϮEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚϭϬϬϴϬϲϬϰϬϮϬϬϭϮϰϴEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚ
yĞŽŶͲŶŽ,dͲϭǇĐƐďyĞŽŶͲŶŽ,dͲϮǇĐƐďyĞŽŶͲ,dͲϭǇĐƐďyĞŽŶͲ,dͲϮǇĐƐďyĞŽŶͲŶŽ,dͲϭǇĐƐďyĞŽŶͲŶŽ,dͲϮǇĐƐďyĞŽŶͲ,dͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϮǇĐƐďǌϭϯͲ^DdϮͲϭǇĐƐďǌϭϯͲ^DdϮͲϮǇĐƐďyĞŽŶͲ,dͲϮǇĐƐďǌϭϯͲŶŽ^DdͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϮǇĐƐďǌϭϯͲ^DdϮͲϭǇĐƐďǌϭϯͲ^DdϮͲϮǇĐƐďWhhƚŝůŝǌĂƚŝŽŶͲ z^;ƌĞĂĚͲŽŶůǇͿϭϮϰϴ

WhhƚŝůŝǌĂƚŝŽŶ;йͿdŚƌŽƵŐŚƉƵƚ;ƚƌĂŶƐĂĐƚŝŽŶƐͬƐĞĐͿz^;ƌĞĂĚͲŽŶůǇͿϲϬϬϬϬϬϱϬϬϬϬϬϰϬϬϬϬϬϯϬϬϬϬϬϮϬϬϬϬϬϭϬϬϬϬϬϬϭϬϬϴϬϲϬϰϬϮϬϬϭϮϰyĞŽŶͲŶŽ,dͲϭǇĐƐďyĞŽŶͲŶŽ,dͲϮǇĐƐďyĞŽŶͲ,dͲϭǇĐƐďyĞŽŶͲ,dͲϮǇĐƐďyĞŽŶͲŶŽ,dͲϭǇĐƐďyĞŽŶͲŶŽ,dͲϮǇĐƐďyĞŽŶͲ,dͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϮǇĐƐďǌϭϯͲ^DdϮͲϭǇĐƐďǌϭϯͲ^DdϮͲϮǇĐƐďyĞŽŶͲ,dͲϮǇĐƐďǌϭϯͲŶŽ^DdͲϭǇĐƐďǌϭϯͲŶŽ^DdͲϮǇĐƐďǌϭϯͲ^DdϮͲϭǇĐƐďǌϭϯͲ^DdϮͲϮǇĐƐď

図2ϴEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚ

EƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚYCSB のスループット
図3

YCSB の CPU 利用率

4. 2 YCSB のプロセス数
次に使用する YCSB プロセスの数について考察すIntel Xeon プロセッサ，IBM z13 ともに YCSB A

る．図 4 は，YCSB プロセスを 2 つ使用した場合のでは，1YCSB プロセス使用の方が性能がよい．YCSB

性能が YCSB プロセスを使用した場合の性能の何倍

B と C の性能を見ると，IBM z13 の方が 2YCSB プになっているかを示すグラフである．値が 100%よりロセス使用の場合の性能が高くなっている．また，大きい場合 2YCSB プロセス使用の方が性能が良く，mongoDB デーモンに割り当てたコア数が多いときに100%より小さい場合 1YCSB プロセス使用の方が性2YCSB 使用の性能が高くなっている．

能が良い．
前節で述べたとおり，2YCSB プロセス使用によりMongoDB に割り当てたコアの CPU 利用率の使用率が向上するケースでは 2YCSB プロセス使用時の性4. 3 Intel Xeon プロセッサと IBM z13 のスループット比較
図 5 に Intel Xeon プロセッサと IBM z13 の性能能が，そうでない場合には 1YCSB プロセス使用時の比を示すグラフを示す．この比較 1YCSB プロセス使性能が高い．

用と 2YCSB プロセス使用の内性能の高い方を使用WĞĨŽƌŵĂŶĐĞZĂƚŝŽ;ǌϭϯͬyĞŽŶͿϭz^ƉƌŽĐĞƐƐǀ͘Ɛ͘Ϯz^ƉƌŽĐĞƐƐĞƐz^;ǁƌŝƚĞͲŚĞĂǀǇͿϮϱϬйϮϬϬйǌϭϯͬyĞŽŶϮz^ƉƌŽĐĞƐƐĞƐͬϭz^ƉƌŽĐĞƐƐϭϱϬйϭϬϬйϱϬйϭϱϬйϭϬϬйϱϬйϬйϭϮϰϴϬйEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚϭyĞŽŶͲŶŽ,dyĞŽŶͲ,dǌϭϯͲŶŽ^Dd

ϮϬϬй

ϴ

図5z^ͲŶŽ,dͬŶŽ^Ddz^Ͳ,dͬ^DdϮz^ͲŶŽ,dͬŶŽ^Ddz^Ͳ,dͬ^DdϮz^ͲŶŽ,dͬŶŽ^Ddz^Ͳ,dͬ^DdϮ

Intel Xeon プロセッサと IBM z13 の性能比ϭϱϬйϭϬϬйϱϬйĨĨĞĐƚƐŽĨ,ĂƌĚǁĂƌĞDƵůƚŝƚŚƌĞĂĚŝŶŐ

Ϭйϭ

Ϯ

ϰ

ϴEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚ
yĞŽŶͲŶŽ,dyĞŽŶͲ,dǌϭϯͲŶŽ^DdϮϬϬ͘Ϭй

,dͬŶŽ,d͕^DdϮͬŶŽ^DdϮz^ƉƌŽĐĞƐƐĞƐͬϭz^ƉƌŽĐĞƐƐϰǌϭϯͲ^DdϮϭz^ƉƌŽĐĞƐƐǀ͘Ɛ͘Ϯz^ƉƌŽĐĞƐƐĞƐz^;ƌĞĂĚͲŵŽƐƚůǇͿǌϭϯͲ^DdϮϭz^ƉƌŽĐĞƐƐǀ͘Ɛ͘Ϯz^ƉƌŽĐĞƐƐĞƐz^;ƌĞĂĚͲŽŶůǇͿϭϱϬ͘ϬйϭϬϬ͘ϬйϱϬ͘ϬйϬ͘ϬйϭϮϰϴEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚϮϬϬйϮz^ƉƌŽĐĞƐƐĞƐͬϭz^ƉƌŽĐĞƐƐ

ϮEƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚϭϱϬйz^ͲyĞŽŶz^Ͳǌϭϯz^ͲyĞŽŶϭϬϬйz^Ͳǌϭϯz^ͲyĞŽŶz^Ͳǌϭϯ

ϱϬй
Ϭй
ϭ

Ϯ

ϰ

ϴ

図6

ハードウェアマルチスレッディングの効果EƵŵďĞƌŽĨĐŽƌĞƐĂƐƐŝŐŶĞĚƚŽŵŽŶŐŽĚ
yĞŽŶͲŶŽ,dyĞŽŶͲ,dǌϭϯͲŶŽ^DdǌϭϯͲ^DdϮ

5 まとめと今後の課題
図4

2 つの YCSB プロセスを使用する効果Linux on z Systems の最新の IBM z13 プロセッサ
上での MongoDB3.0 の性能について，Yahoo! Cloudした．
今回の測定では IBM z13 は Intel Xeon プロセッサに対して約 1.7-2.2 倍の性能が得られた．

Serving Benchmark(以下 YCSB) を用いて 特に mongoDB デーモンの core スケーラビリティーに注目して評価した．また，同様の測定を Intel Xeon プロセッ
サ E5-2699 v3 上でも行い性能を比較した．

4. 4 ハードウェアマルチスレッディングの効果

性能測定の結果，Linux on z Systems では Intel

図 6 は，ハードウェアマルチスレッディングのあるXeon プロセッサの 1.7-2.2 倍のスループットが得ら場合とない場合の性能比を示すグラフである．

れること，ハードウェアマルチスレッディングによハードウェアマルチスレッディングにより，性能はり Xeon プロセッサの場合 22.6%，z Systems の場合1.0-1.4 倍の性能が得られる．平均効果は，Intel Xeon30.1%性能が向上することが分かった．また，YCSBプロセッサの場合 22.6%，IBM z13 の場合 30.1%とによる性能測定に際して，MongoDB により大きな負なり，IBM z13 の方がハードウェアマルチスレッディ

荷を与えるために YCSB プロセスを複数走らせるこングの効果が高い．とが有効であることが確認できた．

今回の測定では MongoDB 自身のコアスケーラビリティーに着目して，MongoDB と YCSB を同一マシン上で動作させたが，実際の運用環境では MongoDBと MongoDB にアクセスするクライアントが別なマシン上に置かれることも多いと考えられるので，この環境での性能測定は今後の課題としたい．

参 考 文 献[ 1 ] Allanbank:mongodb-async-driver, http://
www.allanbank.com/mongodb-async-driver/ performance/ycsb.html.
[ 2 ] COMPOSE: How We Scale MongoDB, https://www.compose.io/articles/how-we-scale-mongodb/.
[ 3 ] Cooper, B. F., Silberstein, A., Tam, E., Ramakrishnan, R., and Sears, R.: Benchmarking Cloud
Serving Systems with YCSB, Proceedings of the 1stACM Symposium on Cloud Computing, SoCC ’10,
New York, NY, USA, ACM, 2010, pp. 143–154.
[ 4 ] Hernandez, A., Jacopi, T., Larsen, S., Read, I.,and Sandy Sherrill, I.: IBM System z Total Cost ofOwnership: What It Means to You and Your Business.
[ 5 ] IBM: Building MongoDB 3.0 on RHEL 6and SLES 11, https://github.com/linux-on-ibmz/docs/wiki/Building-MongoDB-3.0-on-RHEL-6-andSLES-11.
[ 6 ] IBM: DB2, http://www-01.ibm.com/software/jp/info/db2/.
[ 7 ] IBM: Guide to porting Linux on x86 applications to Linux on POWER, http://www.ibm.com/developerworks/systems/library/es-inteltopwr/.
[ 8 ] IBM: IBM z13, http://www-06.ibm.com/systems/jp/z/hardware/z13/.

[ 9 ] IBM: Linux on IBM z Systems, http://www06.ibm.com/systems/jp/z/os/linux/.
[10] IBM: The Virtualization Cookbook for IBM z
Systems Volume 1: IBM z/VM 6.3, IBM Redbook.
[11] IBM: The Virtualization Cookbook for IBM z
Systems Volume 1: IBM z/VM 6.3, IBM Redbook.
[12] IDC: The Business Value of IBM zEnterprise
System Deployments, (2013).
[13] Intel: Intel Xeon Processor E5-2699 v3 (45MCache, 2.30 GHz), http://ark.intel.com/ja/products/81061/Intel-Xeon-Processor-E5-2699-v3-45M-Cache2 30-GHz.
[14] MongoDB: Disable Transparent Huge Pages(THP), http://docs.mongodb.org/master/tutorial/transparent-huge-pages/.
[15] MongoDB: MetLife Leap frogs Insurance Industry with MongoDB-Powered Big Data Application, https://www.mongodb.com/press/metlifeleapfrogs-insurance-industry-mongodb-powered-bigdata-application.
[16] MongoDB: MongoDB, https://www.mongodb.org/.
[17] MongoDB: MongoDB3.0, https://www.mongodb.com/
mongodb-3.0.
[18] MongoDB: Performance Testing MongoDB 3.0
Part 1: Throughput Improvements Measured withYCSB, https://www.mongodb.com/blog/post/performancetesting-mongodb-30-part-1-throughput-improvementsmeasured-ycsb.
[19] Oracle: Oracle Database 12c, http://www.oracle.com/technetwork/jp/database/enterprise-edition/overview/index.html.
[20] Project, M. D.: Sharding and MongoDB, Release 3.0.5, http://docs.mongodb.org/master/MongoDBsharding-guide.pdf.
[21] Yahoo: YCSB Homepage, https://github.com/
brianfrankcooper/YCSB/wiki.