每周六午夜左右，相关服务器会突然出现可用内存丢失的情况。大约 35-40 分钟后，可用内存会下降，直到操作系统无法运行并锁定。操作系统此时没有响应，直到服务器重新启动。
在资源耗尽期间，Windows 事件日志中会出现许多警报，各种进程抱怨它们资源不足。例如，您可以跟踪 SQL Server 的进展，因为越来越多的进程内存被调出。最终，日志条目在操作系统锁定时停止，下一个条目是在服务器重新启动后。
我检查了任务计划程序，没有发现星期六午夜运行的任何明显可能导致此问题的程序。
上周末，我运行了 Windows 性能监视器的计划任务，以跟踪和记录崩溃期间的以下参数：
总可用内存
页面文件字节数（按进程细分）
总页面文件字节数
私有字节数（按进程细分）
私有字节数（总计）
虚拟字节数（按进程细分）
虚拟字节数（总计）
工作集（按进程细分）
工作集（总计）
工作集 – 私有（按进程细分）
工作集 – 私有总计
处理器总使用量
日志中的总可用内存列显示从午夜开始明显下降，直到凌晨 12:40 左右可用内存为零。同样，您可以看到每个单独进程的工作集内存都在减少。但是，似乎没有明显的内存丢失罪魁祸首。我没有看到任何记录表明某个特定进程的内存使用量增加而其他所有进程的内存使用量都在下降。
这次我确实强制使用不可屏蔽中断，以便查看内存转储，但我只能找到一个包含很少有用信息的小型转储。我不确定这是由于当时页面文件的大小，还是由于资源耗尽而导致的，或者 Windows 自动删除了它。据我所知，这些设置是 Windows Server 2019 的默认设置。页面文件现在是 RAM 的大小（16GB），因此 Windows 可能更改了它（https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/automatic-memory-dump)，再进行一次 NMI 就会得到正确保存的内存转储。我下周一会再试一次。
我不确定如何才能最好地继续下去，并希望得到任何建议。例如，我是否遗漏了性能监视器日志中应该包含的参数？
谢谢。
答案1
问题 ：
- SQL 服务器是唯一安装的服务/应用程序吗？
- 该机器是否正在运行防病毒软件，是虚拟机吗？
- 这个 SQL Server 实例是单独的吗或者这台机器上还有其他 SQL Server 实例？
- 您是否将 SQL Server 使用的内存限制为 12 Gb？