web-dev-qa-db-ja.com

SQLサーバーの待機時間の理想的な値

これは ここに自分の投稿 に関連しています

SQLサーバーは毎日午前8時30分に開始し、午後9時30分頃に停止します（したがって、待ち時間は毎日リセットされます）SQLサーバーは約60人のユーザーによって同時に使用されます（データを直接変更するために使用され、アプリケーションのバックエンドデータベースも使用されます）私たちのオフィスで使用しています）サーバーには8 GBのRAMがあります。ほとんどのデータベースで毎時間ログバックアップが行われます（SQLバックアップを自動化する独自のバックアップツールでバックアップが行われます）。

これで説明したように article 以下のクエリを使用しました。

select *
from sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
        N'CLR_SEMAPHORE',    N'LAZYWRITER_SLEEP',
        N'RESOURCE_QUEUE',   N'SQLTRACE_BUFFER_FLUSH',
        N'SLEEP_TASK',       N'SLEEP_SYSTEMTASK',
        N'WAITFOR',          N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'XE_TIMER_EVENT',   N'XE_DISPATCHER_JOIN',
        N'LOGMGR_QUEUE',     N'FT_IFTS_SCHEDULER_IDLE_WAIT',
        N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
        N'CLR_AUTO_EVENT',   N'DISPATCHER_QUEUE_SEMAPHORE',
        N'TRACEWRITE',       N'XE_DISPATCHER_WAIT',
        N'BROKER_TO_FLUSH',  N'BROKER_EVENTHANDLER',
        N'FT_IFTSHC_MUTEX',  N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'DIRTY_PAGE_POLL',  N'SP_SERVER_DIAGNOSTICS_SLEEP')
order by wait_time_ms desc;

そして結果は以下のようになりました（上位25行のみが表示されています）

enter image description here

今、この結果を得た後、これらの値が本当に高いのか、それとも通常のシナリオなのか混乱しています（SQLに関連するパフォーマンスカウンターの値も取得しましたが、ほとんどの記事では、どのパフォーマンスカウンターになるかを説明しているだけなので、トラブルシューティングできません適切に分析することではなく、使用するか、サーバーのパフォーマンスを見つけるのが難しい））これらの理想的な値は何ですか？ SQLサーバーのパフォーマンスに問題があるかどうか。どうやって決めるの？

sql-serverperformancesql-server-2008-r2wait-types
3
IT researcher

考慮する必要があるのは、wait_time_msまたはwaiting_tasks_countの絶対値だけではなく、平均待機時間も確認する必要があります。平均的な待機時間を確認するときは、次のことを自問してください。「これは、このリソースを待機するのに十分な時間ですか？」

たとえば（私が数学で正しく計算している場合）PAGEIOLATCHの待機時間は4〜5ミリ秒です。これは「良好」です。これは、I/O要求をフェッチするハードドライブの応答時間だからです。ただし、SSDで実行している場合（この値が1msの範囲にとどまると予想される場合）は、「不良」です。

別の例として、WRITELOGの待機時間が10msを超えています。シーケンシャルI/Oを正しく行うと、この値は（回転するRustでも）1msの範囲になるはずなので、これは「悪い」ものです。

ただし、これはすべて、達成しようとしている内容のコンテキストで確認する必要があります。 「一般的に物事をより速くする」ことを検討している場合（珍しい要求ではありません）、最も害を及ぼす可能性が最も高い（wait_time_msによる）最大待機を最初に確認する必要があります。チューニングの対象がより限定されている場合は、特定の待機タイプを確認してください。リストの下位にある場合でも同様です。

たとえば、平均70ミリ秒のLCK_M_S待機があります。それらは非常に少ないので、それらは重要に見えません。しかし、おそらくそれらは一部の重要なユーザーに影響を与えます。これがOLTPクエリが速く出入りするシステムである場合-70msは「悪い」数値です（実行時間の短いトランザクションのロックは数ミリ秒またはマイクロ秒でさえ保持されるため） 。

別の例：DMLクエリを高速化しようとしている場合は、WRITELOGおよびPAGEIOLATCH_EXの待機を対象にする必要があります。読み取りを最適化している場合は、PAGEIOLATCH_SHの待機時間を減らす（SSDやRAMを使用するなど）か、データベースの読み取りI/Oを少なくする（インデックスを最適化するなど）ことに重点を置きます。

4
Thomas Kejser

結果セットにCXPACKETの待機がないことに気づきました。並列処理を無効にしましたか？ MAXDOPの設定を見ると、1に設定されていると思います。これで問題ない場合もありますが、まれです。このボックスで並列処理を有効にして、ワークロードを調整します。ここで順序を逆にするかもしれません。次に、並列処理を有効にします。

さらに、BACKUPBUFFERとBACKUPIOが表示されます。サードパーティのツールを使用してバックアップを完了していますか？バックアップはネットワーク共有に対して実行されていますか？

私はアーロンと一緒に拳の目線。 IOサブシステムに深刻な問題があります。

1
Mike West