![50TB 卷上的 zpool 导入需要很长时间:它在做什么?](https://linux22.com/image/533243/50TB%20%E5%8D%B7%E4%B8%8A%E7%9A%84%20zpool%20%E5%AF%BC%E5%85%A5%E9%9C%80%E8%A6%81%E5%BE%88%E9%95%BF%E6%97%B6%E9%97%B4%EF%BC%9A%E5%AE%83%E5%9C%A8%E5%81%9A%E4%BB%80%E4%B9%88%EF%BC%9F.png)
我们有一个由两个 OpenSolaris 2009.06 NFS 服务器管理的光纤通道 san。
- 服务器 1 管理 3 个小卷(300GB 15K RPM 驱动器)。运行良好。
- 服务器 2 正在管理 1 个大型卷,其中包含 32 个驱动器(2TB 7200 RPM 驱动器)RAID6。总大小为 50TB。
- 两台服务器都具有 Zpool 版本 14 和 ZFS 版本 3。
几个月前安装了 50TB 的服务器,运行良好。用户占用了 2TB。我做了一个小实验(创建了 1000 个文件系统,每个文件系统都有 24 个快照)。创建、使用快照访问文件系统以及 NFS 安装其中一些文件系统时一切都很顺利。
当我尝试销毁 1000 个文件系统时,第一个文件系统花了几分钟,然后失败并报告文件系统正在使用中。我发出了系统关闭命令,但花了 10 多分钟。我没有再等,就关闭了电源。
现在启动时,OpenSolaris 挂起。32 个驱动器上的指示灯快速闪烁。我将其放置了 24 小时 - 仍然闪烁,但没有进展。
我在创建 zpool 之前启动了系统快照并尝试导入 zpool。
pfexec zpool import bigdata
相同情况:LED 闪烁并且导入永远挂起。
跟踪“zpool import”过程仅显示 ioctl 系统调用:
dtrace -n syscall:::entry'/pid == 31337/{ @syscalls[probefunc] = count(); }'
ioctl 2499
有没有办法来解决这个问题?编辑:是的。将 OpenSolaris 升级到 svn_134b 就可以了:
pkg publisher # shows opensolaris.org
beadm create opensolaris-updated-on-2010-12-17
beadm mount opensolaris-updated-on-2010-12-17 /mnt
pkg -R /mnt image-update
beadm unmount opensolaris-updated-on-2010-12-17
beadm activate opensolaris-updated-on-2010-12-17
init 6
现在我有 zfs 版本 3。Bigdata zpool 保持在版本 14。并且它已重新投入生产!
但是,在超过 24 小时的繁忙 I/O 访问下(软件升级之前),它都在做什么呢?
答案1
使用 ZFS,您确实希望让它直接操作磁盘,因为它可以提高并发性。您给它的单个 50TB 磁盘是一个瓶颈。
该 DTrace 脚本仅跟踪系统调用。实际操作发生在内核中,如果您想查看哪些程序占用了最多的 CPU,请使用 DTrace Toolkit 中的“hotkernel”脚本。
导入池时,ZFS 会从磁盘读取配置并进行验证。导入池后,它将开始挂载您创建的所有 1000 个文件系统和快照。这可能需要一段时间。如果您启用了重复数据删除(由于您使用的是 snv_111,因此没有启用),则需要更多时间,因为它必须加载重复数据删除表 (DDT)。
关闭系统从来都不是一个好选择,特别是在 OpenSolaris snv_111 上。您尚未发布池配置 (zpool status),但是,如果您有 slog 设备并且它们发生故障,您将无法导入池(此问题最近已在 Solaris 11 Express snv_151a 中得到解决)。
我的建议是,您单独导出 32 个磁盘,并创建多个 raidz2 vdev,这样您就拥有更多的读/写磁头。不要创建包含超过 8 个磁盘的大型 vdev,因为这样性能会非常糟糕。
如果您无法承受系统停机这么长时间(大多数人都无法承受),请仔细研究 ZFS 快照以及如何使用 zfs send/receive 将它们复制到远程服务器。这将允许您快速启动故障转移服务器。
答案2
“zfs import” 或多或少只是直接读回 vdev 的配置(来自“zpool.cache”)。我猜这里花了很长时间才完成的原因是您的删除事务。
假设 ZFS 是事务性的,并且您删除了 1000 个文件系统,每个文件系统有 24 个快照,那么您将执行非常密集的删除操作,需要检查指向 24,000 个快照的引用指针。考虑到这些 SATA 磁头的寻道时间,以及需要执行的所有树更新。