SQL Server 2016 SE（AWS EC2 4核16GB）内存过高崩溃求助

这种周期性内存飙升到90%后服务崩溃的情况，在SQL Server部署中很常见，结合你在4核16GB AWS EC2实例的场景，我来帮你拆解排查步骤和解决方案：

一、先检查最关键的内存配置：Max Server Memory #

SQL Server默认会尽可能抢占系统内存（默认max server memory设为无限制），但16GB的实例必须给操作系统预留足够内存（至少2-4GB），否则OS内存耗尽会直接导致SQL服务挂掉。

查看当前配置： #

sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
sp_configure 'max server memory (MB)';
GO

如果返回的max值是2147483647（默认无限制），这就是核心问题之一。

调整合理的内存上限： #

给OS留3-4GB，所以设置SQL Server最大内存为12288MB（12GB）：

sp_configure 'max server memory (MB)', 12288;
RECONFIGURE;
GO

这个调整无需重启服务，立即生效，能先解决OS被内存吃光的问题。

二、排查SQL Server内部内存泄漏 #

如果已经设置了合理的max server memory，但内存还是持续上涨，那就要排查SQL内部的内存组件是否有泄漏：

查看内存占用Top组件： #

运行以下查询，按内存占用排序SQL Server的内存 clerks：

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

• MEMORYCLERK_SQLBUFFERPOOL是缓冲池，正常会占用大部分内存，只要不超过你设置的max server memory就没问题。
• 如果是MEMORYCLERK_SQLQUERYEXEC、MEMORYCLERK_SQLCLR或者其他非缓冲池组件持续增长且不回落，大概率是特定查询、CLR程序或者第三方工具导致的内存泄漏。

追踪耗内存的查询/会话： #

用以下查询找到当前占用内存最高的会话和对应的SQL语句：

SELECT 
    s.session_id,
    s.login_name,
    t.text AS query_text,
    SUM(gr.memory_usage_kb)/1024 AS memory_usage_mb
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
JOIN sys.dm_exec_query_memory_grants gr ON r.session_id = gr.session_id
GROUP BY s.session_id, s.login_name, t.text
ORDER BY memory_usage_mb DESC;

如果发现某个查询长期占用大量内存不释放，可能是查询本身有问题（比如没有索引、返回超大量数据），或者游标没有正确关闭。

三、检查系统日志与作业 #

查看SQL Server错误日志： #

在SQL Server Management Studio（SSMS）中，展开服务器 → 管理 → SQL Server日志，查看服务崩溃前的日志，找有没有17803（内存分配失败）、701（系统内存不足）这类错误，这些日志能直接定位崩溃原因。

检查周期性作业： #

你的问题是每7-8天出现，刚好对应每周一次的作业周期，比如索引重建、全量备份、ETL同步任务。查看SQL Server代理的作业历史，看这些作业的运行时间是否和内存上升的时间点匹配：

• 有些索引重建作业如果处理超大量数据，可能会占用大量内存且无法及时释放；
• 备份作业如果用了COMPRESSION选项，也会额外消耗内存。

四、其他优化建议 #

• 安装最新累积更新（CU）：SQL Server 2016的早期版本存在一些内存泄漏的已知问题，微软后续的CU补丁已经修复了这些问题，建议升级到最新的CU版本。
• 检查连接泄漏：用SELECT login_name, COUNT(session_id) AS session_count FROM sys.dm_exec_sessions WHERE status = 'running' GROUP BY login_name查看有没有异常多的长期连接，某些应用程序如果没有正确关闭连接，会导致SQL Server持续为这些连接分配内存。

内容的提问来源于stack exchange，提问作者bhanu singh