2

私たちのシステムは、公称荷重、たとえば1インスタンスあたり1秒あたり120インサートの下で絞り壁にぶつかっています。実行中の他の並行プロセスがあり、それらはオフロード/最適化などです。私が知りたいのはこれです：インデックスの存在がスロットルに与える影響のレベルについて誰かが洞察を持っていますか？システムの他の場所でインデックスの存在が役立つパフォーマンスの問題がいくつかありますが、CPUとI / Oの負荷が増えるため、追加することを躊躇します。

ここでの実際のアドバイスは大歓迎です。SQLAzure固有にしてください。

4

3 に答える 3

2

スロットリングは基本的に、CPU、メモリ、およびディスクの使用量の上限にすぎません。したがって、スロットリングに対するインデックスの影響は、それらのリソースへの影響に要約されます。つまり、これは他のパフォーマンス調整シナリオとまったく同じです。どの制限に達しているかを把握し、それをどのように使用するかを決定します。

SQL Azureは、主にすべてのクールなDMVにアクセスできるわけではないという点でSQLServerとは異なります。あなたはまだいくつかを手に入れますが、すべてではありません。取得する利点の1つは、スロットルエラーが発生した場合に、スロットルされているリソースを通知する必要があることです。

状況によっては、次のクエリが役立つ場合があります。私はGlennBerryからこれらを盗みました。私の唯一の貢献は、それらがAzureで実行されていることを理解することです。彼は、Azure以外のインストールに集中していますが、SQLパフォーマンスの作業についても多くの優れたアドバイスを受けています。

--List query plans and stats ordered by last execution time
SELECT TOP(50) q.text, s.last_execution_time, s.execution_count, s.total_worker_time, 
        s.max_elapsed_time, s.max_worker_time,  (s.total_worker_time / s.execution_count) AS AverageExecutionTime,
        s.max_physical_reads, s.max_logical_reads, 
        s.max_logical_writes, s.min_rows, s.max_rows
FROM sys.dm_exec_query_stats as s
      cross apply sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY s.last_execution_time DESC


--List query plans and stats ordered by average execution time
SELECT TOP(50) q.text, s.last_execution_time, s.execution_count, s.total_worker_time, 
        s.max_elapsed_time, s.max_worker_time, (s.total_worker_time / s.execution_count) AS AverageExecutionTime,
        s.max_physical_reads, s.max_logical_reads, 
        s.max_logical_writes, s.min_rows, s.max_rows
FROM sys.dm_exec_query_stats as s
      cross apply sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY [AverageExecutionTime] DESC

--Get 50 most I/O intensive queries
SELECT TOP(50) OBJECT_NAME(qt.objectid) AS [SP Name],
qs.total_logical_writes,
qs.total_logical_reads,
(qs.total_logical_reads + qs.total_logical_writes) /qs.execution_count AS [Avg IO],
SUBSTRING(qt.[text],qs.statement_start_offset/2, 
    (CASE 
        WHEN qs.statement_end_offset = -1 
     THEN LEN(CONVERT(nvarchar(max), qt.[text])) * 2 
        ELSE qs.statement_end_offset 
     END - qs.statement_start_offset)/2) AS [Query Text],
qs.execution_count,
qs.creation_time
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
WHERE qt.[dbid] = DB_ID()
ORDER BY [Avg IO] DESC OPTION (RECOMPILE);

--Get executing requests
SELECT session_id, blocking_session_id, wait_type, last_wait_type, wait_time, total_elapsed_time, cpu_time, logical_reads, reads, writes
FROM sys.dm_exec_requests AS r
ORDER BY wait_time DESC
于 2012-05-02T23:40:55.610 に答える
1

もちろん、インデックス作成に関しては、クエリのオーバーヘッドとパフォーマンスの向上のトレードオフを評価する必要があります。最も害を及ぼすのは、使用されていないインデックスです。これは、インデックスを維持するためのオーバーヘッドが、抑制されるもののカテゴリに分類されるためです。

インデックスを追加した場合、現在は廃止されている別のインデックスを削除できますか？インデックスを追加した結果、クエリが消費する制限されたリソース（I / O、メモリ、CPU）が少なくなっていますか？

また、CPUがハードな方法（I / Oやメモリなど）で抑制されなくなったことにも注意してください。クエリの実行速度は遅くなりますが、実行は遅くなります。

結局、インデックスの作成時（または更新時）を除いて、インデックスがスロットルの重要な原因になることはめったにありません。それでも、SQLServerのようにSQLAzureにも常識が当てはまります。つまり、幅が広すぎないインデックスを作成し、インデックスによって既存のクエリリソースの消費が削減されるようにします。

DMVを使用すると、全体的なリソース消費量が減少しているかどうかを判断するのに役立ちます。

于 2012-05-02T23:51:45.753 に答える
0

クラスタ化されたインデックスを持つPKにGUIDを使用しないようにしてください。

于 2012-05-04T01:03:29.210 に答える