NFS 客戶端讀寫速度不平衡
我有一台 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
。企業儲存配置文件的 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
在 fstab 中添加
noac
nfs 掛載選項是靈丹妙藥。總吞吐量沒有改變,仍然在 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 做一些基準測試,所以我們會看看這些不同的緩衝區大小是如何執行的。