☰

NFS 和 GFS2 效能緩慢

tag-icon • tag-icon web-server storage nfs gfs2
NFS 和 GFS2 效能緩慢

最近，我為一個進行大量文件處理的 Web 應用程式設計並配置了一個 4 節點叢集。此叢集已分為 2 個主要角色：網路伺服器和儲存。每個角色都使用 drbd 以主動/被動模式複製到第二個伺服器。 Web 伺服器對儲存伺服器的資料目錄進行 NFS 掛載，且儲存伺服器也執行 Web 伺服器來向瀏覽器用戶端提供檔案。

在儲存伺服器中，我建立了一個 GFS2 FS 來儲存連接到 drbd 的資料。我選擇 GFS2 主要是因為其公佈的效能，而且還因為磁碟區大小必須相當高。

自從我們進入製作階段以來，我一直面臨著兩個我認為密切相關的問題。首先，網頁伺服器上的 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 掛起已確認，但直接連接到活動儲存伺服器。

我已經嘗試解決這個問題有一段時間了，在發現 GFS2 FS 也掛起之前，我嘗試了不同的 NFS 配置選項。

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

經過一些測試，這些配置可以為叢集帶來更高的效能。

我迫切希望找到一個解決方案，因為叢集已經處於生產模式，我需要修復這個問題，以便將來不會發生這種掛起，而且我真的不知道應該進行什麼以及如何進行基準測試。我可以告訴的是，這是由於負載過重而發生的，因為我之前測試過集群，並且這個問題根本沒有發生。

請告訴我您是否需要我提供集群的配置詳細信息，以及您希望我發布哪些內容。

作為最後的手段，我可​​以將檔案遷移到不同的檔案系統，但我需要一些可靠的指示來確定這是否可以解決這個問題，因為此時磁碟區的大小非常大。

這些伺服器由第三方企業託管，我無法實際存取它們。

此致。

編輯1： 伺服器是實體伺服器，其規格為：

  • 網路伺服器：

    • 英特爾雙核心至強 E5606 2x4 2.13GHz
    • 24GB DDR3
    • 英特爾 SSD 320 2 個 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>

主機檔案允許與fsid=25兩個儲存伺服器上設定的 NFS 選項結合進行正常的 NFS 故障轉移：

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

正如你所看到的，資料包錯誤已降至 0。 MTU大小為正常的1500。

網路伺服器的網路環境類似。

我忘記提及的一件事是，儲存伺服器每天透過 NFS 連接處理約 200GB 的新文件，這是我認為這是 NFS 或 GFS2 的某種重負載問題的關鍵點。

如果您需要更多配置詳細信息，請告訴我。

編輯3：

今天早些時候，我們的儲存伺服器上發生了重大檔案系統崩潰。由於伺服器停止回應，我無法立即獲取崩潰的詳細資訊。重新啟動後，我注意到文件系統非常緩慢，我無法透過 NFS 或 httpd 提供單一文件，可能是由於快取預熱等原因。儘管如此，我一直在密切監視伺服器，並且在dmesg.問題的根源顯然是 GFS，它正在等待 a，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 的索引節點表用法：

Munin 的記憶體使用情況：

答案1

我只能提供一些一般性的指導。

首先，我將啟動並運行一些簡單的基準指標。至少這樣你就會知道你所做的改變是否是最好的。

  • 穆寧
  • 仙人掌

  • 納吉奧斯

    是一些不錯的選擇。

這些節點是虛擬伺服器還是實體伺服器，它們的規格是什麼。

每個節點之間的網路連接是什麼樣的

NFS 是否設定在您的託管供應商專用網路上。

您沒有使用防火牆限制資料包/端口，您的託管提供者是否這樣做？

答案2

我認為你有兩個問題。首先是瓶頸導致了這個問題，更重要的是，GFS 的故障處理能力差。 GFS 確實應該減慢傳輸速度，直到它起作用，但我無法提供幫助。

您說叢集將大約 200GB 的新檔案處理到 NFS 中。從集群中讀取了多少資料？

我總是對前端和後端有一個網路連接感到緊張，因為它允許前端「直接」破壞後端（透過超載數據連接）。

如果您在每個機器上安裝 iperf，則可以測試任何給定點的可用網路吞吐量。這可能是識別是否存在網路瓶頸的快速方法。

網路使用率如何？儲存伺服器上的磁碟速度有多快以及您使用什麼 raid 設定？您能獲得多少吞吐量？假設它正在運行 *nix 並且您有安靜的時間來測試，您可以使用 hdparm

$ hdpard -tT /dev/<device>

如果您發現網路使用率很高，我建議將 GFS 放在輔助專用網路連線上。

根據您對 12 個磁碟進行 raid(ed) 的方式，您可能會獲得不同程度的效能，這可能是第二個瓶頸。它還取決於您使用的是硬體 raid 還是軟體 raid。

如果所要求的資料分佈在超過您的總記憶體（聽起來可能是這樣）的情況下，那麼您在盒子上擁有的大量記憶體可能沒有什麼用處。此外，記憶體只能幫助讀取，而且大多數情況下，如果大量讀取針對相同檔案（否則，它將被從快取中踢出）

運行top/htop時，觀察iowait。這裡的高值是一個很好的指標，表明 cpu 只是在等待某些東西（網路、磁碟等）

在我看來，NFS 不太可能是罪魁禍首。我們在 NFS 方面擁有相當豐富的經驗，雖然它可以調整/優化 - 它趨於工作相當可靠。

我傾向於讓 GFS 元件穩定，然後看看 NFS 的問題是否消失。

最後，OCFS2 可能是替代 GFS 的選項。當我對分散式檔案系統進行一些研究時，我做了相當多的研究，但我不記得我選擇嘗試 OCFS2 的原因 - 但我做到了。也許這與 Oracle 將 OCFS2 用於其資料庫後端有關，這意味著相當高的穩定性要求。

穆寧是你的朋友。但更重要的是 top / htop。 vmstat 還可以為您提供一些關鍵數字

$ vmstat 1

您每秒都會收到有關係統正在花時間做什麼的更新資訊。

祝你好運！

答案3

第一個 HA 代理程式使用 Varnish 或 Nginx 前置 Web 伺服器。

那麼對於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. 空閒目錄和索引節點
  2. echo 3 > /proc/sys/vm/drop_caches
    1. 免費頁面快取、dentires 和 inode

問題是為什麼，是否有一個揮之不去的 cron 任務？

除了 01:00 -> 12:00 之外，它們似乎是有規律的間隔。

如果執行上述命令之一重新建立您的問題，也值得檢查大約 1/2 的峰值方式，但是總是sync這樣做之前請確保您運行正確。

strace如果您的 drbd 程序（再次假設這是罪魁禍首）在預期清除期間和直至所述清除期間失敗，可能會帶來一些啟示。

相關內容