web-dev-qa-db-ja.com

なぜAzure SQL（SQL Server）データベースは、一度に一定期間データIO）で過負荷になるのですか？

S2エディション（50 DTU）でAzure SQLデータベースを実行しています。サーバーの通常の使用では、通常、約10％のDTUがハングします。ただし、このサーバーは定期的に、データベースのDTU使用率を数時間にわたって85〜90％に送信する状態になります。その後、突然、通常の10％の使用量に戻ります。

enter image description here

この過負荷状態の間、アプリケーションからのサーバーに対するクエリは、まだ高速に動作しているようです。

サーバーをS2 =>何からでもスケーリングできます（たとえば、S3）=> S2。サーバーがハングしている状態をすべてクリアするように見えます。しかし、数時間後、同じ過負荷状態のサイクルが繰り返されます。私が気付いたもう1つの奇妙なことは、このサーバーをS3プラン（100 DTU）で24時間年中無休で実行した場合、この動作は観察されなかったことです。データベースをS2プラン（50 DTU）にダウンスケールした場合にのみ発生するようです。 S3プランでは、私は常に5-10％DTU使用率で座っています。明らかに十分に活用されていません。

不正なクエリを探してAzure SQLクエリレポートをチェックインしましたが、実際に異常なものは見られず、期待どおりにリソースを使用してクエリが表示されます。

enter image description here

ここでわかるように、使用法はすべてData IOからのものです。ここでパフォーマンスレポートを変更して、上位のデータIOクエリをMAXで表示すると、次のようになります。

enter image description here

これらの長期にわたる要求を見ると、統計の更新が指摘されているようです。私のアプリケーションから実際には何も実行されていません。たとえば、クエリ16302には次のように表示されます。

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

ただし、この場合も、レポートでは、これらのクエリがサーバーで使用しているデータの割合が少ないことを示していますIOサーバーでの使用率（<4％）。統計の更新（およびインデックスの再構築）も実行しています。定期的なメンテナンスの一環として、データベース全体で毎週。

これは、リソース使用率の高いインシデントの間のみ数時間をカバーするタイムスパンのMAXデータIOクエリを示す別のレポートです。

enter image description here

ご覧のとおり、重要なデータをレポートするクエリは実際にはありませんIO使用状況。

私も走ったsp_who2およびsp_whoisaciveデータベース上で、何も飛び出していないように見えます（ただし、これらのツールの専門家ではないことは認めます）。

ここで何が起こっているのかをどのようにして理解できますか？私のアプリケーションクエリのどれもがこのリソースの使用に責任があるとは思わず、サーバーのバックグラウンドで実行されている内部プロセスが強制終了しているように感じます。

sql-serverazure-sql-databasestatistics
9
kspearrin

スパイク中のログアクティビティが最小限であることを考えると、DUIが実行されていない（または多くない）と想定できます。

ある時点で、スパイクがパフォーマンスに影響を及ぼさないと述べ、別の時点でスパイクが影響を与えると述べました。どっち？

また、これはスケール操作の後でなくなることにも言及しています。これは、すべてのプロセスなどを効果的に強制終了するオンプレミスの再起動に類似しているため、理にかなっています。

このデータベースがアプリケーション層からアクセスされていると推測して、正しく推測できますか？もしそうなら、あなたの接続が適切に閉じられていないだと思います。ガベージコレクターはこれらを最終的に処理することになっています（これに依存することはできません）が、アプリ層からの閉じられていない接続が原因でこの正確な状況が発生するのを見てきました。私たちの場合、アプリケーションが非常にビジーだったため、結局は同時接続エラーが発生し、それが問題の原因となっています。

スパイク中に次のクエリを試してください。

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.Host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

私が正しければ、Sleeping、またはより悪いのはRunningのステータスで返される一連のレコードがすべて見つかります。その場合、アプリ層でさらに大きな問題が発生します。

これをさらにデバッグするには、データベースをコピーし、次のクエリ（基本階層を使用して過度のコストを回避）を使用し、この動作を監視します。

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );
1
pimbrouwers