☰

Linux内核多文件系统驱动及性能

tag-icon • tag-icon linux performance filesystems nfs
Linux内核多文件系统驱动及性能

我不确定 Linux 内核如何处理多个文件系统驱动程序，以及文件系统中每个给定挂载点的 inode 查找是否会干扰其他挂载点，或者是否存在其他原因导致系统运行速度变慢，以防内核中存在一些速度较慢的文件系统驱动程序，但该驱动程序管理的挂载文件系统几乎没有使用。

我担心的是 NFS。那么，假设在本地文件系统上执行需要快速磁盘 I/O 的操作，NFS 驱动程序是否会减慢 Linux 内核和/或用户空间的速度？

我认为，安装LD_LIBRARY_PATH或PATH可能会降低系统速度，因为ld和/或bash会尝试在 NFS 上的目录中查找内容。但是，当我在本地文件系统上打开文件时，NFS 真的会干扰吗？

谢谢。

答案1

每个 inode 指向单个文件系统，并且该 inode 的 IO 仅由该文件系统驱动程序处理，无论内核中加载了哪些其他文件系统驱动程序。

具体来说，NFS 本身不会减慢其他 IO 的速度。当然，如果系统受到 NFS 的冲击，那么文件系统的本地 IO 也会变慢，但这是因为共享资源（文件系统底层的磁盘）的 IO 速率较高，而不是 NFS 特有的。换句话说，如果 NFS 子系统处于空闲状态，它不应该以任何方式影响本地 IO。

不会，如果您在本地文件系统上查找文件，NFS 不会干扰。

答案2

我将远程服务器的 nfs 挂载到 /nfs（50 个目录和 100000 个文件）。然后在其他目录中创建、写入和读取文件五次：

time for i in {1..1000};do touch $i;done
time for i in {1..1000};do echo "$i" > $i;done
time for i in {1..1000};do cat "$i" > /dev/null;done

create: average 7.903s
write: average 0.068s
read: average 7.682s

然后卸载/nfs并再次测试

create: average 7.923s
write: average 0.048s
read: average 7.782s

然后重新启动服务器并再次测试（不使用 /nfs）

create: average 7.901s
write: average 0.052s
read: average 7.582s

如果存在影响，则影响非常小。服务器：HP ProLiant DL160 G6，Linux 2.6.32-24-generic-pae

答案3

上述答案虽然正确，但并未解决您询问的每个系统调用中都会进行的库搜索问题。简而言之，我在负载较轻的系统上运行了测试，针对 NFS 的系统调用没有花费额外的、统计上有意义的时间。我有一个 NFS 挂载点，/data/media我将其添加到其中LD_LIBRARY_PATH，然后使用它strace来跟踪系统调用及其执行时间。

对于不熟悉如何启动可执行文件的人来说，在执行传递到之前，必须找到并加载每个共享库main()，而此时 NFS 的探测可能是一个潜在的问题。通过将 NFS 挂载目录添加到库加载器的路径中，我们应该能够进行简单的时间测试。显然，如果 NFS 服务器没有响应，所有新进程的执行都可能停止，特别是如果挂载点被挂载为“硬”，即没有“intr”选项。这部分是因为 shell 将在PATHNFS 挂载点上搜索新程序的名称并卡在 NFS 挂载点上。这不是我们要测量的。

以下是运行程序并记录系统调用执行时间的 shell 代码。请再次注意，/data/media为了简单起见，我在 LD_LIBRARY_PATH 中只有一个 NFS 挂载点。

strace -T -e open java -version  2>&1 |\
perl -ne 'if (m/\/data\/media.*<(\d+\.\d+)>/) { \
             print "nfs,$1\n";
          } elsif (m/<(\d+\.\d+)>/) {
             print "local,$1\n";
          };'

原始 strace 输出与此类似

open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000041>

输出与此类似

local,0.000030
local,0.000031
nfs,0.000042
nfs,0.000029
nfs,0.000029
nfs,0.000030
local,0.000028
local,0.000027
local,0.000027

我选择 perl 是因为我对它很熟悉，但任何文本过滤都可以。

我把这些数字放到电子表格中，并对其进行了排序，这样我就可以向你展示这张表格

               Avg (s)     Max (s)   Min (s)
NFS lag (s) -0.0000072   -0.000529  0.000007
NFS lag (%)    -17.84%     -90.74%    36.84%

很明显，您应该在进行此测试之前尝试将系统缓存抛到一边，看看它是否会改变一些事情，但这不是系统的正常情况。

如果您无法理解该表，那么有些情况下 NFS 实际上比本地文件系统更快。这是违反直觉的，除非您考虑到 VFS 缓存可能正在进行。

因此，我得出结论，至少对于这个小测试来说，在 LD_LIBRARY_PATH 中有一个 NFS 挂载点不会影响可执行文件的加载时间。只要 NFS 服务器处于启动状态...

相关内容