ZFS:如何降低频率或防止 txg_sync
ZFS: How to reduce frequency of or prevent txg_sync
我有一个小型家庭服务器 运行 Debian Buster,其中有一个带 RAID 的 ZFS 文件系统 (ZFS: Loaded module v0.7.12-2+deb10u2, ZFS pool version 5000, ZFS filesystem version 5
)。
由于有时几天不使用服务器,我配置了一个自动关机脚本,如果我的 2 个大 WD 红色硬盘处于待机状态超过 45 分钟(不是系统硬盘),它会关闭服务器。现在我发现服务器不再关闭,因为两个驱动器在再次激活之前仅处于待机状态几分钟。我用 iotop
进行了测试,发现 ZFS 使用命令 txg_sync
正在唤醒它们。即使没有其他进程在驱动器上写入或读取任何内容。
在切换到安装数据池的目录后,我还用 fatrace -c
进行了检查。当时没有输出,因为命令 txg_sync
弹出并唤醒驱动器。更新:似乎 fatrace 无法与 ZFS 一起正常工作。
我现在使用 iosnoop
from,现在知道 dm_crypt 正在定期写入我的磁盘。我的底层驱动器使用 LUKS 加密。
./iosnoop -d 8,16
Tracing block I/O. Ctrl-C to end.
COMM PID TYPE DEV BLOCK BYTES LATms
dmcrypt_writ 1895 W 8,16 2080476248 4096 6516.10
dmcrypt_writ 1895 W 8,16 3334728264 4096 6516.14
dmcrypt_writ 1895 W 8,16 2080429048 16384 0.16
dmcrypt_writ 1895 W 8,16 3334728272 20480 0.21
dmcrypt_writ 1895 W 8,16 2080476256 20480 0.16
dmcrypt_writ 1895 W 8,16 3328225336 16384 0.20
这是什么原因,我该如何防止这种情况发生?
https://github.com/openzfs/zfs/issues/8537#issuecomment-477361010
@niksfirefly if the pool is being written to then you should expect to see cpu and I/O by consumed by the txg_sync thread. How much will depend on your specific hardware, the pool configuration, which features/properties are enabled, and your workload. This may be normal for your circumstances.
也许这个 link 也有帮助:
https://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04
如何检查每个进程的磁盘 I/O 利用率:
cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3
Those fields are PID, command and cumulative IO-wait ticks. This will show your hot processes, though only if they are still running. (You probably want to ignore your filesystem journalling threads.)
关于 ZFS 的另一个说明。
我在 Manjaro 20210101 上使用内核 5.4,并且在过去几周 txg_sync 上负载很高。
根据/var/log/pacman.log
[2020-12-31T08:58:24+0100] [ALPM] upgraded zfs-utils (0.8.5-2 -> 2.0.0-2)
[2020-12-31T08:58:24+0100] [ALPM] upgraded linux54-zfs (0.8.5-10 -> 2.0.0-6)
从那时起,txg_sync进程也恢复了和平。
在 Debian 下,ZFS(及其版本)的使用肯定会有所不同。
我有一个小型家庭服务器 运行 Debian Buster,其中有一个带 RAID 的 ZFS 文件系统 (ZFS: Loaded module v0.7.12-2+deb10u2, ZFS pool version 5000, ZFS filesystem version 5
)。
由于有时几天不使用服务器,我配置了一个自动关机脚本,如果我的 2 个大 WD 红色硬盘处于待机状态超过 45 分钟(不是系统硬盘),它会关闭服务器。现在我发现服务器不再关闭,因为两个驱动器在再次激活之前仅处于待机状态几分钟。我用 iotop
进行了测试,发现 ZFS 使用命令 txg_sync
正在唤醒它们。即使没有其他进程在驱动器上写入或读取任何内容。
在切换到安装数据池的目录后,我还用 fatrace -c
进行了检查。当时没有输出,因为命令 txg_sync
弹出并唤醒驱动器。更新:似乎 fatrace 无法与 ZFS 一起正常工作。
我现在使用 iosnoop
from,现在知道 dm_crypt 正在定期写入我的磁盘。我的底层驱动器使用 LUKS 加密。
./iosnoop -d 8,16
Tracing block I/O. Ctrl-C to end.
COMM PID TYPE DEV BLOCK BYTES LATms
dmcrypt_writ 1895 W 8,16 2080476248 4096 6516.10
dmcrypt_writ 1895 W 8,16 3334728264 4096 6516.14
dmcrypt_writ 1895 W 8,16 2080429048 16384 0.16
dmcrypt_writ 1895 W 8,16 3334728272 20480 0.21
dmcrypt_writ 1895 W 8,16 2080476256 20480 0.16
dmcrypt_writ 1895 W 8,16 3328225336 16384 0.20
这是什么原因,我该如何防止这种情况发生?
https://github.com/openzfs/zfs/issues/8537#issuecomment-477361010
@niksfirefly if the pool is being written to then you should expect to see cpu and I/O by consumed by the txg_sync thread. How much will depend on your specific hardware, the pool configuration, which features/properties are enabled, and your workload. This may be normal for your circumstances.
也许这个 link 也有帮助: https://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04
如何检查每个进程的磁盘 I/O 利用率:
cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3
Those fields are PID, command and cumulative IO-wait ticks. This will show your hot processes, though only if they are still running. (You probably want to ignore your filesystem journalling threads.)
关于 ZFS 的另一个说明。 我在 Manjaro 20210101 上使用内核 5.4,并且在过去几周 txg_sync 上负载很高。
根据/var/log/pacman.log
[2020-12-31T08:58:24+0100] [ALPM] upgraded zfs-utils (0.8.5-2 -> 2.0.0-2) [2020-12-31T08:58:24+0100] [ALPM] upgraded linux54-zfs (0.8.5-10 -> 2.0.0-6)
从那时起,txg_sync进程也恢复了和平。
在 Debian 下,ZFS(及其版本)的使用肯定会有所不同。