慢NFS和GFS2性能

最近我为一个webappdevise并configuration了一个4节点的集群，它可以处理大量的文件。 集群已经被分解为两个主要angular色，即networking服务器和存储。 在主动/被动模式下，使用drbd将每个angular色复制到另一台服务器。 networking服务器执行存储服务器的数据目录的NFS挂载，而后者也具有运行以向浏览器客户端提供文件的networking服务器。

在存储服务器中，我创build了一个GFS2 FS来保存连接到drbd的数据。 我之所以selectGFS2主要是因为宣布的性能，还因为体积大小相当高。

自从我们进入生产以来，我一直面临着两个我认为深深联系的问题。 首先，networking服务器上的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分钟才能恢复正常操作。

• 存储空间稍后添加镜像驱动器
• 使用Microsoft存储空间奇偶校验卷调整日记磁盘的大小
• HP StoreEasy 1630池扩展
• 服务器挂起文件副本
• IBM XIV（存储arrays） – 任何人？

我的第一个猜测是，这是由于NFS挂载的重负载而发生的，并且通过将RPCNFSDCOUNT增加到更高的值，这将变得稳定。 我增加了几次，显然，一段时间后，日志开始出现较less的时间。 价值现在在32 。

在进一步调查这个问题之后，我遇到了一个不同的挂起，尽pipeNFS消息仍然出现在日志中。 有时候，GFS2 FS会挂起，导致NFS和存储networking服务器提供文件。 两者都保持一段时间，然后恢复正常的操作。 这挂起了在客户端留下痕迹（也没有留下任何NFS ... not responding消息），而在存储方面，即使rsyslogd正在运行，日志系统也显示为空。

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

我一直试图解决这个问题，现在我已经尝试了不同的NFSconfiguration选项，在我发现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 

经过一些testing后，这些configuration对集群产生了更多的性能。

我急于find一个解决scheme，因为集群已经处于生产模式，我需要解决这个问题，以便将来不会发生这种情况，我不确定我应该做什么以及如何进行基准testing。 我可以告诉的是，这是由于重负载，因为我已经testing了集群，这个问题根本没有发生。

请告诉我是否需要我提供集群的configuration细节，以及您希望我发布哪些信息。

作为最后的手段，我可​​以将文件迁移到不同的FS，但是我需要一些关于这是否能够解决这个问题的明确指示，因为在这一点上，卷大小是非常大的。

服务器由第三方企业托pipe，我没有物理访问权限。

最好的祝福。

编辑1：服务器是物理服务器，其规格是：

• Web服务器：

  • Intel Bi Xeon E5606 2×4 2.13GHz
  • 24GB DDR3
  • 英特尔SSD 320 2 x 120GB Raid 1

• 存储：

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

最初在服务器之间有一个VRack设置，但是我们升级了一个存储服务器以拥有更多的RAM，而不是在VRack内部。 它们通过它们之间的共享10Gbps连接进行连接。 请注意，这是用于公共访问的连接。 他们使用一个IP（使用IP故障切换）在它们之间进行连接，并允许正常的故障切换。

因此，NFS是通过公共连接而不是在任何专用networking下（升级之前，问题依然存在）。

防火墙已经被彻底的configuration和testing了，但是我停了一会儿，看看问题是否仍然存在。 据我所知，托pipe服务提供商并没有阻止或限制服务器和公共域之间的连接（至less在给定的带宽消耗门限尚未达到的情况下）。

希望这有助于找出问题。

编辑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 

存储服务器上的DRBDconfiguration：

 #/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; } } 

存储服务器中的NFSconfiguration：

 #/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 ，使用相同的端口是否LOCKD_UDPPORT LOCKD_TCPPORT ？）

GFS2configuration：

 # 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 

存储networking环境：

 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地址是静态分配给定的networkingconfiguration：

 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> 

托pipe文件以允许在两个存储服务器上同时设置NFS选项fsid=25进行正常的NFS故障切换：

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

正如你所看到的，数据包错误已经降低到了0.我也运行了很长一段时间ping没有任何数据包丢失。 MTU大小是正常的1500.由于现在没有VLan，所以这是用于在服务器之间进行通信的MTU。

networking服务器的networking环境是相似的。

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

如果你需要进一步的configuration细节，请告诉我。

编辑3：

今天早些时候，我们在存储服务器上发生了严重的文件系统崩溃。 由于服务器停止响应，我无法立即得到崩溃的细节。 重新启动后，我注意到文件系统非常慢，我无法通过NFS或httpd服务单个文件，可能是由于caching温度boost等原因。 不过，我一直在密切监视服务器，并在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。 与内存一样，caching数据也从7GB突然下降到500MB。 负载平均值也会在挂起期间出现峰值，而drbd设备的设备使用率也会达到90％左右。

与之前的挂起相比，这两个指标performance相同。 这可能是由于在应用程序方面的不良文件pipe理，不释放文件处理程序，或者可能是来自GFS2或NFS（我怀疑）的内存pipe理问题？

感谢任何可能的反馈。

编辑5：

Munin的Inode表使用情况：

来自Munin的内存使用情况：

 $ hdpard -tT /dev/<device> 

 $ vmstat 1