小编ale*_*x.p的帖子

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

使用带有混合 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;
Run Code Online (Sandbox Code Playgroud)

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

根据正常运行时间绘制的同步时间

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

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

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

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

同步时间根据正常运行时间绘制,放大

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

linux filesystems ubuntu kernel linux-kernel

9
推荐指数
1
解决办法
2553
查看次数

标签 统计

filesystems ×1

kernel ×1

linux ×1

linux-kernel ×1

ubuntu ×1