このトピックでは、仕様の異なる複数の ApsaraDB for MongoDB レプリカセットインスタンスに対して、最大接続数のストレス テストを実行する方法について説明します。このテストは、Elastic Compute Service (ECS) インスタンスから ApsaraDB for MongoDB インスタンスにアクセスして実施します。
テスト環境
ECS インスタンスと ApsaraDB for MongoDB インスタンスを作成します。詳細については、「レプリカセットインスタンスの作成」および「ECS インスタンスの作成」をご参照ください。
次の表に、テストで使用した ECS インスタンスと ApsaraDB for MongoDB インスタンスの設定を示します。
|
設定項目 |
ECS インスタンス |
クラウドディスクを使用する ApsaraDB for MongoDB インスタンス |
ローカルディスクを使用する ApsaraDB for MongoDB インスタンス |
|
リージョンとゾーン |
北京ゾーン H |
北京ゾーン H |
北京ゾーン H |
|
ネットワークタイプ |
Virtual Private Cloud (VPC) |
VPC |
VPC |
|
インスタンスカテゴリー |
c6e、拡張パフォーマンスを備えたコンピューティング最適化インスタンスカテゴリー |
汎用および専用 |
汎用および専用 |
|
インスタンスタイプ |
ecs.c6e.2xlarge |
3つの利用可能なインスタンスタイプがあります。詳細については、「テスト結果」をご参照ください。 |
2つの利用可能なインスタンスタイプがあります。詳細については、「テスト結果」をご参照ください。 |
|
ストレージタイプ |
Enterprise SSD (ESSD) AutoPL ディスク |
ESSD |
ローカル SSD |
|
イメージまたはエンジンバージョン |
Alibaba Cloud Linux 3.2104 LTS 64ビット |
4.19.91-26.al7.x86_64 |
3.10.0-327.ali2017.alios7.x86_64 |
|
カーネルバージョン |
N/A |
|
|
-
テストで使用した ApsaraDB for MongoDB インスタンスは、プライマリーノード、セカンダリノード、隠しノードで構成される3ノードアーキテクチャを採用しています。
-
テストで使用した ECS インスタンスと ApsaraDB for MongoDB インスタンスは、同じリージョンの同じゾーンにデプロイされており、平均ラウンドトリップタイム (RTT) は 0.103 ms です。
テストツール
-
このテストでは、オープンソースの Yahoo Cloud Serving Benchmark (YCSB) 0.17.0 ツールを使用します。
説明YCSB は、複数タイプのデータベースのパフォーマンスをベンチマークするために使用できる Java ツールです。YCSB のインストールと使用方法の詳細については、「YCSB」をご参照ください。
-
このテストでは、カスタム接続ストレステストプログラムを使用します。詳細については、「96,000接続のストレステストに関する追加情報」をご参照ください。
テスト方法
- ECSインスタンスのプライマリプライベートIPアドレスをApsaraDB for MongoDBインスタンスのホワイトリストに追加します。 詳細については、「ApsaraDB For MongoDBインスタンスのIPアドレスホワイトリストの変更」をご参照ください。 説明 ECSコンソールにログインし、[インスタンスの詳細] ページの [ネットワーク情報] セクションでECSインスタンスの [プライマリプライベートIPアドレス] を表示します。
- ECSインスタンスに接続します。 詳細については、「ECSコンソール (エクスプレスバージョン) を使用したECSインスタンスの作成と管理」をご参照ください。
-
YCSB ツールを使用してテストデータをロードします。
./bin/ycsb.sh load mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=10000000 -p mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin" -p table=test -threads 8次の設定を変更します:
-
recordcount=10000000: ApsaraDB for MongoDB インスタンスにロードするデータの総量です。 -
mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin": ApsaraDB for MongoDB インスタンスの接続文字列です。このテストでは、データベースアカウントは test、データベースは admin です。説明ApsaraDB for MongoDB コンソール にログインし、Database Connection ページで、[内部接続 - VPC] セクションの接続文字列を表示します。
-
threads 8:テストで使用するクライアント上の同時実行スレッド数です。
-
-
次のコマンドを実行して、パフォーマンスストレステストを実行します:
./bin/ycsb.sh run mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=10000000 -p operationcount=5000000 -p readproportion=50 -p updateproportion=50 -p requestdistribution=zipfian -p mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin?maxPoolSize=8000" -p table=test -threads 8000次の設定を変更します:
-
recordcount=10000000: ApsaraDB for MongoDB インスタンスにロードするデータの総量です。 -
operationcount=5000000:読み取りおよび書き込み操作の総数です。 -
insertproportion=0:挿入操作の比率です。 -
readproportion=50:読み取り操作の比率です。 -
updateproportion=50:更新操作の比率です。 -
mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin": ApsaraDB for MongoDB インスタンスの接続文字列です。このテストでは、データベースアカウントは test、データベースは admin です。説明-
ApsaraDB for MongoDB コンソール にログインし、Database Connection ページの [内部接続 - VPC] セクションで接続文字列を表示できます。
-
maxPoolSizeパラメーターを指定する必要があります。そうしないと、デフォルト値の 100 が使用され、MongoWaitQueueFullExceptionエラーが発生して、テストが目標の接続制限に達しなくなることがあります。
-
-
-
テストで使用した ApsaraDB for MongoDB インスタンスの監視情報を表示します。詳細については、「ノード監視 (旧基本監視)」をご参照ください。
[ノード監視] タブで、テストの時間範囲を選択して、インスタンスの [CPU使用率]、[メモリ使用率]、[QPS操作数]、[接続数]、[接続数使用率] を表示します。
96,000接続のストレステストに関する追加情報
YCSB は Java 環境に依存しており、Java 仮想マシン (JVM) には最大ヒープサイズの制限があります。高い同時実行性 (スレッド > 20,000) でテストを実行すると、次の例に示すように "Cannot allocate memory" エラーが発生し、テストが停止します。
OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
OpenJDK 64-Bit Server VM warning: DBWrapper: report latency for each error is false and specific error codes to track for latency are: []INFO: os rrno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 12288 bytes for committing reserved memory.
OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
# An error report file with more information is saved as:
# /root/ycsb-0.17.0/hs_err_pid101727.log
DBWrapper: report latency for each error is false and specific error codes to track for latency are: []
OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
DBWrapper: report latency for each error is false and specific error codes to track for latency are: []OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
OpenJDK 64-Bit Server VM warning: DBWrapper: report latency for each error is false and specific error codes to track for latency are: []INFO: os rrno=12)
[thread 140023352145472 also had an error]
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f59ba0a2000, 12288, 0) failed; error='Cannot allocate memory' (errno=12)
JAVA_OPTS パラメーターの値を増やしても、エラーは引き続き発生します。この問題を解決するには、カスタム接続ストレステストプログラムを使用します。このストレステストプログラムは、複数のスレッドを周期的に生成します。各スレッドは MongoClient を生成します。MongoClient がクエリを実行した後、MongoClient は接続を解放せずに一定期間維持します。
ストレステストクライアントを実行する単一のマシンには、ポート数の制限があります。そのため、32コア、128 GB のメモリ仕様では、接続ストレステスト (最大 96,000 接続) の要件を満たすことはできません。この場合、複数のマシンで同じストレステストプログラムを実行する必要があります。
次の Bash コマンドを実行して、マシンの現在のポート範囲を確認します:
sysctl net.ipv4.ip_local_port_range
結果の例:
net.ipv4.ip_local_port_range = 40000 65535
次のコマンドを実行してマシンのポート範囲を拡張し、接続ストレステストを実行します:
sudo sysctl -w net.ipv4.ip_local_port_range="10240 65535"
テスト結果
ESSD を使用するインスタンス
4コア、8 GB メモリの専用インスタンス
最大接続数: 8,000
|
QPS |
接続数 |
接続使用率 |
CPU 使用率 |
メモリ使用量 |
|
|
|
|
|
|
ノード監視ビューのサンプリング粒度が 分レベル であるため、グラフには 8,000 接続のピークが表示されません。より詳細な粒度の監視を使用するか、serverStatus 出力の connections サブドキュメントを確認することで、このピークを確認できます。
mgset-xxx:PRIMARY> db.serverStatus().connections
{
"current" : 7854,
"available" : 146,
"totalCreated" : 7857,
"internal_current" : 27,
"internal_available" : 7973,
"internal_totalCreated" : 7029,
"active" : 9,
"exhaustIsMaster" : 4,
"exhaustHello" : 2,
"awaitingTopologyChanges" : 6
}
32コア、128 GB メモリの専用インスタンス
最大接続数: 96,000
|
QPS |
接続数 |
接続使用率 |
CPU 使用率 |
メモリ使用量 |
|
|
|
|
|
|
最大接続数 96,000 のテストで使用したツールは、8,000 および 16,000 の場合とは異なります。そのため、前述の QPS、CPU 使用率、メモリ使用量に関する監視スクリーンショットには差異があります。
8コア、32 GB メモリの汎用インスタンス
最大接続数: 16,000
|
QPS |
接続数 |
接続使用率 |
CPU 使用率 |
メモリ使用量 |
|
|
|
|
|
|
ローカルディスクを使用するインスタンス
16コア、64 GB メモリの汎用インスタンス
最大接続数: 32,000
|
QPS |
接続数 |
接続使用率 |
CPU 使用率 |
メモリ使用量 |
|
|
|
|
|
|
[ノード監視] タブで 分 レベルの収集粒度を指定した場合、16コア、64 GB メモリの汎用インスタンスでは、CPU 使用率が 100% になったことによる収集コマンドのタイムアウトが原因で、いくつかの時点で接続数が監視されません。この場合、分単位のグラフで谷が発生しますが、その時点での実際の接続数は 32,000 のままです。
2コア、16 GB メモリの専用インスタンス
最大接続数: 8,000
|
QPS |
接続数 |
接続使用率 |
CPU 使用率 |
メモリ使用量 |
|
|
|
|
|
|
まとめ
-
ApsaraDB for MongoDB レプリカセットインスタンスは、仕様やストレージタイプが異なっていても、それぞれの仕様に対応する最大接続数に達します。
-
最大接続数に達すると、ApsaraDB for MongoDB は後続の接続を拒否します。接続の確立に失敗するため、リクエストのレイテンシーが高くなるか、アプリケーションでリクエストが滞ります。
-
同時接続数が多いほど、CPU やメモリなどのリソースをより多く消費します。ビジネス要件に基づいて、インスタンスへの接続数を調整することを推奨します。
























