目前,我遇到了 SaaS 应用程序的一些数据库性能问题。白天,RESOURCE_SEMAPHORE 等待统计数据会猛增 30 到 60 秒,持续 1 到 2 分钟。在此期间,我还从我们的服务器收到一封或多封严重性为 17 的警报邮件,其中包含警告“资源池‘内部’中没有足够的系统内存来运行此查询。”
我们已经解决了具有大量内存授予的效率最低的查询(1.5 到 2.5 GB 授予,但使用率仅为 5% 或更少)。为了精确定位这些查询,我们使用了 Brent Ozar 的 sp_BlitzCache。不幸的是,这些更改后仍然出现性能问题。
请注意,此时我们有一个代理作业每 5 分钟运行一次 DBCC FREEPROCCACHE。这样做会使问题更加分散。将此作业更改为每半小时运行一次似乎会使问题变得更糟。当然,运行此作业还有其他影响,例如更高的编译/秒和更高的 CPU 利用率,但目前这是一个“两全其美”的解决方案。
恐怕内存压力问题是由于服务器配置的 RAM 内存不足造成的?这个假设是正确的还是这些问题是由其他原因造成的?
服务器统计
- SQL Server 2022 (16.0.4085.2)
- 6 个逻辑处理器(最大 DOP = 4)
- 16 GB 总 RAM,配置为 SQL Server 的最大服务器内存为 14 GB,操作系统的最大服务器内存为 2 GB
- 共有1381个数据库
- 数据库总大小:302GB
这很可能是您当前遇到的主要问题,但对于 6 核和 1381 个数据库,您还会遇到 CPU 问题,只是内存问题在环境中更为突出。
只要大声说出来可能会有所帮助。假设每个在线数据库都需要 SQL Server 进行一些基本级别的设置,假设需要 4 MB 内存(这不是实际值,它会根据不同的设置和版本而变化)。有 1381 个数据库,因此只要使数据库联机而不执行任何操作,您就会占用 5.5 GB 的内存用于控制和分配结构。这不计算 cpu 需求 - 例如恢复线程、GC 线程、CLR 线程、日志写入器线程、IOCP 等,全部位于 6 个 cpu 上。在考虑到 Windows 和加载到服务器上的任何其他服务(反*任何废话、50 个不同的代理等)之后,这为工作负载留下了非常少量的内存或 CPU。
每个 CPU 实质上有 230 个数据库,每个数据库有 11 MB。对我来说,作为服务器,这已经是严重超额订阅了。您需要多少尚不清楚,但对于 1381 个数据库(除非是其中 99% 几乎每天都闲置的托管情况),我会以两位数的 CPU 和三位数的内存作为起点。