SQL Serverの「合計サーバーメモリ」の消費量は数か月間停滞しており、64 GB以上が利用可能

Question

SQL Server 2016 Standard Edition 64ビットが割り当てられたメモリの合計のちょうど半分（128GBのうち64GB）を制限しているように見えるという奇妙な問題に遭遇しました。

_@@VERSION_の出力は次のとおりです。

Microsoft SQL Server 2016（SP1-CU7-GDR）（KB4057119）-13.0.4466.4（X64）2017年12月22日11:25:00 Copyright（c）Microsoft Corporation Standard Edition（64-bit）on Windows Server 2012 R2 Datacenter 6.3（ビルド9600：）（ハイパーバイザー）

_sys.dm_os_process_memory_の出力は次のとおりです。

_sys.dm_os_performance_counters_をクエリすると、Target Server Memory (KB)が_131072000_にあり、Total Server Memory (KB)が_65308016_の半分未満にあることがわかります。ほとんどのシナリオでは、SQL Serverがそれ自体に追加のメモリを割り当てる必要があるとまだ判断していないため、これは正常な動作であると理解します。

ただし、2か月以上、約64 GBで「スタック」しています。この期間中に、一部のデータベースでメモリを大量に消費する操作を大量に実行し、インスタンスにさらに40近くのデータベースを追加しました。合計292のデータベースがあり、それぞれに256 GBの自動拡張レートで4 GBの事前割り当てされたデータファイルと128 MBの自動拡張レートで2 GBのログファイルが割り当てられています。フルバックアップを毎晩12:00 AMに実行し、月曜日から金曜日の午前6時から午後8時までトランザクションログのバックアップを15分間隔で開始します。これらのデータベースは全体的なスループットが比較的低いですが、SQL Serverが新しいデータベースの追加、通常のクエリの実行、およびメモリを通じて自然に_Target Server Memory_に近づいていないため、何かがおかしいのではないかと疑っています。実行された集中的なETLパイプライン。

SQL Serverインスタンス自体は、12 CPU、144 GBのメモリ（SQL Serverに対して128 GB、Windows用に16 GBを予約）、および15KのvSANの上に配置された合計4つの仮想ディスクを備えた仮想化（VMware）Windows Server 2012R2サーバーの上にありますSASドライブ。 Windowsは、32 GBのページファイルを持つ64 GB C：ディスク上に自然に配置されます。データファイルは2TB D：ディスク上にあり、ログファイルは2TB L：ディスクの上にあり、tempdbは256GB T：ディスク上にあり、8x16GBファイルがあり、自動拡張はありません。

サーバー上でMSSQLSERVER以外にSQL Serverのインスタンスが実行されていないことを確認しました。

このサーバーは完全にSQL Serverインスタンス専用であり、メモリを消費する可能性のある他のアプリケーションやサービスは実行されていません。

私はRedGate SQLモニターを分析に利用していますが、以下は過去18日間の_Total Server Memory_の履歴です。ご覧のように、メモリ使用率は、4月上旬に最大300MB増加したことを除けば、完全に停滞しています。

これの原因は何でしょうか？ SQL Serverがそれに割り当てられた追加の64 GB以上のメモリを使用したくない理由を判断するために、何を詳しく調べることができますか？

_sp_Blitz_の実行の出力：

_sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1; _
優先度50：パフォーマンス：

オフラインのCPUスケジューラ-一部のCPUコアは、アフィニティマスキングまたはライセンスの問題のため、SQL Serverにアクセスできません。

オフラインのメモリノード-アフィニティマスキングまたはライセンスの問題により、一部のメモリが使用できない場合があります。

優先度50：信頼性：

リモートDAC無効-専用管理接続（DAC）へのリモートアクセスが有効になっていません。 DACを使用すると、SQL Serverが応答しない場合のリモートトラブルシューティングがはるかに簡単になります。

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

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

サーバートリガーが有効

サーバートリガー[RG_SQLLighthouse_DDLTrigger]が有効になっています。そのトリガーが何をしているのかを理解していることを確認してください-トリガーが少ないほど良いです。

サーバートリガー[SSMSRemoteBlock]が有効になっています。そのトリガーが何をしているのかを理解していることを確認してください-トリガーが少ないほど良いです。

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

結合ヒントを強制するクエリ-結合ヒントの1480回のインスタンスが再起動後に記録されました。これは、クエリがSQL Serverオプティマイザを攻撃していることを意味します。クエリが何をしているのかわからない場合は、害を及ぼすだけではありません。これは、DBAのチューニング作業が機能しない理由も説明できます。

注文のヒントを強制するクエリ-注文のヒントの2153回のインスタンスが再起動後に記録されました。これは、クエリがSQL Serverオプティマイザを攻撃していることを意味します。クエリが何をしているのかわからない場合は、害を及ぼすだけではありません。これは、DBAのチューニング作業が機能しない理由も説明できます。

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

Cドライブのシステムデータベース

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

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

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

優先度200：情報提供：

同時に開始するエージェントジョブ-複数のSQL Serverエージェントジョブが同時に開始するように構成されています。詳細なスケジュールリストについては、URLのクエリを参照してください。

マスターデータベースマスターのテーブル-マスターデータベースのCommandLogテーブルは、2017年7月30日午後5時22分にエンドユーザーによって作成されました。マスターデータベースのテーブルは、災害発生時に復元されない場合があります。

TraceFlag On

トレースフラグ1118はグローバルに有効になります。

トレースフラグ1222はグローバルに有効です。

トレースフラグ2371はグローバルに有効です。

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

エージェントXP-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。

backup checksum default-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。

バックアップ圧縮のデフォルト-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。

並列処理のコストしきい値-このsp_configureオプションが変更されました。デフォルト値は5で、48に設定されています。

最大並列度-このsp_configureオプションが変更されました。デフォルト値は0で、12に設定されています。

最大サーバーメモリ（MB）-このsp_configureオプションが変更されました。デフォルト値は2147483647で、128000に設定されています。

アドホックワークロードの最適化-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。

詳細オプションを表示-このsp_configureオプションは変更されました。デフォルト値は0で、1に設定されています。

xp_cmdshell-このsp_configureオプションが変更されました。デフォルト値は0で、1に設定されています。

優先度200：信頼性：

マスターの拡張ストアドプロシージャ

master-[sqbdata]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbdir]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbmemory]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbstatus]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbtest]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbtestcancel]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbteststatus]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqbutility]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

master-[sqlbackup]拡張ストアドプロシージャはmasterデータベースにあります。 CLRが使用されている可能性があり、マスターデータベースをバックアップ/リカバリ計画の一部にする必要があります。

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

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

RedGate

RedGateMonitor

スナップショット分離が有効-このデータベース設定はデフォルトではありません。

RedGate

RedGateMonitor

優先度240：待機統計：

1-SOS_SCHEDULER_YIELD-1770.8時間の待機、1時間あたりの平均待機時間115.9分、100.0％の信号待機、1419212079待機タスク、4.5ミリ秒の平均待機時間。

優先度250：情報提供：

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

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

デフォルトのトレースの内容-デフォルトのトレースは、2018年4月14日の午後11時21分から2018年4月16日の午前11時13分の間に36時間のデータを保持します。デフォルトのトレースファイルは、C：\ Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Logにあります。

ドライブCスペース-Cドライブに196816.00MBの空き容量

ドライブDスペース-Eドライブに894823.00MBの空き容量

ドライブLスペース-Fドライブに1361367.00MBの空き容量

ドライブTスペース-Gドライブに114441.00MBの空き容量

ハードウェア-論理プロセッサ：12.物理メモリ：144GB。

ハードウェア-NUMA構成

ノード：0状態：ONLINEオンラインスケジューラ：4オフラインスケジューラ：2プロセッサグループ：0メモリノード：0メモリVAS予約済みGB：186

ノード：1状態：OFFLINEオンラインスケジューラー：0オフラインスケジューラー：6プロセッサーグループ：0メモリノード：0メモリVAS予約済みGB：186

ファイルの即時初期化が有効-サービスアカウントにはボリュームメンテナンスタスクの実行権限があります。

電源プラン-サーバーには2.60GHzのCPUが搭載されており、バランスの取れた電源モードになっています-ええと... CPUをフルスピードで実行したいですね。

サーバーの最終再起動-2018年3月9日7:27 AM

サーバー名-[編集済み]

サービス

サービス：SQL Server（MSSQLSERVER）は、サービスアカウントNT Service\MSSQLSERVERで実行されます。最終起動時間：2018年3月9日午前7:27。スタートアップの種類：自動、現在実行中。

サービス：SQL Serverエージェント（MSSQLSERVER）は、サービスアカウントLocalSystemで実行されます。最終起動時間：表示されません。起動タイプ：自動、現在実行中。

SQL Server最終再起動-2018年3月9日6:27 AM

SQL Serverサービス-バージョン：13.0.4466.4。パッチレベル：SP1。累積的な更新：CU7。エディション：スタンダードエディション（64ビット）。可用性グループの有効化：0。可用性グループマネージャーのステータス：2

仮想サーバー-タイプ：（HYPERVISOR）

Windowsバージョン-Windowsの最新バージョンを実行している：サーバー2012R2時代、バージョン6.3

優先度254：Rundate：

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

Brent Ozar · Accepted Answer

いくつかのCPUノードやメモリノードがオフラインになるように仮想CPUを構成したと思います。

ダウンロード sp_Blitz （免責事項：私はその無料のオープンソーススクリプトの作成者の1人です）、それを実行します。

sp_Blitz @CheckServerInfo = 1;

オフラインになっているCPUまたはメモリノード、あるいはその両方に関する警告を探します。 SQL Server Standard Editionは最初の4つのCPUソケットしか認識せず、VMを6つのデュアルコアCPUのようなものとして構成している可能性があります。最終的には Enterprise Editionの20コア制限により、表示されるメモリの量が制限されます。

ここでsp_Blitzの出力を共有する場合は、次のように実行してMarkdownに出力できます。Markdownにコピーして、質問に貼り付けます。

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

2018年4月16日更新-確認しました。sp_Blitz出力を添付しました（ありがとうございます）。CPUノードとメモリノードがあることを実際に示しています。オフライン。 VM=を構築した人は、12個のシングルコアCPUとして構成したため、SQL Server Standard Editionは最初の4つのソケット（コア）とそれに接続されたメモリのみを認識しています。

これを修正するには、VMをシャットダウンし、2ソケット、6コアのVMとして構成すると、SQL Server Standard Editionがすべてのコアとメモリを認識します。これにより、SOS_SCHEDULER_YIELDの待機も減少します。現在、SQL Serverは最初の4つのコアを処理していますが、それだけです。この修正後は、12コアすべてで動作するようになります。

PicoDeGallo · Answer

ブレント・オザールの行動計画の補遺として、結果を共有したいと思いました。ブレントが述べたように、VMware内では、仮想マシンを12個のシングルコアCPUで不適切に構成していました。これにより、SQL Serverから残りの8つのコアにアクセスできなくなり、その結果、元の質問で説明したメモリの問題が発生しました。 VMを適切に再構成するために、サービスをメンテナンスモードにしました。通常の方法でメモリが増加するだけでなく、ブレントも示唆したように、待機の数をSQL Serverの全体的なパフォーマンスが急上昇し、vNUMA構成は、ワークロードをスライスしている小さなコンポーネントになりました。

VMware vSphere 6.5を使用している可能性のあるユーザーのために、ブレントが説明したアクションアイテムを完了するための簡単な手順は次のとおりです。

VMwareクラスターのvSphere Webクライアントにログインし、SQL Serverをホストする仮想マシンを参照します。 CPUとメモリの構成を調整するには、VMをオフラインにする必要があります。
プライマリペイン内でConfigure > VM hardwareに移動し、右上隅のEditボタンをクリックします。 Edit Settingsを含むコンテキストメニューを開きます。参考までに、下の画像は正しくない構成です。 Cores per Socketを1に設定していることに注意してください。 SQL Server Standard Editionの制限を考えると、これは不適切な構成です。
修正は、Cores per Socket値を調整するだけの簡単なものです。この例では、6となるように2 Socketsに設定します。これにより、SQL Serverは12個のプロセッサすべてを利用できます。

重要な注意：Number of CoresまたはSocketsが奇数になる場所に値を設定しないでください。 NUMAはバランスが大好きであり、経験則では、2で割り切れる必要があります。たとえば、4コアから3ソケットへの構成は不均衡になります。実際、このタイプの構成でsp_Blitzを実行すると、これに関する警告が表示されます。

これについては、 VMware vSphereでのMicrosoft SQL Serverの設計（PDF警告）のセクション3.3で詳しく説明しています。ホワイトペーパーで概説されているプラクティスは、SQL Serverのほとんどすべてのオンプレミスの仮想化に適用できます。

以下は、ブレントの投稿後に私の調査を通じてまとめたいくつかのリソースです。

過去24時間のRedGate SQLモニターからのキャプチャを終了します。主な注意点は、CPU使用率と待機数です-昨日のピーク時間中に、CPUの使用と待機の競合が発生していました。この簡単な修正により、パフォーマンスが10倍に向上しました。ディスクI/Oも大幅に減少しました。これは見落とされがちな設定であり、仮想パフォーマンスを1桁向上させることができます。少なくとも、それは私たちのエンジニアと完全なd'ohの瞬間から見落とされていました。