正常运行 30 分钟后，对同步/fsync 的调用变慢

Question

使用带有混合 SSD 的Ubuntu 14.04 正常运行 30 分钟后，我看到许多进程使用iotop. 这是在磁盘写入期间，例如，如果我在 gedit 中打开和关闭一个空文件，由于 dconf 写入设置，它可能需要 2 秒才能关闭，这会以类似的方式影响其他应用程序；非常严重地减慢整个系统的速度。

使用 strace 我设法将其追溯到 fsync 调用，并从那里设法使用 sync 命令重现它。

所以总结一下，简单地sync从终端重复运行可能需要 1 - 2 秒的时间，但只有在 30 分钟的正常运行时间之后。

为了证明这一点，我制作了一个脚本，以秒为单位输出正常运行时间与执行同步所需的时间，并每秒运行一次：

while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;

我运行了上面的脚本，等了大约一个小时（系统处于空闲状态），然后在 gnuplot 中绘制结果（y = 执行同步的时间，x = 以秒为单位的正常运行时间）：

图表峰值的时间点在 1780 年左右（1780/60 = 大约 30 分钟）。

除了脚本，此时不应向磁盘写入任何内容，因此在第一次同步之后页面缓存中应该几乎没有任何内容，每个后续同步将准确写入正在写入脚本的内容，大约为 100 字节或所以。

重新启动后此问题仍然存在；例如 - 如果我等待 30 分钟减速然后重新启动，减速仍然存在。如果我关闭电源然后重新启动问题会消失，直到 30 分钟后。

另一个好奇心是，当我检查上图并放大正在发生减速的区域时，我得到了这个：

波峰和波谷重复——这几乎每 10 秒从波谷到波谷发生一次，而且波峰在下降时也会扭结。

在减速之前，我还运行了 hdparm 测试（hdparm -t /dev/sda和hdparm -T /dev/sda）：

/dev/sda:
Timing cached reads:   23778 MB in  2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in  3.01 seconds = 105.63 MB/sec

在放缓期间：

/dev/sda:
 Timing cached reads:     2 MB in  2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in  3.01 seconds =  99.54 MB/sec

显示实际磁盘读取没有受到影响，但缓存读取受到影响，这是否意味着这与系统总线有关，而与 HD 无关？

这是我尝试过的解决方案：

• 更改 HD 的降速设置可能是 HD 进入省电模式：

  hdparm /dev/sda -S252 #(set it to 5 hours before spindown)
  

• 将文件系统的日志类型更改为回写而不是有序，以便我们获得性能改进 - 这并不能解决问题，因为它不能解释 30 分钟无减速的正常运行时间。

• 禁用 CRON，因为它似乎在 30 分钟后发生。

• CPU 使用率很好并且完全空闲，因此不能责怪任何进程，但是我尝试关闭包括会话管理器 (lightdm) 在内的所有服务，这没有任何作用，因为我认为问题级别较低。

• 分析 30 分钟后进入的任何新进程表明没有任何变化 - 我前后对比了 PS 的输出，没有区别。

这仅在大约 2 周前开始发生，当时没有安装任何内容，也没有进行任何更新。我认为这个问题的级别要低得多，所以我真的很感激这里的一些帮助，因为我一无所知，即使将我指向正确的方向也会有所帮助 - 例如，有没有办法检查页面缓存中正在刷新的内容？

有问题的磁盘上启用了写缓存，我也尝试过禁用写屏障。HD 上的 SMART 数据表明 HD 本身没有问题，但我怀疑是 HD 做了一些神秘的事情，因为它在重新启动后仍然存在。

编辑：

我弄完了 ：

watch -n 1 cat /proc/meminfo

...查看内存如何变化，特别是查看脏行和我认为是 HD 磁盘缓冲区的回写行。它们大部分都保持为零，最高可能是 300kb。调用 sync 将这些按预期刷新回 0，但在减速期间调用 sync 当磁盘缓冲区中有零脏页和零 kb 时仍会锁定 IO。如果没有什么可以刷新页面缓存和写入缓存，同步还能做什么？

Answer 1

这些症状与大部分饱和的 IO 系统非常一致，但是在很大程度上排除了来自操作系统/用户空间端的 IO 负载，另一种可能性是驱动器在自身上运行自检，其中可能包括从所有扇区读取。这应该可以从 smartctl 查询/调整（至少有一个地方是 smartctl -c 用于查询）。

至于为什么现在来来去去又突然开始：

• 驱动器已过了其生命周期的某个阶段（写入的扇区数、旋转时间等），并且驱动器上的固件已触发其中一项扫描
• 我相信这也可以通过 smartctl 触发，因此可能是某些自动化过程触发了它
• 触发其中一个扫描并将其标记为正在进行或已开始，当驱动器开启一段时间后，它会从头开始重新触发或从中断处恢复