SQL Server 2016(SP2-CU3)内存占用异常求助

首先得明确一个核心差异：任务管理器统计的是整个Windows系统的内存使用，而sys.dm_os_sys_info里的committed_GB只是SQL Server内部已提交的核心内存（主要是缓冲池+部分组件），两者统计范围完全不同。这227GB的“缺失”内存，大概率来自以下几个方向，咱们一步步定位：

1. 先确认SQL Server进程的真实内存占用 #

别只依赖sys.dm_os_sys_info，用sys.dm_os_process_memory能更准确反映SQL Server进程的总内存开销，运行这个查询：

SELECT 
    physical_memory_in_use_kb/1024/1024 AS sql_physical_memory_used_GB,
    locked_page_allocations_kb/1024/1024 AS sql_locked_pages_GB,
    committed_kb/1024/1024 AS sql_committed_GB
FROM sys.dm_os_process_memory WITH (NOLOCK);

• sql_physical_memory_used_GB是SQL Server实际占用的物理内存（涵盖缓冲池、CLR、内存OLTP、查询执行内存等所有组件），这个数值应该和任务管理器里sqlservr.exe的「内存（工作集）」接近。
• 如果这个数值远大于796GB，说明SQL Server内部还有大量内存没被sys.dm_os_sys_info的committed_GB统计到，接下来就深入查内部组件。

2. 排查系统层面的非SQL内存消耗 #

任务管理器显示的1TB已用内存，除了SQL Server，还包含：

• 其他进程：打开任务管理器的「详细信息」标签，按「内存（工作集）」排序，看看有没有杀毒软件、备份工具、监控服务、其他数据库/应用进程占用了大量内存（比如几百GB级别的）。
• Windows系统缓存：Windows会把空闲内存用来缓存文件数据，这部分会被算在“已用内存”里，但不属于任何进程。你可以用这个查询查看系统缓存大小：

  SELECT system_cache_kb/1024/1024 AS system_cache_GB
  FROM sys.dm_os_sys_memory WITH (NOLOCK);
  

  如果这个数值接近227GB，那就是系统缓存占了这部分内存——这是Windows的正常优化行为，当其他进程需要内存时，系统会自动释放缓存。

3. 分析SQL Server内部的内存分配细节 #

如果SQL Server进程的实际内存占用确实远大于796GB，就需要查内部哪些组件在消耗内存，运行这个查询看各个内存 clerk 的占用情况：

SELECT 
    type,
    SUM(pages_kb)/1024/1024 AS memory_GB
FROM sys.dm_os_memory_clerks WITH (NOLOCK)
GROUP BY type
ORDER BY memory_GB DESC;

重点关注这些类型：

• MEMORYCLERK_SQLBUFFERPOOL：缓冲池（数据库缓存），正常情况下这部分占比最大。
• MEMORYCLERK_XTP：内存中OLTP组件，如果你的数据库用了内存优化表，这部分内存不会计入sys.dm_os_sys_info的committed_GB，是单独分配的。
• MEMORYCLERK_SQLQUERYEXEC：查询执行内存（排序、哈希操作等），如果有长时间运行的大查询，可能会占用大量内存。
• MEMORYCLERK_SQLCLR：CLR程序集占用的内存，比如自定义的CLR函数/存储过程。

4. 其他潜在排查点 #

• 多实例情况：检查服务器上是否有多个SQL Server实例运行，每个实例都会占用内存，需要分别连接每个实例查询内存使用情况。
• 锁定页内存权限：如果SQL Server服务账号有「锁定页内存」权限，SQL Server会把内存锁定在物理内存中，不会被分页到磁盘。这部分内存依然会被任务管理器统计，但sys.dm_os_sys_info的统计可能有延迟，用sys.dm_os_process_memory的locked_page_allocations_kb可以查看这部分大小。
• 内存泄漏：如果前面的排查都没找到原因，可能是SQL Server的bug、第三方扩展存储过程或CLR程序导致的内存泄漏。这种情况可以跟踪sys.dm_os_memory_clerks的内存变化，或者查看SQL Server错误日志是否有相关警告，必要时可以升级到更高的CU（你当前是SP2-CU3，后续多个CU修复了内存泄漏问题）。

内容的提问来源于stack exchange，提问作者Ильдар