運用SQL Serverの主なパフォーマンスの問題、これをトラブルシューティングするにはどうすればよいですか？

Question

この質問は基本的に、この質問の補足質問です。
SQL Server 2016の奇妙なパフォーマンスの問題

このシステムで生産性が向上しました。私の最後の投稿以来、別のアプリケーションデータベースがこのSQL Serverに追加されましたが。

これらはシステム統計です：

128 GB RAM（SQL Serverの最大メモリは110GB）
4コア@ 2.6 GHz
10 GBitネットワーク接続
すべてのストレージはSSDベースです
プログラムファイル、ログファイル、データベースファイル、およびtempdbは、サーバーの別のパーティションにあります。
Windowsサーバー2012 R2
VMwareバージョンHPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
VMware Toolsバージョン10.0.9、ビルド3917699
Microsoft SQL Server 2016（SP1）（KB3182545）-13.0.4001.0（X64）2016年10月28日18:17:30 Copyright（c）Microsoft Corporation Standard Edition（64-bit）on Windows Server 2012 R2 Standard 6.3（Build 9600：）（ハイパーバイザー）

現在、システムに大きなパフォーマンスの問題があります。非常に高いCPU使用率とスレッド数：

アクティビティモニターの待機統計（あまり信頼性がないことはわかっています）

Sp_blitzfirstの結果：

Sp_configureの結果：

サーバーの詳細設定（ドイツ語のみの不幸）

MAXDOP設定は私が変更しました。

これはおそらくSQL Server自体の問題ではないことを知っています。これはおそらく、仮想化（vmware）、ネットワーク関連（すでにテスト済み）、またはアプリケーション自体の問題です。私はそれをさらに釘付けにしたいだけです。

ASYNC_NETWORK_IOが高いと、sqlserverプロセスのスレッド数が多くなりますか？スレッドを閉じることができないため、多くのワーカーが急上昇すると思います。そうですか？

必要な追加情報を提供します。よろしくお願いします！

編集：

の結果 sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

優先度1：バックアップ：

データベースが存在する同じドライブへのバックアップ-過去2週間にドライブE：\で5つのバックアップが行われ、データベースファイルも存在します。これは、そのアレイに障害が発生した場合の重大なリスクを表しています。

優先度1：信頼性：

2週間以上前の最後の良いDBCC CHECKDB
- babtec_prod-最後に成功したCHECKDB：2017-08-20 00：01：01.513
- D3PR-最後に成功したCHECKDB：決して。
- DEMO77-最後に成功したCHECKDB：2016-02-23 20：31：38.590
- FINP-最後に成功したCHECKDB：2017-04-23 22：01：19.133
- GridVis_EnMs-最後に成功したCHECKDB：2017-05-18 22：10：48.120
- マスター-最後に成功したCHECKDB：決して。
- モデル
- msdb
- PROD77-最後に成功したCHECKDB：2016-02-23 21：33：24.343

優先度10：パフォーマンス：

クエリストアが無効-このデータベースでは、SQL Server 2016の新しいクエリストア機能が有効になっていません。
- babtec_prod
- D3PR
- デモ77
- FINP
- GridVis_EnMs

優先度50：DBCCイベント：

DBCC DROPCLEANBUFFERS-ユーザーschorschは、2017年9月21日11:57 AMと2017年9月21日11:57 AMの間にDBCC DROPCLEANBUFFERSを1回実行しました。これがプロダクションボックスである場合は、これが発生したときにメモリからすべてのデータを消去していることを確認してください。どんなモンスターがそれをするでしょうか？
DBCC SHRINK％-ユーザーschorschが実行したファイル圧縮は、2017年9月21日11:51 PMからOkt 4 2017 9:02 AMの間に6回実行されました。それで、ええと、彼らは腐敗を修正しようとしているのでしょうか、それとも腐敗を引き起こしているのでしょうか？
全体的なイベント-2017年9月19日の午後1時40分からOkt 4 2017の午後3時20分までに287件のDBCCイベントが発生しました。これには、CHECKDBやその他の通常無害なDBCCイベントは含まれません。

優先度50：パフォーマンス：

ファイルの増加が遅いPROD77-2の増加にそれぞれ15秒以上かかりました。ファイルの自動拡張を小さな増分に設定することを検討してください。

優先度50：信頼性：

ページ検証が最適ではありませんbabtec_prod-データベース[babtec_prod]には、ページ検証用のTORN_PAGE_DETECTIONがあります。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

優先度100：パフォーマンス：

1つのクエリに対する多くのプラン-3576のプランがプランキャッシュ内の1つのクエリに存在します。つまり、おそらくパラメーター化の問題があります。

優先度110：パフォーマンス：

クラスタ化インデックスのないアクティブテーブル
- babtec_prod-[babtec_prod]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。
- D3PR-[D3PR]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。
- DEMO77-[DEMO77]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。
- FINP-[FINP]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。
- GridVis_EnMs-[GridVis_EnMs]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。
- PROD77-[PROD77]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

優先度150：パフォーマンス：

信頼されていない外部キー
- babtec_prod-[babtec_prod]データベースには、おそらく無効にされた外部キーがあり、データが変更されてから、キーが再び有効にされました。オプティマイザがこのキーを使用するには、キーを有効にするだけでは不十分です。WITHCHECK CHECK CONSTRAINTパラメータを使用してテーブルを変更する必要があります。
- D3PR-[D3PR]データベースには、おそらく無効になっている外部キーがあり、データが変更されてから、キーが再び有効になりました。オプティマイザがこのキーを使用するには、キーを有効にするだけでは不十分です。WITHCHECK CHECK CONSTRAINTパラメータを使用してテーブルを変更する必要があります。
クラスタ化インデックスのない非アクティブなテーブル
- D3PR-[D3PR]データベースには、最後の再起動以降クエリされていないヒープ（クラスター化インデックスのないテーブル）があります。これらは、不用意に取り残されたバックアップテーブルである可能性があります。
- GridVis_EnMs-[GridVis_EnMs]データベースには、最後の再起動以降クエリされていないヒープ（クラスター化インデックスのないテーブル）があります。これらは、不用意に取り残されたバックアップテーブルである可能性があります。
テーブルのトリガーbabtec_prod-[babtec_prod]データベースには26のトリガーがあります。

優先度170：ファイル構成：

Cドライブのシステムデータベース
- master-masterデータベースには、Cドライブにファイルがあります。システムデータベースをCドライブに置くと、スペースが不足するとサーバーがクラッシュする危険性があります。
- モデル-モデルデータベースのCドライブにファイルがあります。システムデータベースをCドライブに置くと、スペースが不足するとサーバーがクラッシュする危険性があります。
- msdb-msdbデータベースには、Cドライブにファイルがあります。システムデータベースをCドライブに置くと、スペースが不足するとサーバーがクラッシュする危険性があります。

優先度170：信頼性：

最大ファイルサイズセット
- D3PR-[D3PR]データベースファイルd3_data_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_data_idx_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_firm_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_firm_idx_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_log_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_phys_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_phys_idx_01の最大ファイルサイズは61440MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_sys_01の最大ファイルサイズは20480MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_usr_01の最大ファイルサイズは20480MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_wort_01の最大ファイルサイズは20480MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。
- D3PR-[D3PR]データベースファイルd3_wort_idx_01の最大ファイルサイズは20480MBに設定されています。領域が不足すると、使用可能なドライブ領域がある場合でも、データベースは動作を停止します。

優先度200：情報提供：

バックアップ圧縮のデフォルトオフ-最近、非圧縮フルバックアップが行われ、サーバーレベルでバックアップ圧縮がオンになっていません。 SQL Server 2008R2以降には、Standard Editionでもバックアップ圧縮が含まれています。アドホックバックアップが圧縮されるように、デフォルトでバックアップ圧縮をオンにすることをお勧めします。
照合順序はLatin1_General_CS_AS FINPです-ユーザーデータベースとtempdbの照合順序の違いにより、特に文字列値を比較するときに競合が発生する可能性があります
照合順序はSQL_Latin1_General_CP1_CI_AS-ユーザーデータベースとtempdbの照合順序の違いにより、特に文字列値を比較するときに競合が発生する可能性があります
- デモ77
- PROD77
リンクサーバーの構成-BWIN2\INFORはリンクサーバーとして構成されています。 saに接続しているときにセキュリティ構成を確認してください。クエリを実行するユーザーは管理者レベルの権限を取得するためです。

優先度200：監視：

失敗メールのないエージェントジョブ
- ジョブsyspolicy_purge_historyは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブupd_durchpreis_monatlは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブupd_fertmengen_wocheは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブupd_liegezeit_monatlは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブupd_vertreter_diffは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブUPDATE_CONNECT_IKは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブWartung.Cleanupは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブWartung.DBCC Check DBは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブWartung.Index neu erstellenは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブWartung.Statistiken aktualisierenは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブWartung.Transactionlog Backupは、失敗した場合にオペレーターに通知するように設定されていません。
- ジョブWartung.Vollbackup SystemDBは、失敗した場合にオペレーターに通知するようにセットアップされていません。
- ジョブWartung.Vollbackup UserDBは、失敗した場合にオペレーターに通知するようにセットアップされていません。
破損のアラートなし-エラー823、824、および825のSQL Serverエージェントアラートは存在しません。これらの3つのエラーは、初期のハードウェア障害に関する通知を提供します。それらを有効にすると、多くの失恋を防ぐことができます。
Sev 19-25のアラートなし-重大度レベル19〜25のSQL Serverエージェントアラートは存在しません。これらは、いくつかの非常に重大なSQL Serverエラーです。これらが発生していることを知っていると、エラーからより早く回復できる場合があります。
すべてのアラートが構成されていません-SQL Serverエージェントのすべてのアラートが構成されていません。これは、監視システムが検出する前でも、破損、ジョブの失敗、または重大な停止について通知を受ける無料の簡単な方法です。

優先度200：デフォルト以外のサーバー構成：

エージェントXP-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。
データベースメールXP-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。
デフォルトのフルテキスト言語-このsp_configureオプションは変更されました。デフォルト値は1033で、1031に設定されています。
デフォルト言語-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。
filestreamアクセスレベル-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。
最大並列度-このsp_configureオプションが変更されました。デフォルト値は0で、4に設定されています。
最大サーバーメモリ（MB）-このsp_configureオプションが変更されました。デフォルト値は2147483647で、115000に設定されています。
min server memory（MB）-このsp_configureオプションは変更されました。デフォルト値は0で、10000に設定されています。
リモート管理接続-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。

優先度200：パフォーマンス：

並列処理のコストしきい値-5に設定、そのデフォルト値。このsp_configure設定を変更すると、CXPACKETの待機が減少する場合があります。
スナップショットバックアップの発生-過去2週間に9つのスナップショットのようなバックアップが発生し、IOがフリーズしている可能性があることを示しています。

優先度210：デフォルト以外のデータベース構成：

コミットされたスナップショット分離の読み取りが有効-このデータベース設定はデフォルトではありません。
- D3PR
- FINP
再帰トリガーが有効-このデータベース設定はデフォルトではありません。
- デモ77
- PROD77
スナップショット分離有効FINP-このデータベース設定はデフォルトではありません。

優先度240：待機統計：

1-ASYNC_NETWORK_IO-225.9時間の待機、1時間あたり平均143.5分の待機時間、0.2％のシグナル待機、2146022の待機タスク、378.9ミリ秒の平均待機時間。
2-CXPACKET-43.1時間の待機、1時間あたり27.4分の平均待機時間、1.5％の信号待機、32608391待機タスク、4.8ミリ秒の平均待機時間。

優先度250：情報提供：

SQL ServerはNTサービスアカウントで実行されています
- NT Service\MSSQL $ INFORとして実行しています。代わりにActive Directoryサービスアカウントが必要です。
- NT Service\SQLAgent $ INFORとして実行しています。代わりにActive Directoryサービスアカウントが必要です。

優先度250：サーバー情報：

デフォルトのトレースの内容-デフォルトのトレースは、2017年9月3日の午後8時34分から2017年のオクト5午後12時50分までの760時間のデータを保持します。デフォルトのトレースファイルは次の場所にあります：C：\ Program Files\Microsoft SQL Server\MSSQL13.INFOR\MSSQL\Log
ドライブCスペース-Cドライブに21308.00MBの空き容量
ドライブDスペース-Dドライブに280008.00MBの空き容量
ドライブEスペース-Eドライブに281618.00MBの空き容量
ドライブFスペース-Fドライブに60193.00MBの空き容量
ハードウェア-論理プロセッサ：4.物理メモリ：128GB。
ハードウェア-NUMA構成-ノード：0状態：オンラインオンラインスケジューラー：4オフラインスケジューラー：0プロセッサーグループ：0メモリノード：0メモリVAS予約済みGB：281
サーバーの最終再起動-Okt 1 2017 2:21 PM
サーバー名-BWINPDB\INFOR
サービス
- サービス：SQL Server（INFOR）は、サービスアカウントNT Service\MSSQL $ INFORで実行されます。最終起動時間：2017年Okt 1 2:22 PM。スタートアップの種類：自動、現在実行中。
- サービス：SQL Server-Agent（INFOR）は、サービスアカウントNT Service\SQLAgent $ INFORで実行されます。最終起動時間：表示されません。起動タイプ：自動、現在実行中。
SQL Server最終再起動-2017年Okt 1 2:22 PM
SQL Serverサービス-バージョン：13.0.4001.0。パッチレベル：SP1。エディション：スタンダードエディション（64ビット）。 AlwaysOn有効：0。AlwaysOnマネージャステータス：2
仮想サーバー-タイプ：（HYPERVISOR）
Windowsバージョン-Windowsの最新バージョンを実行している：サーバー2012R2時代、バージョン6.3

優先度254：Rundate：

キャプテンのログ：何かをスターデートする...

編集：

Vmwareを使用したSQLサーバーのセットアップに関するベストプラクティスガイドについてはすでに調査しましたが、このホワイトペーパーに従って、そのほとんどを設定しました。ただし、ハイパースレッディングはアクティブ化されておらず、NUMAはVMwareホスト上ではアクティブではありません。 SQL ServerはNUMAに設定されています。

編集：

並列処理のしきい値を50に設定した後にRECONFIGUREを発行しましたが、私のMAXDOP設定も構成されていませんでした。

私もvmware管理者に確認しましたが、誤って知らされたようです。 CPUは4.6 GHzではなく2.6 GHzに設定されています。上記の情報を修正しました。

編集：

vmwarekb および guide に従って、関連するネットワークを設定しようとしました。また、VMにさらに4つのコアを追加しました。 CPU使用率は変わりませんでした。

Emptyslot · Accepted Answer

私自身の質問に答えるために。 ASYNC_NETWORK_IOは実際には問題ではありませんでした。レイテンシの影響を受けやすいワークロードについてこのガイドに従うことで、パフォーマンスの問題を修正しました。

vSphere VMでのレイテンシの影響を受けやすいワークロードのパフォーマンスチューニングのベストプラクティス

ここで、システムに適用した設定を黄色でマークしました。

最も影響を与えた設定はnuma configurationと設定latency Sensitivityからhigh。どちらも、物理CPUコアを明示的に割り当て/予約するために必要であり、RAM for the VM）。

また、VMにコアを追加しました。SQLServerライセンスをStandardからEnterpriseにアップグレードする必要があります。

Brent Ozar · Answer

議論したように最後にこの質問をしたとき、あなたの一番の待ちはASYNC_NETWORK_IOです。 SQL Serverは、パイプの反対側のマシンがクエリ結果の次の行を消化するのを待っています。

私はこの情報をsp_Blitzの待機統計結果から取得しました（それを貼り付けてくれてありがとう）：

1-ASYNC_NETWORK_IO-225.9時間の待機、1時間あたり平均143.5分の待機時間、0.2％のシグナル待機、2146022の待機タスク、378.9ミリ秒の平均待機時間。

CPUスレッドのトラブルシューティングに取り掛からないでください。これは関係ありません。主な待機タイプと、その待機タイプの原因となるものに焦点を当てます。

これをさらにトラブルシューティングするには、 sp_WhoIsActive または sp_BlitzFirst を実行します（免責事項：私はその作成者の1人です）-どちらも現在実行中のクエリを一覧表示します。待機情報の列を確認し、ASYNC_NETWORK_IOを待機しているクエリを見つけ、実行元のアプリとサーバーを確認します。

そこから、次のことを試すことができます。

それらのアプリサーバーが十分に機能していないかどうかを確認し（CPUが使い果たされているか、ディスクにページングされているかなど）、それらを調整します
アプリの開発者と協力して、結果に対して行ごとの処理を行っているかどうかを確認します（SQL Serverから返されるすべての行について、アプリはオフになり、次の結果の行を要求する前に何らかの処理を行います）。
アプリの開発者と協力して選択するデータを少なくする（すべてのデータが不要な場合は行や列を少なくするなど）-誤ってSELECT *を実行して必要以上のデータを返却したり、要求したりすると、これが表示されることがあります上位1000件のみが本当に必要な場合のすべての行）

sp_WhoIsActiveで更新-投稿したsp_WhoIsActiveスクリーンショットには、ASYNC_NETWORK_IOで待機しているクエリがいくつかあります。それらについては、上記の手順を参照してください。

残りのクエリでは、sp_WhoIsActiveの "status"列を確認します。それらの大部分は "スリープ状態"です。つまり、まったく機能していないということです。パイプの反対側にあるアプリが次のコマンドを送信するのを待っています。トランザクションは開いていますが（「open_tran_count」列を参照）、SQL Serverがスリープ状態のトランザクションを高速化するためにできることは何もありません。これらのクエリは40分以上開いています（sp_WhoIsActiveの最初の列。彼らはもう何もしていないだけです。これらの人々にトランザクションをコミットさせて閉じる必要がありますこれはパフォーマンスチューニングの問題ではありません。

ここに表示されているものはすべて、アプリで待機しているシナリオを示しています。

Milney · Answer

Windowsが最近の4.6Ghz CPUコアのクロック速度を2.6Ghzとして報告しているようです... CPU-Zなどのツールを実行して、実際に実行されている速度を確認し、電源設定の変更を確認しますWindowsとBIOS /管理OSの両方を使用して、コアを低速に抑制している可能性のある省電力設定を無効にします。