☰

通过 NFS 共享的 Fuseblk 分区中数百万个文件的读取速度缓慢

tag-icon • tag-icon nfs ntfs fuse ntfs-3g
通过 NFS 共享的 Fuseblk 分区中数百万个文件的读取速度缓慢

我有两个 Linux 系统：NFSServer1 (RHEL) 和 NFSClient1 (Ubuntu)。

在 NFSServer1 上安装了ntfs-3g驱动程序。通过执行以下命令来挂载设备分区 ldmtool：NTFSmount -t ntfs-3g -o ro,noatime $devPath $mountPath

注意：这两个分区/dev/mapper/ldm_vol_VishalWDD-Dg0_Volume1是/dev/mapper/ldm_vol_VishalWDD-Dg0_Volume2使用派生的 Windows 动态磁盘分区LDM工具

[root@ROADQAScaleNFS2 ~]# df -Th
Filesystem                                Type      Size  Used Avail Use% Mounted on
/dev/sdc4                                 fuseblk   127G   11G  117G   9% /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc4
/dev/sdc2                                 fuseblk   450M   13M  438M   3% /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc2
/dev/mapper/ldm_vol_VishalWDD-Dg0_Volume1 fuseblk    10G  5.8G  4.3G  58% /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume1
/dev/mapper/ldm_vol_VishalWDD-Dg0_Volume2 fuseblk    10G  6.0G  4.1G  60% /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume2

[root@ROADQAScaleNFS2 ~]# mount
/dev/sdc4 on /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc4 type fuseblk (ro,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/sdc2 on /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc2 type fuseblk (ro,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/mapper/ldm_vol_VishalWDD-Dg0_Volume1 on /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume1 type fuseblk (ro,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/mapper/ldm_vol_VishalWDD-Dg0_Volume2 on /monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume2 type fuseblk (ro,noatime,user_id=0,group_id=0,allow_other,blksize=4096)

所有这些分区总共有大约 1000 万个文件。

这些已安装的分区可作为 NFS 共享从 NFSClient1 访问：

[root@NFSClient ~]# mount
10.4.0.5:/monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc4 on /monitor1/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc4 type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.148.66.49,local_lock=none,addr=10.4.0.5)
10.4.0.5:/monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc2 on /monitor1/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/sdc2 type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.148.66.49,local_lock=none,addr=10.4.0.5)
10.4.0.5:/monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume1 on /monitor1/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume1 type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.148.66.49,local_lock=none,addr=10.4.0.5)
10.4.0.5:/monitor/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume2 on /monitor1/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume2 type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.148.66.49,local_lock=none,addr=10.4.0.5)

NFS 服务器上的 NFS 守护线程数设置为 64。

fuseblk接下来，在 NFS 客户端上，当我们使用命令发出 stat 分区时find：

find -H /monitor1/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume2 -printf '%p|' | xargs -d '|' stat --printf="%F, %i:\t%n\t%.19x\t%.19y\t%.19z\t%.19w\t%s\t%u\t%g\n" \ |$SED -e "s|/monitor1/6f5bd42-e548-4e60-8c5d-4c52360b8dc4/mapper/ldm_vol_VishalWDD-Dg0_Volume2/||g" -e "s|directory,|d/d|g" -e "s|symbolic link,|l/l|g" -e "s|regular file,|r/r|g" -e "s|socket,|h/h|g" \ -e "s|regular empty file,|r/r|g" -e "s|fifo,|p/p|g"

它的执行速度极其缓慢。需要休息 5-6 分钟，然后恢复几秒钟。对于所有其他安装点也是如此。即使 12 小时后执行也没有完成。

ext4对于和xfs设备类型，未观察到这种缓慢的行为。

作为测试，我尝试在 NFSServer1 上执行相同的 find 命令，速度相当快。整个执行过程在大约 40 分钟内完成。但我无权访问 NFS 服务器。我已要求 NFS 服务器团队尝试不同的安装选项，如ntfs-3g 手册页，但这没有帮助。

如果有什么方法可以提高fuseblkNFS 分区的读取性能，我将非常感谢你们。

非常感谢！

答案1

FUSE 是用户空间中的文件系统 - 由于上下文切换开销，它永远不会像内核中的文件系统那么快，我的猜测是，当您必须执行文件系统密集型操作（例如find在上面。

所以。

  • 使用 NTFS3 内核驱动程序（如果我没记错的话，在 Linux 5.15 及更高版本中可用），或者
  • 将所有数据移动到不同的文件系统一次（如果您再次需要，请将其同步到 NTFS），或者
  • 运行半虚拟化 Windows Server VM 通过 NFS 为该文件系统提供服务

我个人强烈倾向于第二种选择。从绝对不适合该文件系统永久访问某些内容有什么意义？我们谈论的实际数据甚至还不到 40GB——这根本不算什么。

我的意思是，你有一个极品飞车团队。有人雇用人员来通过 NFS 访问您的数据。为什么他们甚至支持直接导出 NTFS 我有点难以理解。

相关内容