より優れたストレージにアップグレードした後のチェックポイント中の待機の増加
古いオールフラッシュアレイから新しいオールフラッシュアレイ（異なるが、確立されたベンダー）に移行すると、チェックポイント中にSQL Sentryで待機が増加することがわかりました。
バージョン：SQL Server 2012 Sp4
私たちの古いストレージでは、待機時間はチェックポイント中の「スパイク」が2500になるまで約2kでしたが、新しいストレージではスパイクは通常10kで、ピークは50k近くです。セントリーは、PAGEIOLATCHワティスにもっと私たちを向けます。独自の分析を行うと、それはPAGEIOLATCH and PAGELATCH待機の組み合わせのようです。 Perfmonを使用すると、一般に、チェックポイントのページが増えるほど、待機時間が長くなりますが、フラッシュするのは、チェックポイント中に〜125 MBだけです。私たちのワークロードはほとんどが書き込みです（主に挿入/更新）。
ストレージベンダーは、ファイバチャネル直接接続アレイがこれらのチェックポイントイベント中に1 ms未満応答していることを証明しています。 HBAはアレイの番号も確認します。また、キューの深さが8を超えることはなかったため、これはHBAキューの問題であるとは考えていません。ZIO、実行スロットル、およびキューの深さの設定を無効にして、新しいHBAを試しました。また、サーバーのメモリを500 GBから1に増やしましたTB変更なし。チェックポイントプロセス中に、2〜4個の個別のコア（16個のうち）が100％に急上昇していますが、全体的にCPUは約20％です。BIOSも同様に高パフォーマンスに設定されています。興味深いことに、CPUを無効にしても、通常はC2スリープ状態であるため、スリープ状態になる理由を調査しています。 C1を過ぎて。
ほとんどすべての待機が、DCMページタイプのPFSが時々発生するデータページで発生していることがわかります。待機はtempdbではなくユーザーDBで行われます。また、待機が複数のデータページにわたって行われ、一部のSPIDが同じページで待機していることもわかります。データベース設計には、いくつかの挿入ホットスポットがありますが、同じ設計が古いストレージに配置されていました。
このクエリのループを100回実行すると、ディスクとメモリで待機しているSPIDの数を把握できました。
SELECT
[owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type]
order by 1
GO 100
「良い」ことは、同じモデル配列と類似のサーバー仕様を持つパフォーマンス環境で問題を簡単に再現できることです。他にどこを見るべきか、どのように問題を絞り込むかについての考えをいただければ幸いです。現在、次のテストは次のとおりです。新しいマザーボードとより多くのCPUを搭載した新しいサーバー。 SIOSデータキーパーを無効にします（これは古いストレージに配置されていますが）。別のHBAブランド。
exec sp_Blitz @outputtype = 'markdown'
優先度5：信頼性：-危険なサードパーティモジュール-ソフォス限定-ソフォスのバッファオーバーラン保護-SOPHOS〜2.DLL-危険なサードパーティモジュールがインストールされている。
優先度200：情報：-クラスターNode-これはクラスター内のノードです。-TraceFlag On-トレースフラグ1117はグローバルに有効-トレースフラグ1118はグローバルに有効-トレースフラグ3226はグローバルに有効.
優先度200：ライセンス：-使用中のEnterprise Edition機能* xxxxx-[xxxxxx]データベースは圧縮を使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 SP1より前のバージョンでは復元が失敗します。 * xxxxx-[xxxxxx]データベースはパーティショニングを使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 SP1より前のバージョンでは復元が失敗します。
優先度240：待機統計：-重要な待機が検出されなかった-このサーバーはアイドル状態で待機している、または誰かが最近待機統計をクリアした可能性があります。
優先度250：サーバー情報：-ハードウェア-論理プロセッサ：16.物理メモリ：512GB。 -ハードウェア-NUMA構成-ノード：0状態：オンラインオンラインスケジューラ：8オフラインスケジューラ：0プロセッサグループ：0メモリノード：0メモリVAS予約済みGB：1177-ノード：1状態：オンラインオンラインスケジューラ：8オフラインスケジューラ：0プロセッサグループ：0メモリノード：1メモリVAS予約済みGB：0-電源プラン-サーバーに3.50 GHz CPUがあり、高性能電源モードです-サーバーの最終再起動-2018年7月4日4:56 AM-SQLサーバーの最終再起動-7月5日2018 5:11 AM-SQL Serverサービス-バージョン：11.0.7462.6。パッチレベル：SP4。エディション：Enterprise Edition（64ビット）。可用性グループの有効化：1.可用性グループマネージャーのステータス：1-仮想サーバー-タイプ：（HYPERVISOR）-Windowsバージョン-Windowsのかなり新しいバージョンを実行しています：サーバー2012R2時代、バージョン6.3
優先度200：デフォルト以外のサーバー構成：-エージェントXP-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-バックアップ圧縮のデフォルト-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-ブロックされたプロセスのしきい値（複数可）-このsp_configureオプションが変更されました。デフォルト値は0で、20に設定されています。-並列処理のコストしきい値-このsp_configureオプションが変更されました。デフォルト値は5で、30に設定されています。-データベースメールXP-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-最大並列度-このsp_configureオプションが変更されました。デフォルト値は0で、8に設定されています。-最大サーバーメモリ（MB）-このsp_configureオプションが変更されました。デフォルト値は2147483647で、496640に設定されています。-最小サーバーメモリ（MB）-このsp_configureオプションが変更されました。デフォルト値は0で、8196に設定されています。-アドホックワークロード用に最適化-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-リモートアクセス-このsp_configureオプションが変更されました。デフォルト値は1で、0に設定されています。-リモート管理接続-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-起動プロシージャをスキャン-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-詳細オプションを表示-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。-xp_cmdshell-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。
うーん。チェックポイント中に待機しているspidが表示されますが、平均または全体で待機している時間は表示されません（正直なところ、私が気にするのはこれだけです）。差分待機統計分析を実行して、期間が問題かどうかを確認します。また、チャートの2つの待機は正確には何ですか？ RAMが1TBの状態で大量のメモリ許可待機が発生する場合は、別の議論が必要です。:-D
チェックポイント時の125MBの書き込み速度：チェックポイントが書き込むのはALLですか？いずれにしても、オールフラッシュストレージの場合は低そうです。さまざまな書き込みパターンのストレージについてベンチマークを行いましたか。
SQL Serverの動作が変更された理由はわかりません（そして、ストレージスイッチの前に発生したという証拠があります）が、ユーザーDBの間接チェックポイントを有効にすると問題が修正されました。