ArcGIS for Server 10.2.1でのマップキャッシュ作成パフォーマンスの最適化

私はArcGIS for Serverに比較的慣れていないので、自分がやっていることが適切でない場合に備えて、誰かが私を正しい方向に向けてくれることを願っています。

ArcGIS for Server 10.2.1の2つのボックスが両方とも同じサイトにあります。どちらのボックスにも、4つのプロセッサと16GBのRAMが搭載されています。どちらのボックスもWindows Server 2008で実行されます。

このサイトは、少数のユーザー（5未満）にいくつかのベースマップサービスを提供するためと、将来のサービスのためにキャッシュタイルを生成するために使用されます。

私は現在、マッピングサービス（〜50GB）のキャッシュタイルを生成しています。2つのボックスのCPU使用率が非常に高くなることを期待していました。ただし、各ボックスの15％から30％の間に収まる傾向があります。

キャッシュツールの最大インスタンス数は6に設定されています。

マシンあたりのインスタンスの最大数は3に設定されています。

CPUの使用率が高くなると想定しているのは間違っていますか？

正しい数字を入れていませんか？

それとも私のセットアップはベストプラクティスではありませんか？つまり、マップを提供するためだけに1つのサイトを使用し、キャッシュのためだけに別のサイトを使用する必要がありますか？

こことここに記載されているガイドラインに従っていると思います。しかし、キャッシュの実行速度が予想よりも遅いことは確かです。19時間後、すべてのタイルの1.17％しかキャッシュされませんでした。

ベストプラクティスの提案は大歓迎です。

更新：21時間後、両方のマシンのCPU使用率はゼロになりました：

マシン1：

マシン2：

サーバーのキャッシュステータス「進行中」バーはまだ移動していますが、キャッシュ％は過去2時間増加していません。

キャッシュを作成するためのベストプラクティスに従うかなりの仕事をしたようです。サーバーには十分な処理能力がありますが、データベースから地図データを取得することが問題になる場合があります。このサイトの簡単な概要を以下に示します。

1- 公開する前にマップを分析してください！

これは明白かもしれませんが、分析の結果を確認せずにサーバーに公開するには速すぎることがよくありました。に移動File->Analyze Mapして簡単なチェックを行い、マップに問題がないかどうかを確認してください。マップのレンダリングが高速であるほど、キャッシュが高速になります。

2- データをローカルに保つ

単一のマシン配置がある場合は、マップデータをサーバーのローカルのFGDBに保持します。複数のマシンがある場合は、各マシンにデータのコピーを持たせ、キャッシュを設定するときに[サーバーでタイルを生成するときにローカルキャッシュディレクトリを使用する]オプションを使用します。

上記のリンクには、失敗を処理するためのいくつかの便利なヒントと、キャッシュエラーを解析してポリゴンフットプリントに解析する便利なスクリプトがあり、簡単に戻って失敗した領域を再キャッシュできるようになっています。

この質問は時々出てきます。多分私達はいくつかのより多くの答えを得て、これをWikiに変えることができます。:)

もう1つの方法は、キャッシュコントローラーとキャッシュツールを別のクラスターに設定することです。これにより、キャッシングプロセスが通常のプロセスプールから分離されます。これにより、通常のarcgisserver関数からキャッシングを分離して、パフォーマンスが向上することがわかりました。私は通常、この新しいクラスターキャッシングを呼び出します。次に、新しいマシンをインストールに追加するとき、それらをデフォルトではなくキャッシングクラスターに追加するだけで、処理能力が向上します。さらに、使用率が低い場合は、70〜80％程度の使用率になるまでリソースを追加し続け、ファイルを前後にコピーしてリソースの競合を減らすために、ある程度の能力を残しておきます。

ESRIドキュメント（http://server.arcgis.com/en/server/latest/publish-services/linux/accelerating-map-cache-creation.htm）に基づいて、キャッシュに使用するインスタンス数のベストプラクティスここで、nはサーバーで実行されているコアの数です。ドキュメントによれば、サーバーにはそれぞれ4つのプロセッサーがあり、各X5690プロセッサーには6つのコアがあります。

http://ark.intel.com/products/52576/Intel-Xeon-Processor-X5690-12M-Cache-3_46-GHz-6_40-GTs-Intel-QPI

これに基づいて、理論的にはサーバーごとに25のキャッシュインスタンスを処理できるはずです。ESRIドキュメントが10.3用であることはわかったのですが、これは最近のいくつかのバージョンで推奨されている方法です。

私は同様のサーバーセットアップを使用しており、25のインスタンスに近づく前にCPUが100％に到達するが、10〜15を非常に快適に使用できることを伝えることができます。

したがって、ディスクIOまたはデータベースがボトルネックではないことをテストした場合、インスタンスの数を10に増やすことをお勧めします。これによりCPU使用率が増加しない場合は、制限要因ではなかったことを意味します。増加するがそれでも妥当な場合は、さらに増加し​​てみることができます。

とにかく、ストーリーのモラルは、インスタンスをクランキングすることをためらわないでください。かつて、コアが2つとインスタンスが3つしかない、かなりパワー不足のサーバーにも取り組んだことがありました。ただし、インスタンスを5に増やしたところ、CPU使用率は妥当でした。ベストプラクティスは単なる出発点です。