ArcSOC 構成への影響に関するテスト結果

2 つ目のテストでは、データベース リソースの評価に加え、十分なデータベース リソースがあることを前提として、システムとそのワークフローに設計負荷の 8 倍の負荷に対応できる最適な ArcSOC 構成を特定することに重点を置きました。

テストの方法と結果

異なる ArcSOC と vCPU の比率で 3 つのテストが実施されました:

• 2:1, or two ArcSOCs per vCPU on the ArcGIS Server instances
• 3:1, or three ArcSOCs per vCPU on the ArcGIS Server instances
• 4:1, or four ArcSOCs per vCPU on the ArcGIS Server instances

また、このテストは 1:1 の ArcSOC と vCPU の比率でも実施しました。「データベース リソースの影響評価」に記載されている、大規模なデータベース インスタンスでのテストをご確認ください。

ArcSOC インスタンスと vCPU の比率を体系的に変化させながら複数の負荷テストを実施し、パフォーマンスやユーザー エクスペリエンスへの影響を観察および測定しました。 有意義な結果を得られるよう、システムの他のすべての要素は一定に保ちました。

ArcSOC の使用や可用性、サービス待ち時間、システム リソースの使用率、 error 率などのパフォーマンス指標を監視し、各構成を評価しました。

テストは元のシステム テスト調査の設計負荷の 8 倍の負荷で実施され、システムに影響を与えるのに十分な負荷を確保するために、ArcGIS Enterprise サーバーのリソースは半分に削減しました。 JMeter を使用してユーザーのワークフローをシミュレートし、さまざまな負荷のもとでシステム パフォーマンスを測定しました。

ArcGIS は多層システムなので、テストは、クライアント層、サービス層、データ ストレージ層、および基盤となるインフラストラクチャー自体にわたって行われました。 このテスト調査では、JMeter を使用してユーザーのワークフローをシミュレートし、さまざまな負荷のもとでシステム パフォーマンスを測定しました。

2:1 ArcSOCs : vCPU ratio

今回の実行では、ArcGIS Server インスタンスの vCPU あたり 2 つの ArcSOC を構成しました。 この場合、8 つの vCPU に対して 16 個の ArcSOC が稼働しています。 前のグラフと同様に、CPU 使用率はオレンジ、ディスク使用率はゴールド、メモリー使用率は紫で示しています。

以下のグラフでは、すべてのコンピューターの CPU 使用率はおおむね 60% 未満です。 しかし、UN GIS Server のメモリー使用率は 80% を超えてピークに達しています。 これは、比率が 1:1 の場合に比べて、追加で稼働している ArcSOC があるためです。 UN GIS Server 上のサービスにより、バージョン管理されたデータベース編集が可能です。 システムは順調に動作しているように見えますが、問題を回避するためには、メモリーを注意深く監視する必要があります。 同時リクエスト数のグラフでは、同時表示リクエスト (赤) が着実に開閉しており、平均は 35 回であることがわかります。

以下のグラフはホスティング サーバーにおける ArcSOC の使用状況を示します。16 個の ArcSOC が稼働しており (青いラインは緑のラインに重なっています)、最大使用数 (ビジー状態) は 14 個です。 UN GIS Server (図には表示されていません) では、最大で 7 個の ArcSOC がビジー状態だったので、追加のサービス インスタンスは活用しませんでした。そのため、16 個の ArcSOC が稼働していたものの、ほとんどアイドル状態となっていました。 このサーバーのメモリー使用率は 80% を超えていたため、UN GIS Server のサービス インスタンスを最小、最大ともに 8 個に減らすことでメモリー負荷を軽減し、これらのワークフローや負荷に対してシステムを最適化できる可能性があります。 ワークフローや負荷の変化は、バランスに影響を与える可能性があります。

3:1 ArcSOCs to vCPU ratio

今回の実行では、vCPU あたり 3 つの ArcSOC を構成しました。 この場合、8 つの vCPU に対して 24 個の ArcSOC が稼働しています。 ここでも、すべてのコンピューターで CPU 使用率 (オレンジ) はおおむね 60% 未満になっています。 しかし残念ながら、UN GIS Server のメモリー使用率 (紫) は最大に達しており、クリーンアップ処理の一環として 95% まで低下することがあります。 同時表示リクエスト (赤) は着実に開閉しており、平均は 36 回であることがわかります。 このシステムは負荷に対応できているように見えますが、メモリー不足のため、この状態を維持することはできません。

さらに、以下の ArcSOC グラフを見ると、比率が 3:1 の場合、UN GIS Server では 24 個の ArcSOC が稼働していることがわかります (青いラインは緑のラインに重なっています)。 しかし、ビジー状態の ArcSOC は 18 個に留まり、使用していないときでもメモリーを消費しています。 これは不適切な構成の一例です。 このワークロードでは、利用可能なすべての ArcSOC が必要というわけではありません。 不要な 6 個 (稼働している 24 個からビジー状態の 18 個を差し引いた数) は、リソース (メモリー) を無駄に消費しています。 UN GIS Server のメモリーを増やせばこの状況は改善されるかもしれませんが、その代わりに問題が CPU やデータベースに移ることも考えられます。 システムをサポートする適切な構成や設計を選択するには、テストと観察が必要です。

4:1 ArcSOCs to vCPU ratio

今回の実行では、vCPU あたり 4 つの ArcSOC を構成しました。 この場合、UN GIS Server で 8 つの vCPU に対して 32 個の ArcSOC が稼働しています。 UN GIS Server では CPU 使用率 (オレンジ) は増加しており、80% を超えるピークが 2 回見られます。 しかし最大の問題は、そのインスタンスのメモリー使用率 (青) がほぼ 100% に達している点です。クリーンアップ処理を行っても追い付かない状況です。

下に示した同時表示リクエスト (赤) を見ると、3:1 の比率と同様に平均 36 回で、開閉が着実に行われていることがわかります。 これは、追加の ArcSOC がシステムのパフォーマンスやエンド ユーザー エクスペリエンスに何のメリットももたらしていないことを示しています。 むしろ、それらは単に GIS サーバー リソースを消費しているだけに過ぎません。

これは、ビジー状態の ArcSOC が最大 16 個しかないことを示す、以下の ArcSOC チャートでも裏付けられています。 ここで明らかなのは、サービス インスタンスを追加しても不要なサーバー リソースを消費するだけで、パフォーマンスやユーザー エクスペリエンスの向上につながらないことです。 UN GIS Server の CPU とメモリーを増やすことで結果が改善される可能性はありますが、その代わりに問題がデータベース サーバーの CPU に移ることも考えられます。 テストと観察が重要です。