OLTP 系统上的 writelog 等待时间长，SSD 存储速度快，日志刷新慢

Question

我们最近从 SQL Server 2008 升级到新服务器并升级到 sql server 2016 (SP1 CU3)

新服务器硬件 hp proliant 580G8，4 插槽英特尔至强 E7 处理器，总共 60 个内核，640GB 内存，8 个英特尔 SSD S3700 Raid 10，本地

环境是一个繁忙的 OLTP 系统，每秒大约有 3K 批请求，主要是插入和较小程度的更新。作为 OLTP 系统，主要有 1 个插入/事务，因此有很多事务提交。有一些用于系统目的的报告查询（队列阅读器、监控等）

问题是日志刷新性能很慢，我们得到了 writelog 等待。我已经测试了 I/O，它可以在 4k 随机写入测试中管理超过 100K iops/sec，顺序写入高达 2500MB/sec

数据库兼容级别 = 130（sql server 2016）

间接检查点 = on,

甚低频计数 = 80-120

处理器 CPU 使用率为 3%-8%，平均为 5%，运行日志备份时最大低于 10%（压缩备份）总信号时间/总等待时间 = 6% - 94% 资源等待时间

内存 PLE 将每秒滴答一次，目前代表 584000 秒，可观察到的页面交换很少（页/秒）

这是我发现的真正问题

“日志刷新/秒”= 1000-2000/秒

“日志刷新等待时间”= 1000-4000 毫秒/秒

“日志刷新写入时间”= 0-1 毫秒/秒，峰值为 10-15 毫秒/秒

“平均磁盘秒/写入”= 0

“当前磁盘队列”= 0（每隔几分钟峰值为 2）

“磁盘空闲时间”= 90%-100%

所以似乎有问题，因为 sql server 无法使用 SSD 阵列提供的超低延迟......

我试图从 cpu 关联掩码禁用日志写入器线程，chris adkin 在他的博客中写道但没有成功，还使用扩展事件来监视日志刷新，并看到单个日志刷新发生了多次等待。

我不知道这个问题是否存在于以前的服务器上，因为在那个平台上 I/O 有点问题，而且“日志刷新写入时间”要高得多......

所以你有没有在现场看到这个问题，从现在开始的解决方案是什么谢谢

Answer 1

（不是答案，但注释不允许使用代码。）

您没有 AlwaysOn AG 或镜子，对吗？

在用户数据库中测试您的最大日志刷新率，如下所示：

create table t(id int)
go
set nocount on
declare @i int = 0
while @i < 100000
begin
  insert into t(id) values (@i);
  set @i = @i + 1;
end