☰

NFS 和 GFS2 性能缓慢

tag-icon • tag-icon web-server storage nfs gfs2
NFS 和 GFS2 性能缓慢

最近，我为一个进行大量文件处理的 Web 应用设计并配置了一个 4 节点集群。该集群被分为两个主要角色：Web 服务器和存储。每个角色都使用 drbd 在主动/被动模式下复制到第二台服务器。Web 服务器对存储服务器的数据目录进行 NFS 挂载，后者还运行一个 Web 服务器来向浏览器客户端提供文件。

在存储服务器中，我创建了一个 GFS2 FS 来保存连接到 drbd 的数据。我选择 GFS2 主要是因为它的性能很好，而且卷大小也相当大。

自从我们投入生产以来，我一直面临两个我认为密切相关的问题。首先，Web 服务器上的 NFS 挂载会挂起一分钟左右，然后恢复正常运行。通过分析日志，我发现 NFS 会停止响应一段时间并输出以下日志行：

Oct 15 18:15:42 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:44 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:46 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:47 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:48 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:51 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:52 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:55 <server hostname> kernel: nfs: server active.storage.vlan not responding, still trying
Oct 15 18:15:58 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK
Oct 15 18:15:59 <server hostname> kernel: nfs: server active.storage.vlan OK

在这种情况下，挂起持续了 16 秒，但有时需要 1 或 2 分钟才能恢复正常运行。

我的第一个猜测是，这是由于 NFS 挂载负载过重而发生的，通过增加到RPCNFSDCOUNT更高的值，这种情况会变得稳定。我多次增加了它，显然，过了一段时间，日志出现的次数开始减少。该值现在为32。

在进一步调查该问题后，我遇到了另一种挂起情况，尽管 NFS 消息仍出现在日志中。有时，GFS2 FS 只是挂起，导致 NFS 和存储 Web 服务器都提供文件服务。两者都挂起一段时间，然后恢复正常操作。这种挂起不会在客户端留下任何痕迹（也不会留下任何NFS ... not responding消息），而在存储方面，日志系统似乎为空，即使正在rsyslogd运行。

节点通过 10Gbps 非专用连接进行连接，但我不认为这是一个问题，因为 GFS2 挂起已确认但直接连接到活动存储服务器。

我已经尝试解决这个问题一段时间了，也尝试了不同的 NFS 配置选项，最后才发现 GFS2 FS 也挂了。

NFS 挂载导出如下：

/srv/data/ <ip_address>(rw,async,no_root_squash,no_all_squash,fsid=25)

NFS 客户端挂载如下：

mount -o "async,hard,intr,wsize=8192,rsize=8192" active.storage.vlan:/srv/data /srv/data

经过一些测试，这些配置可以为集群带来更高的性能。

我迫切希望找到解决方案，因为集群已经处于生产模式，我需要修复这个问题，以便将来不会再发生这种挂起，而且我真的不知道我应该进行什么基准测试以及如何进行基准测试。我能说的是，这是由于负载过重而发生的，因为我之前测试过集群，根本没有发生过这个问题。

如果您需要我提供集群的配置详细信息，请告诉我，以及您希望我发布哪些内容。

作为最后的手段，我可​​以将文件迁移到不同的 FS，但我需要一些可靠的指示来确定这是否能解决这个问题，因为此时卷大小非常大。

该服务器由第三方企业托管，我无法物理访问它们。

此致。

编辑1： 这些服务器是物理服务器，其规格如下：

  • 网络服务器：

    • 英特尔双至强 E5606 2x4 2.13GHz
    • 24GB DDR3
    • 英特尔固态硬盘 320 2 x 120GB Raid 1

  • 贮存：

    • 英特尔 i5 3550 3.3GHz
    • 16GB DDR3
    • 12 个 2TB SATA

最初，服务器之间有一个 VRack 设置，但我们升级了其中一台存储服务器，使其拥有更多 RAM，而它不在 VRack 内。它们通过它们之间的共享 10Gbps 连接进行连接。请注意，它是用于公共访问的同一连接。它们使用单​​个 IP（使用 IP 故障转移）在它们之间进行连接，并允许优雅的故障转移。

因此，NFS 是通过公共连接而不是任何私有网络进行的（升级之前，问题仍然存在）。

防火墙已配置并经过全面测试，但我将其禁用了一段时间，以查看问题是否仍然存在，结果确实如此。据我所知，托管服务提供商没有阻止或限制服务器与公共域之间的连接（至少在尚未达到的给定带宽消耗阈值下）。

希望这有助于解决问题。

编辑2：

相关软件版本：

CentOS 2.6.32-279.9.1.el6.x86_64  
nfs-utils-1.2.3-26.el6.x86_64  
nfs-utils-lib-1.1.5-4.el6.x86_64  
gfs2-utils-3.0.12.1-32.el6_3.1.x86_64  
kmod-drbd84-8.4.2-1.el6_3.elrepo.x86_64  
drbd84-utils-8.4.2-1.el6.elrepo.x86_64

存储服务器上的 DRBD 配置：

#/etc/drbd.d/storage.res
resource storage {
    protocol C;

    on <server1 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server1 ip>:7788;
            meta-disk internal;
    }

    on <server2 fqdn> {
            device /dev/drbd0;
            disk /dev/vg_storage/LV_replicated;
            address <server2 ip>:7788;
            meta-disk internal;
    }
}

存储服务器中的 NFS 配置：

#/etc/sysconfig/nfs
RPCNFSDCOUNT=32
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005
LOCKD_UDPPORT=30001
LOCKD_TCPPORT=30001

LOCKD_UDPPORT（和使用同一个端口会不会发生冲突LOCKD_TCPPORT？）

GFS2 配置：

# gfs2_tool gettune <mountpoint>
incore_log_blocks = 1024
log_flush_secs = 60
quota_warn_period = 10
quota_quantum = 60
max_readahead = 262144
complain_secs = 10
statfs_slow = 0
quota_simul_sync = 64
statfs_quantum = 30
quota_scale = 1.0000   (1, 1)
new_files_jdata = 0

存储网络环境：

eth0      Link encap:Ethernet  HWaddr <mac address>
          inet addr:<ip address>  Bcast:<bcast address>  Mask:<ip mask>
          inet6 addr: <ip address> Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:957025127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1473338731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2630984979622 (2.3 TiB)  TX bytes:1648430431523 (1.4 TiB)

eth0:0    Link encap:Ethernet  HWaddr <mac address>  
          inet addr:<ip failover address>  Bcast:<bcast address>  Mask:<ip mask>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

IP 地址是根据给定的网络配置静态分配的：

DEVICE="eth0"
BOOTPROTO="static"
HWADDR=<mac address>
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=<ip address>
NETMASK=<net mask>

和

DEVICE="eth0:0"
BOOTPROTO="static"
HWADDR=<mac address>
IPADDR=<ip failover>
NETMASK=<net mask>
ONBOOT="yes"
BROADCAST=<bcast address>

Hosts 文件允许与fsid=25两个存储服务器上设置的 NFS 选项一起实现平稳的 NFS 故障转移：

#/etc/hosts
<storage ip failover address> active.storage.vlan
<webserver ip failover address> active.service.vlan

如您所见，数据包错误降至 0。我还运行了很长时间的 ping，没有任何数据包丢失。MTU 大小是正常的 1500。由于现在没有 VLan，这是用于服务器之间通信的 MTU。

网络服务器的网络环境类似。

我忘了提一件事，那就是存储服务器每天通过 NFS 连接处理约 200GB 的新文件，这是我认为这是 NFS 或 GFS2 某种重负载问题的关键点。

如果您需要进一步的配置详细信息，请告诉我。

编辑3：

今天早些时候，我们的存储服务器上发生了一次重大文件系统崩溃。由于服务器停止响应，我无法立即获取崩溃的详细信息。重启后，我注意到文件系统非常慢，我无法通过 NFS 或 httpd 提供单个文件，可能是由于缓存预热等原因。尽管如此，我一直在密切监视服务器，并出现了以下错误dmesg。问题的根源显然是 GFS，它正在等待，lock并在一段时间后最终陷入困境。

INFO: task nfsd:3029 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
nfsd          D 0000000000000000     0  3029      2 0x00000080
 ffff8803814f79e0 0000000000000046 0000000000000000 ffffffff8109213f
 ffff880434c5e148 ffff880624508d88 ffff8803814f7960 ffffffffa037253f
 ffff8803815c1098 ffff8803814f7fd8 000000000000fb88 ffff8803815c1098
Call Trace:
 [<ffffffff8109213f>] ? wake_up_bit+0x2f/0x40
 [<ffffffffa037253f>] ? gfs2_holder_wake+0x1f/0x30 [gfs2]
 [<ffffffff814ff42e>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff814ff2cb>] mutex_lock+0x2b/0x50
 [<ffffffffa0379f21>] gfs2_log_reserve+0x51/0x190 [gfs2]
 [<ffffffffa0390da2>] gfs2_trans_begin+0x112/0x1d0 [gfs2]
 [<ffffffffa0369b05>] ? gfs2_dir_check+0x35/0xe0 [gfs2]
 [<ffffffffa0377943>] gfs2_createi+0x1a3/0xaa0 [gfs2]
 [<ffffffff8121aab1>] ? avc_has_perm+0x71/0x90
 [<ffffffffa0383d1e>] gfs2_create+0x7e/0x1a0 [gfs2]
 [<ffffffffa037783f>] ? gfs2_createi+0x9f/0xaa0 [gfs2]
 [<ffffffff81188cf4>] vfs_create+0xb4/0xe0
 [<ffffffffa04217d6>] nfsd_create_v3+0x366/0x4c0 [nfsd]
 [<ffffffffa0429703>] nfsd3_proc_create+0x123/0x1b0 [nfsd]
 [<ffffffffa041a43e>] nfsd_dispatch+0xfe/0x240 [nfsd]
 [<ffffffffa025a5d4>] svc_process_common+0x344/0x640 [sunrpc]
 [<ffffffff810602a0>] ? default_wake_function+0x0/0x20
 [<ffffffffa025ac10>] svc_process+0x110/0x160 [sunrpc]
 [<ffffffffa041ab62>] nfsd+0xc2/0x160 [nfsd]
 [<ffffffffa041aaa0>] ? nfsd+0x0/0x160 [nfsd]
 [<ffffffff81091de6>] kthread+0x96/0xa0
 [<ffffffff8100c14a>] child_rip+0xa/0x20
 [<ffffffff81091d50>] ? kthread+0x0/0xa0
 [<ffffffff8100c140>] ? child_rip+0x0/0x20

编辑4：

我安装了 munin，并且有一些新数据出来了。今天又出现了一次挂起，munin 显示以下信息：挂起前 inode 表大小高达 80k，然后突然降至 10k。与内存一样，缓存数据也突然从 7GB 降至 500MB。挂起期间平均负载也出现峰值，设备的设备使用率drbd也出现峰值至 90% 左右。

与之前的挂起相比，这两个指标表现相同。这可能是由于应用程序端的文件管理不善导致未释放文件处理程序，还是由于 GFS2 或 NFS 的内存管理问题（我对此表示怀疑）？

谢谢任何可能的反馈。

编辑5：

Munin 的 Inode 表使用情况：

Munin 的内存使用情况：

答案1

我只能提供一些一般性指示。

首先，我会设置并运行一些简单的基准指标。这样你至少会知道你所做的改变是否是最好的。

  • 穆宁
  • 仙人掌

  • 纳吉奥斯

    都是一些不错的选择。

这些节点是虚拟服务器还是物理服务器，它们的规格是什么。

各个节点之间采用什么样的网络连接

NFS 是否通过您的托管服务提供商的私有网络设置。

您没有使用防火墙限制数据包/端口，您的托管服务提供商是否这样做？

答案2

我认为您有两个问题。首先是瓶颈导致了这个问题，更重要的是，GFS 的故障处理能力差。GFS 应该减慢传输速度直到它正常工作，但我无法提供帮助。

您说集群处理了约 200GB 的新文件到 NFS。从集群读取了多少数据？

我总是对前端和后端只有一个网络连接感到紧张，因为它允许前端“直接”破坏后端（通过超载数据连接）。

如果在每个盒子上都安装 iperf，则可以随时测试可用的网络吞吐量。这可能是快速识别是否存在网络瓶颈的方法。

网络利用率如何？存储服务器上的磁盘速度有多快，您使用的是哪种 RAID 设置？您的吞吐量是多少？假设它运行的是 *nix，并且您有安静的时间进行测试，则可以使用 hdparm

$ hdpard -tT /dev/<device>

如果您发现网络使用率过高，我建议将 GFS 放在辅助专用网络连接上。

根据您对 12 个磁盘进行 raid 的方式，您可能会获得不同程度的性能，这可能是第二个瓶颈。这还取决于您使用的是硬件 raid 还是软件 raid。

如果请求的数据分布在总内存之外，那么机器上大量的内存可能没什么用处，这听起来可能确实如此。此外，内存只能帮助读取，而且主要是在大量读取针对同一个文件的情况下（否则，它将被踢出缓存）

运行 top / htop 时，观察 iowait。此处的高值是一个很好的指标，表明 CPU 只是在无所事事地等待某些事情（网络、磁盘等）

我认为 NFS 不太可能是罪魁祸首。我们在 NFS 方面有相当丰富的经验，虽然它可以调整/优化 - 但趋向工作非常可靠。

我倾向于让 GFS 组件稳定下来，然后看看 NFS 的问题是否会消失。

最后，OCFS2 可能是 GFS 的一个可考虑的替代选项。当我研究分布式文件系统时，我做了相当多的研究，我不记得我选择尝试 OCFS2 的原因 - 但我做到了。也许这与 Oracle 将 OCFS2 用于其数据库后端有关，这意味着对稳定性的要求相当高。

Munin 是你的朋友。但更重要的是 top / htop。vmstat 还可以为你提供一些关键数字。

$ vmstat 1

您将每秒获得一次更新，了解系统花费时间执行的具体操作。

祝你好运！

答案3

首先，使用 Varnish 或 Nginx 作为 Web 服务器的 HA 代理。

然后对于 Web 文件系统：为什么不使用 MooseFS 而不是 NFS、GFS2，它具有容错能力并且读取速度快。NFS、GFS2 所失去的是本地锁，您的应用程序需要它吗？如果不是，我会切换到 MooseFS 并跳过 NFS、GFS2 问题。您将需要使用 Ucarp 来 HA MFS 元数据服务器。

在 MFS 中将复制目标设置为 3

# mfssetgoal 3 /文件夹

//基督教

答案4

根据您的 munin 图表，系统正在删除缓存，这相当于运行以下操作之一：

  1. echo 2 > /proc/sys/vm/drop_caches
    1. 空闲的 dentry 和 inode
  2. echo 3 > /proc/sys/vm/drop_caches
    1. 释放 pagescache、dentires 和 inode

问题是为什么，是否可能有一个挥之不去的 cron 任务？

除了 01:00 -> 12:00 之外，它们似乎都是有规律的间隔。

如果运行上述命令之一时再次出现了您的问题，则也值得在峰值过半时进行检查，但是总是在这样做之前，请确保你跑到了sync右边。

strace如果您的 drbd 进程（再次假设这是罪魁祸首）在预期清除的时间前后以及所述清除过程中出现问题，可能会带来一些启示。

相关内容