1

何十万ものジオメトリ タイプのパーセルを含む SQL Server テーブルがあります。セル設定ごとの密度とオブジェクトのさまざまな組み合わせを試して、それらにインデックスを作成しました。これまでのところ、LOW、LOW、MEDIUM、MEDIUM、およびセルごとに 16 個のオブジェクトを設定しており、テーブル内のエンティティの範囲に従って境界ボックスを設定する SP を作成しました。

インデックスなしでほぼ​​数分かかっていたクエリから数秒未満まで、信じられないほどのパフォーマンスの向上があります。ズームが近づくと高速になり、表示されるオブジェクトが少なくなります。

それでも、クエリ自体が高速であっても、フィーチャのクエリを実行すると、CPU 使用率は 100% になります。これが本番環境で飛ばないのではないかと心配しています。

このプロジェクトでは MapGuide Open Source 2.1 を使用していますが、CPU 負荷が SQL Server によって引き起こされていることは確かです。

インデックスが適切に設定されているかどうか疑問に思います。それらを適切に設定する方法に関する明確なドキュメントは見つかりませんでした。私が読んだすべての記事には、基本的に「場合による...」と書かれていますが、具体的なことは何もありません。本や記事など、私に何かお勧めはありますか?

ありがとうございました。

4

3 に答える 3

0

この種の質問があるときはいつでも、SQL プロファイラーを取り出して、どのクエリが実行されているかを確認してください。次に、それらをクエリ プランナーで実行して、ボトルネックがどこにあるかを確認します。

また、(私のように) 怠惰で、チューニング テンプレートを使用して典型的な負荷を記録し、それをデータベース エンジン チューニング アドバイザーで実行して、パフォーマンスを向上させるためにインデックスを追加できる場所を確認することもできます。

通常、サーバーに対して実行されるクエリを最適化することもできますが、MapGuide に関してはオプションが少し不足しています。MapGuide は、SQL Server が最適化するのが難しい方法で質問をしている可能性があります。このような場合は、MapGuide Tracシステムにチケットを入力してください。

于 2010-08-04T07:51:39.340 に答える
0

CPU 使用率は SQL または mapguide デーモンですか?

私たちが遭遇した問題の 1 つは、mapguide がクエリの記述に関してそれほどスマートではないということです。最大ズームで凡例の小さなサブセットを表示する場合 (そのズーム レベルでの透過のみなど)、他のフィルターを適用せずにビュー エリア内のすべてのオブジェクトをクエリします。次に、何千ものレコードをループし、テーマを適用します (別のフィルターを使用します)。

試してみることができるのは、さまざまなズーム レベルのレイヤーを作成し、クエリ フィルターを使用して、SQL から返されるデータの量を制限することです (おそらく、これが非常に多くの CPU 時間を消費しています)。これにより、送電線と配電網 (そのレベルで表示する意味のある唯一のもの) の初期ロード時間が 20 秒以上から数ミリ秒に短縮されました。

--

私が話していたのは、レイヤーが必要とするデータのみを要求していることを確認することです。ID 1、2、3、および 4 を表示するとします。

スケール 0 -> 無限大でディスプレイ 1 と 2 があるとします。3 と 4 は、たとえば 20,000 フィートでしか機能しません。デフォルトでは、mapguide は基本的にビューポートのバウンディング ボックスで select * を行います。次に、テーマを適用するすべてのデータをループします。

したがって、たとえば 30,000 フィートでは、すべてのデータを照会しますが、それでもループする必要があります。

于 2009-11-30T03:22:57.617 に答える
0

簡単な答えは、データを一般化して、表示用に最適化することです

つまり、詳細が少なく、密度が低い追加のテーブルをいくつか作成します

于 2010-06-01T15:50:31.833 に答える