Linux

NFS 客戶端讀寫速度不平衡

  • February 7, 2013

我有一台 NetApp 作為我的 nfs 伺服器,兩台 Linux 伺服器作為 nfs 客戶端。問題在於,兩台伺服器中較新的一台在同時對 nfs 伺服器進行讀寫時,其讀寫速度差異*很大。*另外,對於這個新伺服器來說,讀寫看起來很棒。較舊的伺服器沒有此問題。

老宿主:鯉魚

Sun Fire x4150,帶 8 核,32 GB RAM

SLES 9 SP4

網路驅動:e1000

me@carp:~> uname -a
Linux carp 2.6.5-7.308-smp #1 SMP Mon Dec 10 11:36:40 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

新主人:小辣椒

HP ProLiant Dl360P Gen8 帶 8 個核心,64 GB RAM

CentOS 6.3

網路驅動:tg3

me@pepper:~> uname -a
Linux pepper 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

我將跳到一些說明讀/寫測試的圖表。這是辣椒及其不平衡的讀/寫:

辣椒吞吐量

這是鯉魚,看起來不錯:

鯉魚吞吐量

測試

這是我正在執行的讀/寫測試。我已經分別執行了這些,它們在胡椒上看起來很棒,但是當一起執行時(使用&),寫入性能保持穩定,而讀取性能受到很大影響。測試文件的大小是 RAM 的兩倍(辣椒使用 128 GB,鯉魚使用 64 GB)。

# write
time dd if=/dev/zero of=/mnt/peppershare/testfile bs=65536 count=2100000 &
# read 
time dd if=/mnt/peppershare/testfile2 of=/dev/null bs=65536 &

NFS 伺服器主機名是 nfsc。Linux 客戶端在一個子網上有一個專用的 NIC,它與其他任何東西分開(即與主 IP 不同的子網)。每個 Linux 客戶端都將一個 nfs 共享從伺服器 nfsc 掛載到 /mnt/hostnameshare。

nfsiostat

這是胡椒的 simul r/w 測試期間的 1 分鐘樣本:

me@pepper:~> nfsiostat 60

nfsc:/vol/pg003 mounted on /mnt/peppershare:

  op/s         rpc bklog
1742.37            0.00
read:             ops/s            kB/s           kB/op         retrans         avg RTT (ms)    avg exe (ms)
                49.750         3196.632         64.254        0 (0.0%)           9.304          26.406
write:            ops/s            kB/s           kB/op         retrans         avg RTT (ms)    avg exe (ms)
               1642.933        105628.395       64.293        0 (0.0%)           3.189         86559.380

我還沒有舊主機鯉魚上的 nfsiostat,但正在努力。

/proc/mounts

me@pepper:~> cat /proc/mounts | grep peppershare 
nfsc:/vol/pg003 /mnt/peppershare nfs rw,noatime,nodiratime,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0

me@carp:~> cat /proc/mounts | grep carpshare 
nfsc:/vol/pg008 /mnt/carpshare nfs rw,v3,rsize=32768,wsize=32768,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,timeo=60000,retrans=3,hard,tcp,lock,addr=nfsc 0 0

網卡設置

me@pepper:~> sudo ethtool eth3
Settings for eth3:
       Supported ports: [ TP ]
       Supported link modes:   10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Half 1000baseT/Full
       Supports auto-negotiation: Yes
       Advertised link modes:  10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Half 1000baseT/Full
       Advertised pause frame use: Symmetric
       Advertised auto-negotiation: Yes
       Speed: 1000Mb/s
       Duplex: Full
       Port: Twisted Pair
       PHYAD: 4
       Transceiver: internal
       Auto-negotiation: on
       MDI-X: off
       Supports Wake-on: g
       Wake-on: g
       Current message level: 0x000000ff (255)
       Link detected: yes

me@carp:~> sudo ethtool eth1
Settings for eth1:
       Supported ports: [ TP ]
       Supported link modes:   10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Full
       Supports auto-negotiation: Yes
       Advertised link modes:  10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Full
       Advertised auto-negotiation: Yes
       Speed: 1000Mb/s
       Duplex: Full
       Port: Twisted Pair
       PHYAD: 1
       Transceiver: internal
       Auto-negotiation: on
       Supports Wake-on: umbg
       Wake-on: g
       Current message level: 0x00000007 (7)
       Link detected: yes

解除安裝設置:

me@pepper:~> sudo ethtool -k eth3
Offload parameters for eth3:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

me@carp:~> # sudo ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on

這一切都在一個 LAN 上,在 nfs 客戶端和 nfs 伺服器之間有一個全雙工的千兆交換機。另一方面,我發現在 CPU 上等待辣椒的 IO 比 carp 多得多,正如我所預料的那樣,因為我懷疑它在等待 nfs 操作。

我已經用 Wireshark/Ethereal 擷取了數據包,但我在那個領域並不強,所以不知道要尋找什麼。我沒有在 Wireshark 中看到一堆以紅色/黑色突出顯示的數據包,所以這就是我尋找的所有內容:)。這種糟糕的 nfs 性能已經體現在我們的 Postgres 環境中。

任何進一步的想法或故障排除提示?讓我知道我是否可以提供更多資訊。

更新

根據@ewwhite 的評論,我嘗試了兩種不同的 tune-adm 配置文件,但沒有任何變化。

在我的紅色標記的右邊是另外兩個測試。第一座山與throughput-performance,第二座與enterprise-storage

辣椒adm調整

企業儲存配置文件的 nfsiostat 60

nfsc:/vol/pg003 mounted on /mnt/peppershare:

  op/s         rpc bklog
1758.65            0.00
read:             ops/s            kB/s           kB/op         retrans         avg RTT (ms)    avg exe (ms)
                51.750         3325.140         64.254        0 (0.0%)           8.645          24.816
write:            ops/s            kB/s           kB/op         retrans         avg RTT (ms)    avg exe (ms)
               1655.183        106416.517       64.293        0 (0.0%)           3.141         159500.441

更新 2

sysctl -a 用於胡椒

在 fstab 中添加noacnfs 掛載選項是靈丹妙藥。總吞吐量沒有改變,仍然在 100 MB/s 左右,但我的讀寫現在更加平衡,我不得不想像這對 Postgres 和其他應用程序來說是個好兆頭。

在此處輸入圖像描述

您可以看到我標記了我在測試時使用的各種“塊”大小,即 rsize/wsize 緩衝區大小安裝選項。令人驚訝的是,我發現 8k 大小的 dd 測試吞吐量最高。

這些是我現在使用的 nfs 掛載選項/proc/mounts

nfsc:/vol/pg003 /mnt/peppershare nfs rw,sync,noatime,nodiratime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0

僅供參考,noac選項 man 條目:

交流/諾克

選擇客戶端是否可以記憶體文件屬性。如果兩個選項都沒有指定(或者如果指定了 ac),客戶端記憶體文件屬性。

為了提高性能,NFS 客戶端記憶體文件屬性。每隔幾秒鐘,NFS 客戶端就會檢查每個文件屬性的伺服器版本以進行更新。在客戶端再次檢查伺服器之前,在這些小間隔內發生在伺服器上的更改不會被檢測到。noac 選項可防止客戶端記憶體文件屬性,以便應用程序可以更快地檢測伺服器上的文件更改。

除了防止客戶端記憶體文件屬性外,noac 選項還強制應用程序寫入同步,以便對文件的本地更改立即在伺服器上可見。這樣,其他客戶端在檢查文件屬性時可以快速檢測到最近的寫入。

使用 noac 選項可以在訪問相同文件的 NFS 客戶端之間提供更高的記憶體一致性,但會導致顯著的性能損失。因此,鼓勵明智地使用文件鎖定。數據和元數據一致性部分包含對這些權衡的詳細討論。

我在網路上閱讀了關於屬性記憶體的混合意見,所以我唯一的想法是它是一個必要的選項,或者與具有較新核心 (>2.6.5) 的 NetApp NFS 伺服器和/或 Linux 客戶端配合得很好。我們在具有 2.6.5 核心的 SLES 9 上沒有看到此問題。

我還閱讀了關於 rsize/wise 的混合意見,通常你採用預設值,目前我的系統是 65536,但 8192 給了我最好的測試結果。我們也會用 postgres 做一些基準測試,所以我們會看看這些不同的緩衝區大小是如何執行的。

引用自:https://serverfault.com/questions/474571