web-dev-qa-db-ja.com

SQL Server 2012 Standardで使用するメモリが多すぎる

過去数か月間、RAM=サーバーで最大190GBを使用してSQL Server 2012 Standardエディションをインストールしました（冗談ではありません）。約3〜4日ごと結局、SQL Serverサービスを再起動しなければならず、サーバーが応答しなくなってしまいます。

RAM01

ご覧のとおり、SQL ServerはSSMS内で最大64000 MBに設定されています。ただし、標準エディションであるにもかかわらず、ライセンスは64 GBに制限されているはずです。

サーバーに関するいくつかの詳細：

これは、8個のコア（ハイパースレッディングを備えた16個）、192GBのRAMインストール済み、およびローカルSSDストレージを備えた物理的なボックスです。多くのRAM SQL Server 2012の複数のインスタンスのインストールと、カスタムアプリ用のMySQLのインストールがあった可能性があるため、Standard Editionは、Windows 2012 R1で完全に最新の状態で実行されています。

現在、SQL Server 2012の1つのインスタンス（バージョン11.5.5548、つまりSP2およびCU2）がインストールおよび実行されており、SSRSがインストールされてローカルDBにアクセスするために使用され、MySQLがインストールされていますが使用されていません。データベースは、複数のSharepoint Foundationサイト、古いERPシステムの12GBデータウェアハウス、そして最後にメインのERP Dynamics AXデータベースの80GBコピーです。最大のSharepoint DBは29GBのドキュメントリポジトリです。

私はMicrosoftでチケットを開きました。彼らが推奨する2つのオプションは、Enterpriseエディション（$ 100,000 US）にアップグレードするか、SharePointクエリをそのまま使用してデフォルトの調整に関するプレミアチケットを開くことです。

誰かアイデアはありますか？

編集1以下は、リクエストごとの最大サーバーメモリの結果です。

RunningRAM2

編集2これがexec sp_configure 'max server memory (MB)'の結果です。

name                    minimum  maximum        config_value    run_value
max server memory (MB)  128      2147483647     64000           64000

編集3SQL Serverのエディションとバージョン情報

ServerEdition               ProductVersion                              O.S.
Standard Edition (64-bit)   SQL Server 2012 + SP2 + (Build11.0.5548.0)  Windows NT 6.2 <X64> (Build 9200: )

編集4リンクサーバーとperfmon情報

  • リンクサーバー

3つのリンクサーバーがあり、そのうちの2つは「Microsoft OLE SQL ServerのDBプロバイダー」を使用しています。もう1つは「Microsoft OLE ODBC Drivers "、およびそのODBC接続は、MySQL 64ビット5.2aドライバを使用しています。

  • Perfmonターゲットサーバー情報は65,539,008KBです。合計サーバーメモリは現在39,017,864KBです（サービスは今朝再開されました）。

編集4Thomas Stringerからの要求に対するDBCCメモリテキストダンプ。

現在、DBは素晴らしい反応を示しています。私は今DBCCを投稿しており、180 GBを超えたら4日以内に追加する予定です。時計仕掛けのようなものです。

DBCCMemory出力10-31-2014

編集5Shankyからのリクエスト

Memory_usedby_Sqlserver_MB Locked_pages_used_Sqlserver_MB Total_VAS_in_MB      process_physical_memory_low process_virtual_memory_low
-------------------------- ------------------------------ -------------------- --------------------------- --------------------------
78636                      0                              8388607              0                           0

編集6今朝、SQLはRAMのゴブを使用しており、応答が非常に遅いです（私もリモートからSSMSにログインします）幸い、SSMSはサーバー上でまだ開いており、要求されたクエリを実行できます。

これはクエリの結果です "

select (physical_memory_in_use_kb/1024)Memory_usedby_Sqlserver_MB, 

(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB, 

(total_virtual_address_space_kb/1024 )Total_VAS_in_MB, 

process_physical_memory_low, 

process_virtual_memory_low from sys. dm_os_process_memory

：

Memory_usedby_Sqlserver_MB  Locked_pages_used_Sqlserver_MB  Total_VAS_in_MB process_physical_memory_low process_virtual_memory_low
175901                      0                               8388607                   1                         0

あり ここ （ペーストビン）の結果

select type, sum(pages_in_bytes)/1024.0/1024.00 'Mem in MB',

 count (*) 'row count' from sys.dm_os_memory_objects group by type

結果（Pastebin）は here クエリの場合

select type, sum(pages_kb)/1024 pages_in_mb, 
sum(virtual_memory_reserved_kb)/1024 as virtual_memory_reserved_MB,
Sum(virtual_memory_committed_kb)/1024 as virtual_memory_committed_MB from `sys.dm_os_memory_clerks group by type order by pages_in_mb desc`

更新されたdbcc memorystatusは here にあります。これは20分以上実行されており、まだ完了していません。 「OBJECTSTORE_XACT_CACHE」に引っかかっているようです。

編集7DBCC MemoryStatusを実行しただけで、1秒足らずで戻ってきました。読める ここ

sql-serversql-server-2012memory
4
Mark House

DBCC MEMORYSTATUS（または他のクエリ）が現時点で明らかになっているとは思いません（他の人の考えを知らない）。もう1つだけ実行するようにお願いします。

dbcc traceon(3654, -1)
go
waitfor delay '00:05:00'
go
select top 20 memory_object_address, source_file, sum(size_in_bytes) as total_bytes
from sys.dm_os_memory_allocations
group by memory_object_address, source_file
order by total_bytes desc
go
dbcc traceoff(3654, -1)
go

情報を収集するための時間を確保するために、私が遅延を組み込んだことがわかります。それが明らかにするものに応じて、私はあなたが選択に直面していると思います、調査または推測を続けます：

  1. sysinternalsツールなどのより高度なデバッグ手法を使用して、メモリリークをさらに掘り下げます Process Explorer ;プロセスsqlservr.exeを見つけて、メモリリークの証拠を探します。または、
  2. 私たちの本能とSQL Serverについて知っていることを使用して、これがMySQLリンクサーバーで最も可能性が高いと推測し、その結果に基づいて推測します。次にサービスを再起動するときに、この機能のビットを一時的に無効にします。たとえば、リンクサーバーを削除したり、それに依存するレポートを無効にしたりします。問題を監視します。問題が発生しない場合は、犯人の候補として適切です。新しいドライバーが利用可能だと思います（5.3.4？）、または、アプリケーションのこの部分をSSISジョブにリファクタリングして、たとえば、夜間に1回ローカルキャッシュを作成することを検討できます。問題が発生しない場合は、少なくともそれを除外します。

これはライブサーバーなので、デバッグオプションは少し限られていると思うので、いくつかのオプションを試してみるときがきたかもしれません。サーバーの応答を確認してください。

DBCC MEMORYSTATUSの使用に関しては、過去にこの手法である程度成功しました。たとえば、暴走するフルテキストクエリを特定したり、強制的なsp_xml_removedocumentなしでOPENXMLを使用したりします。

1
wBob