NFSクライアントの読み取り速度と書き込み速度のバランスが悪い
NfsサーバーとしてNetAppを使用し、nfsクライアントとして2つのLinuxサーバーを使用しています。問題は、2つのサーバーの新しい方が、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
新しいホスト：Pepper
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
読み取り/書き込みテストを示すグラフにジャンプします。 Heres pepperとそのアンバランスな読み取り/書き込み：
そして、ここに鯉がいます。
テスト
これが私が実行している読み取り/書き込みテストです。私はこれらを個別に実行しましたが、コショウで見栄えがしますが、一緒に実行すると（&を使用して）、書き込みパフォーマンスは安定したままですが、読み取りパフォーマンスは大幅に低下します。テストファイルは、RAMの2倍のサイズです（コショウには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クライアントには、他のものとは別のサブネット（つまり、プライマリIPとは異なるサブネット）に専用のNICがあります）。各Linuxクライアントは、サーバーnfscから/ mnt/hostnameshareにnfs共有をマウントします。
nfsiostat
コショウの同時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
そのすべては、nfsクライアントとnfsサーバー間の全二重のギガビットスイッチを備えたLAN上にあります。別のメモでは、期待どおりに、nfs操作で待機しているのではないかと思っているので、期待どおりに、コップよりもCPUでコショウを待つIO CPUでかなり待機しています。
Wireshark/Etherealでパケットをキャプチャしましたが、その分野では得意ではないため、何を探すべきかわかりません。 Wiresharkで赤/黒で強調表示されているパケットの束が表示されないので、探していたすべてのパケットが表示されます。この不十分なNFSパフォーマンスは、Postgres環境で明らかになっています。
さらに考えやトラブルシューティングのヒントはありますか？さらに情報を提供できるかどうか教えてください。
更新
@ewwhiteのコメントによると、2つの異なるtuned-admプロファイルを試しましたが、変更はありませんでした。
私の赤いマークの右側には、さらに2つのテストがあります。最初の丘はthroughput-performanceで、2番目の丘は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テストに最適なスループットであることがわかりました。
これらは、/proc/mountsごとに、現在使用しているnfsマウントオプションです。
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オプションの男性エントリ：
ac/noac
クライアントがファイル属性をキャッシュできるかどうかを選択します。どちらのオプションも指定されていない場合（またはacが指定されている場合）、クライアントはファイル属性をキャッシュします。
パフォーマンスを向上させるために、NFSクライアントはファイル属性をキャッシュします。 NFSクライアントは、数秒ごとに、サーバーの各ファイルの属性のバージョンをチェックして更新を確認します。これらの短い間隔でサーバーで発生する変更は、クライアントがサーバーを再度チェックするまで検出されません。 noacオプションは、クライアントがファイル属性をキャッシュできないようにするため、アプリケーションはサーバー上のファイルの変更をより迅速に検出できます。
Noacオプションは、クライアントがファイル属性をキャッシュできないようにするだけでなく、アプリケーションの書き込みを強制的に同期させて、ファイルへのローカルな変更がサーバー上ですぐに表示されるようにします。そうすれば、他のクライアントはファイルの属性をチェックするときに最近の書き込みをすばやく検出できます。
Noacオプションを使用すると、同じファイルにアクセスするNFSクライアント間のキャッシュコヒーレンスが向上しますが、パフォーマンスが大幅に低下します。そのため、代わりにファイルロックを慎重に使用することをお勧めします。データとメタデータの一貫性のセクションには、これらのトレードオフの詳細な説明が含まれています。
私はウェブ上の属性キャッシングについてさまざまな意見を読んだので、私の唯一の考えは、NetApp NFSサーバーや新しいカーネル（> 2.6.5）を備えたLinuxクライアントで必要またはうまく機能するオプションだということです。 2.6.5カーネルを搭載したSLES9ではこの問題は発生しませんでした。
私はまた、rsize/wiseについての混合意見を読んで、通常はデフォルトを使用します。現在のところ、私のシステムでは65536ですが、8192が最良のテスト結果を与えてくれました。 postgresでもいくつかのベンチマークを実行するので、これらのさまざまなバッファーサイズがどのように機能するかを確認します。