ベンチマーク

• 1: ストレージのメモリー使用量ベンチマーク
• 2: 監視のメモリー使用量ベンチマーク
• 3: etcd v3のベンチマーク
• 4: etcd v2.2.0-rc-memoryのベンチマーク
• 5: etcd v2.2.0-rcのベンチマーク
• 6: etcd v2.2.0のベンチマーク
• 7: etcd v2.1.0のベンチマーク

1 - ストレージのメモリー使用量ベンチマーク

etcdのストレージでは、2つの構成要素が物理メモリーを消費します。etcdプロセスは、キーの検索を高速化するためにインメモリーインデックスを割り当てます。また、オペレーティングシステムが管理するプロセスのページキャッシュには、最近ディスクから読み込んだデータが保存され、すばやく再利用できます。

インメモリーインデックスは、ディスク上のデータ（値）へのポインターとともに、すべてのキーをB木 のデータ構造で保持します。B木の各キーには、値の異なるバージョンを指す複数のポインターが含まれる場合があります。そのため、インメモリーインデックスの理論上のメモリー消費量は、次の式で近似できます。

N * (c1 + avg_key_size) + N * (avg_versions_of_key) * (c2 + size_of_pointer)

ここで、c1はキーのメタデータのオーバーヘッド、c2はバージョンのメタデータのオーバーヘッドです。

次の図は、インメモリーインデックスのB木の詳細な構造を示します。

                                In mem index

                               +------------+
                               | key || ... |
  +--------------+             |     ||     |
  |              |             +------------+
  |              |             | v1  || ... |
  |   disk    <----------------|     ||     | Tree Node
  |              |             +------------+
  |              |             | v2  || ... |
  |           <----------------+     ||     |
  |              |             +------------+
  +--------------+       +-----+    |   |   |
                         |     |    |   |   |
                         |     +------------+
                         |
                         |
                         ^
                      ------+
                      | ... |
                      |     |
                      +-----+
                      | ... | Tree Node
                      |     |
                      +-----+
                      | ... |
                      |     |
                      ------+

ページキャッシュのメモリー はオペレーティングシステムが管理するため、このドキュメントでは詳しく扱いません。

テスト環境

etcdのバージョン

• git head https://github.com/etcd-io/etcd/commit/776e9fb7be7eee5e6b58ab977c8887b4fe4d48db

GCEのn1-standard-2マシンタイプ

• メモリー：7.5 GB
• CPU：2基

インメモリーインデックスのメモリー使用量

このテストでは、インメモリーインデックスのメモリー使用量のみを測定します。目的は、前述のc1とc2を求め、ストレージのメモリー消費量の厳密な限界を把握することです。

Goのruntime.ReadMemStatsを使い、インデックス作成前後の総割り当てバイト数の差から、メモリー消費量を算出します。インメモリーインデックス自体の使用量を完全に反映するわけではありませんが、おおよその消費傾向を把握できます。

結果から、c1=120bytes、c2=30bytesと計算できます。式の未知数はこの2つだけなので、c1とc2の算出には2組のデータだけが必要です。c1=120bytesとc2=30bytesは、計算した4組のc1とc2の平均値です。小さなキー・バリューペアに対しては、キーのメタデータのオーバーヘッドは依然として無視できない大きさ（50%）です。しかし、少なくとも1000%のオーバーヘッドがあった旧ストアからは大幅に改善しています。

全体のメモリー使用量

全体のメモリー使用量は、ストレージを含めたetcdのRSS消費量を測定したものです。値はディスクに保存し、頻繁に使う値だけをOSのページキャッシュで管理するメモリーに保持するため、値のサイズがetcd全体のメモリー使用量に与える影響はごく小さいはずです。

結果から、値のサイズはメモリー消費量に大きな影響を与えないことがわかります。OSのページキャッシュに保持されるデータが増えるため、わずかな増加は見られます。

2 - 監視のメモリー使用量ベンチマーク

etcdの主な目標の1つは、非常に多くのウォッチャーが膨大な数の監視を行えるようにすることです。etcdは、O(10k)のクライアント、O(100K)の監視ストリーム（クライアントあたりO(10)ストリーム）、合計O(10M)の監視（ストリームあたりO(100)の監視）への対応を目指しています。個々の監視が消費するメモリーは、etcd全体の使用量の中で最も大きな割合を占めるため、現在および今後の最適化の重点となっています。

etcdの監視では、関連する3つの構成要素、すなわち各grpc.Conn、各監視ストリーム、各監視インスタンスが物理メモリーを消費します。grpc.Connは実際のTCP接続とその他のgRPC接続状態を保持します。各grpc.ConnはO(10kb)のメモリーを消費し、複数の監視ストリームが接続されることがあります。

各監視ストリームは独立したHTTP2接続で、さらにO(10kb)のメモリーを消費します。 複数の監視で1つの監視ストリームを共有できます。

監視インスタンスは、キー・バリューストアの変更を追跡する実際の構造体です。各監視のメモリー消費量はO(1kb)未満に収まるはずです。

                                          +-------+
                                          | watch |
                              +---------> | foo   |
                              |           +-------+
                       +------+-----+
                       |   stream   |
      +--------------> |            |
      |                +------+-----+     +-------+
      |                       |           | watch |
      |                       +---------> | bar   |
+-----+------+                            +-------+
|            |         +------------+
|   conn     +-------> |   stream   |
|            |         |            |
+-----+------+         +------------+
      |
      |
      |
      |                +------------+
      +--------------> |   stream   |
                       |            |
                       +------------+

監視の理論上のメモリー消費量は、次の式で近似できます。 memory = c1 * number_of_conn + c2 * avg_number_of_stream_per_conn + c3 * avg_number_of_watch_stream

テスト環境

etcdのバージョン

• git head https://github.com/etcd-io/etcd/commit/185097ffaa627b909007e772c175e8fefac17af3

GCEのn1-standard-2マシンタイプ

• メモリー：7.5 GB
• CPU：2基

全体のメモリー使用量

全体のメモリー使用量は、クライアントのウォッチャーを接続したetcdが消費するRSS を測定したものです。結果には最大10%程度のばらつきがありますが、おおよそのメモリー使用量と割り当ての傾向を把握するという目的には意味があります。

ベンチマーク結果から、おおよそc1 = 17kb、c2 = 18kb、c3 = 350bytesと計算できます。つまり、クライアント接続を1つ追加すると17kb、ストリームを1つ追加すると18kbのメモリーを消費しますが、監視を1つ追加したときの消費量はわずか350bytesです。通常、1台のetcdサーバーで、数GBのメモリーを使って数百万の監視を維持できます。

3 - etcd v3のベンチマーク

物理マシン

GCE n1-highcpu-2マシンタイプ

• /var/lib/etcdにマウントした専用ローカルSSD × 1
• OS用の専用低速ディスク × 1
• メモリー1.8 GB
• CPU × 2
• etcdバージョン2.2.0

etcdクラスター

v3デモモードで稼働するetcdメンバー1つ

テスト

etcd v3ベンチマークツール を使用します。

性能

単一キーの読み取り

空のサーバーハンドラーを使用した場合と、ほぼ同じ性能です。

書き込み後の単一キーの読み取り

空のサーバーハンドラーを使用した場合、1回のputによって性能は変わりません。したがって、性能低下の原因はストレージパッケージにあると考えられます。

4 - etcd v2.2.0-rc-memoryのベンチマーク

物理マシン

GCE n1-standard-2マシンタイプ

• /var/lib/etcdにマウントした専用ローカルSSD × 1
• OS用の専用低速ディスク × 1
• メモリー7.5 GB
• CPU × 2

etcd

etcd Version: 2.2.0-rc.0+git
Git SHA: 103cb5c
Go Version: go1.5
Go OS/Arch: linux/amd64

テスト

各メンバーが2コアを使用する3メンバーのetcdクラスターを起動します。

キー名の長さは常に64バイトとします。これは、キーの平均的なバイト長として妥当な長さです。

最大メモリー使用量

• フォロワーの1つが停止し、リーダーがスナップショットを送信し続けると、etcdのメモリー使用量が最大になる場合があります。
• max RSSは、3回の実行で記録された最大メモリー使用量です。

データサイズのしきい値

• etcdのデータサイズがしきい値に達すると、リーダー選出が起こりやすくなり、提案の一部が破棄される場合があります。
• ほとんどの場合、しきい値に達していなければetcdクラスターは問題なく動作するはずです。リソース不足によって正常に動作しない場合は、データサイズを減らしてください。

5 - etcd v2.2.0-rcのベンチマーク

物理マシン

GCEのn1-highcpu-2マシンタイプ

• /var/lib/etcdにマウントした専用ローカルSSD：1台
• OS用の専用低速ディスク：1台
• メモリー：1.8 GB
• CPU：2基

etcdクラスター

etcd 2.2.0-rcメンバー3つを、それぞれ別のマシンで実行します。

バージョンの詳細：

etcd Version: 2.2.0-alpha.1+git
Git SHA: 59a5a7e
Go Version: go1.4.2
Go OS/Arch: linux/amd64

比較の基準となる性能を測るため、alpha段階のetcd 2.1.0メンバー3つでもクラスターを構成します。etcdのコミットはc7146bd5 で、etcd 2.1のベンチマーク で使用したものと同じです。

テスト

別のマシンを起動し、hey HTTPベンチマークツール を使って各etcdメンバーにリクエストを送信します。詳しい手順はベンチマーク開発ガイド を参照してください。

性能

単一キーの読み取り

単一キーの書き込み

性能変化の説明

• ほとんどのシナリオで、読み取りQPSが5～8%低下しています。これは、etcdがストア操作ごとにストアのメトリクスを記録するためです。メトリクスは監視やデバッグに重要なため、この低下は許容できると考えています。

• リーダーに対する書き込みQPSが20～30%増加しています。raftのメインループとエントリー適用ループを分離し、互いの処理をブロックしないようにしたためです。

• 全サーバーに対する書き込みQPSが30～80%増加しています。フォロワーが最新のコミットインデックスをより早く受信し、提案をより速くコミットできるようになったためです。

6 - etcd v2.2.0のベンチマーク

物理マシン

GCEのn1-highcpu-2マシンタイプ

• etcdのデータディレクトリとしてマウントした専用ローカルSSD：1台
• OS用の専用低速ディスク：1台
• メモリー：1.8 GB
• CPU：2基

etcdクラスター

etcd 2.2.0メンバー3つを、それぞれ別のマシンで実行します。

バージョンの詳細：

etcd Version: 2.2.0
Git SHA: e4561dd
Go Version: go1.5
Go OS/Arch: linux/amd64

テスト

etcdクラスターの外部に別のマシンを起動し、接続再利用のパッチを適用したhey HTTPベンチマークツール を実行して、各etcdクラスターメンバーにリクエストを送信します。パッチと測定手順の再現方法は、ベンチマークの手順 を参照してください。

性能は100回のベンチマーク結果から算出します。

性能

単一キーの読み取り性能

単一キーの書き込み性能

性能の変化

• etcdがAPI呼び出しごとにメトリクスを記録するようになったため、ほとんどのシナリオで読み取りQPSがわずかに低下しているようです。得られる監視・デバッグ情報の広がりを考慮し、この小さな性能への影響は妥当なものと判断しました。

• クラスターのリーダーに対する書き込みQPSは、わずかに増加しているようです。これは、etcdのraft処理でメインループとエントリー適用ループを分離し、両者の間で発生していたいくつかのブロックを解消したためです。

• 全メンバーに対する書き込みQPSは、大幅に増加しているようです。フォロワーが最新のコミットインデックスをより早く受信し、提案をより速くコミットできるようになったためです。

7 - etcd v2.1.0のベンチマーク

物理マシン

GCEのn1-highcpu-2マシンタイプ

• /var/lib/etcdにマウントした専用ローカルSSD：1台
• OS用の専用低速ディスク：1台
• メモリー：1.8 GB
• CPU：2基
• etcdバージョン：2.1.0 alpha

etcdクラスター

etcdメンバー3つを、それぞれ別のマシンで実行します。

テスト

別のマシンを起動し、hey HTTPベンチマークツール を使って各etcdメンバーにリクエストを送信します。詳しい手順はベンチマーク開発ガイド を参照してください。

性能

単一キーの読み取り

単一キーの書き込み