因此,我们使用数据库服务器的主力已经有 7 年多了,去年我们开始逐步使用一台新服务器,它在各方面都本质上更好,一次转换一个数据库。特别是有一个数据库我们转移到了新服务器,但情况变得很糟糕......
即使在中低负载下,查询也会开始超时,该数据库和其他已转换的数据库的性能几乎在各个方面都明显变慢,直到我们转换回原始服务器。一旦我们这样做了,新服务器上的性能就稳定下来,并且问题数据库在原始服务器上也很好。
一些具体细节会有所帮助!
我们当前(老化)服务器的规格:
- 戴尔 Poweredge T640
- 双 Intel Xeon Gold 5120 处理器(2.20GHz,共 56 个核心)
- 512 GB 内存
- 用于 C(操作系统)的 NVMe RAID 1、用于 D(SQL 数据)的 HDD RAID 10 [8 个磁盘]、用于 L(SQL 日志)的 SSD RAID 1、用于 T(临时数据库)的 SSD RAID 1
- Windows Server 2016 数据中心
- SQL Server 2019 企业版
我们新服务器的规格:
- 戴尔 PowerEdge R7515
- 单个 AMD EPYC 7H12 处理器(2.6GHz,共 64 核)
- 1024 GB 内存
- 适用于 C(操作系统)的 NVMe RAID 1、适用于 D(SQL 数据)的 SSD RAID 10 [10 个磁盘]、适用于 L(SQL 日志)的 SSD RAID 1、适用于 T(临时数据库)的 NVMe RAID 1
- Windows Server 2022 标准版
- SQL Server 2019 企业版
SQL 服务器配置
服务器配置几乎相同,除了由于硬件差异(最大 RAM)而有意义的地方。以下是截图:
*新服务器上未启用启用包含的数据库,但是,我们不使用此功能。
**在评论开始之前,我意识到 CTFP 太离谱了,那完全是另一个蜡球。
特别是,在审查我们的监控工具时,我们在比较从 sys.dm_os_performance_counters 获得的以下指标时注意到不成比例的值:
- 交易
- 锁定请求/秒
- 锁定超时/秒
- 平均锁存等待时间(毫秒)
如果有帮助的话,很乐意提供更多详细信息/图表。
所讨论的数据库大小适中,但对我们来说很大(120 GB),但 OLTP 应用程序中有许多活跃的写入者。特别是这个数据库涉及很多页面拆分。
从学术上讲,新服务器的一切都应该能够处理旧服务器的负载,然后是一些。
所有这些信息都是为了问这些问题:
- AMD 处理器与 Intel 处理器上的锁、闩锁或页面分割的处理方式是否存在差异?
- 单套接字与多套接字上的锁、闩锁或页面分割的处理方式是否存在差异?
- 是否有任何 SQL 数据结构在服务器之间可能表现不同?(这是我们使用列存储索引、过滤索引和其他一些更新/奇特的结构来帮助加快速度的唯一数据库)
- 是否还有其他因素会导致数据库在服务器与服务器之间的行为如此不同?
预先感谢您加入我的疯狂!
更新1
我们每晚运行 Ola Hallengren 令人惊叹的SQL Server 索引和统计维护脚本,以 5% 碎片重新组织每个表,以 30% 碎片重建并更新 INDEX 统计信息。这是由 SQL 代理在每台服务器上运行的,没有错误。
更新2
在花了一些时间建立在不影响客户的情况下复制我们设置的负载的方法之后,我们开始测试各种理论。获胜者是@StrayCatDBA,他通过电源设置调用了它。平衡的电源选项最终停放了我们的许多核心,服务器从未承受足够的负载来克服这种限制,但这足以驱动服务器挣扎以影响工作负载。
我感谢所有花时间插话的人。有些反馈在短期内很有帮助,有些反馈有助于开始重构我们一些更“激进”的查询(以及补偿所需的实践) 。
确认电源设置已设置为“高性能”,尤其是在具有大量 CPU 的计算机上。
“平衡”电源设置将降低 CPU 的性能以节省能源,并且理论上在负载情况下不会降低 CPU 的性能。在 64 个 CPU 的机器上,10 个 CPU 在 100% 时仅占总负载的 15% 左右,这可能不足以取消限制。
这种行为会导致在非常低的负载下单个查询的性能非常糟糕。