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

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

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

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

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

分析にはRedGate SQL Monitorを使用します。以下は、過去18日間の履歴ですTotal Server Memory。ご覧のように、メモリ使用率は、4月上旬に300 MBの単一の増加を除いて、完全に停滞したままです。

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

runningの出力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ドライブに配置すると、スペースが不足したときにサーバーがクラッシュするリスクがあります。

  • model-モデルデータベースのCドライブにファイルがあります。システムデータベースをCドライブに配置すると、スペースが不足したときにサーバーがクラッシュするリスクがあります。

  • msdb-msdbデータベースのCドライブにファイルがあります。システムデータベースをCドライブに配置すると、スペースが不足したときにサーバーがクラッシュするリスクがあります。

優先度200：情報：

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

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

• TraceFlag On

  • トレースフラグ1118はグローバルに有効になっています。

  • トレースフラグ1222はグローバルに有効になっています。

  • トレースフラグ2371はグローバルに有効になっています。

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

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

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

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

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

• max degree of parallelism-この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 PMから2018年4月16日11:13 AMまでの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 Config

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

  • ノード：1状態：オフラインオンラインスケジューラー：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 AM スタートアップの種類：自動、現在実行中。

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

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

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

• 仮想サーバー-タイプ：（ハイパーバイザー）

• Windowsバージョン-かなりモダンなバージョンのWindows：Server 2012R2時代、バージョン6.3を実行しています

優先度254：実行日：

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

一部のCPUノードやメモリノードがオフラインになるように仮想CPUを構成したに違いありません。

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

sp_Blitz @CheckServerInfo = 1;

CPUやメモリノードがオフラインであることに関する警告を探します。SQL Server Standard Editionは最初の4つのCPUソケットのみを認識し、6つのデュアルコアCPUのようにVMを構成している場合があります。最終的に、Enterprise Editionの20コア制限により、表示可能なメモリ量が制限されるのと同様の問題が発生します。

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

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

更新2018/04/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コアすべてで動作するようになります。

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

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

1. VMwareクラスターのvSphere Web Clientにログインし、SQL Serverをホストする仮想マシンを参照します。CPUとメモリの構成を調整するには、VMをオフラインにする必要があります。

2. プライマリペイン内で、に移動しConfigure > VM hardware、Edit右上隅のボタンをクリックします。コンテキストメニューが開きますEdit Settings。参考のため、以下の画像は誤った構成です。にCores per Socket設定していることに注意してください1。SQL Server Standard Editionの制限を考えると、これは不適切な構成です。

   

3. 修正は、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のほとんどすべてのオンプレミス仮想化に適用できます。

ブレントの投稿後、私が調査を通じてまとめたリソースをいくつか紹介します。

• 大規模データベースの仮想化-VMware CPU容量計画

• 仮想マシンvCPUおよびvNUMAの権利化–経験則

• vSphere 6.5の仮想NUMAトポロジからのソケットごとのコアの分離

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

また、MSDNによると、SQL Serverの標準は64GBのRAMに制限されています。データベースを複数のインスタンスに分割することでこれを「解決」しましたが、状況によっては許可されない場合があります。

Hmm 2016には128GBの制限があるようですが、インスタンス分割はまだオプションかもしれません。