同じサーバー上の NFS/CIFS ディレクトリ間のコピーが遅い

Question

うーん... いくつか問題に気付きましたし、決定的な証拠も 1 つか 2 つ見つけたと思います。でも、まずはいくつか質問をして、皆さんの答えを推測してみます。一見無関係に思えるデータもいくつか提示しますが、読む価値は十分にあると思います。それでは、どうぞお待ちください... :-)

RAID10 では、ストライプ + 冗長ドライブが合計 4 つあると想定しています。
そして、Linux autoraid (ハードウェア RAID コントローラーではなく) を使用していること。
また、すべての SATA ポートが相互に独立してフル転送速度で双方向に転送でき、すべての SATA ポートが同等の高速性を備えていると想定しています。つまり、1 つの SATA アダプタ/コントローラがあれば、それに接続されているすべてのディスクを定格速度で実行することができます。
また、最新のSATA仕様のドライブとコントローラをお持ちだと仮定します。つまり、6.0Gb/sです。つまり、600MB/秒です。控えめに言っても、その半分の300MB/秒だと仮定しましょう。
クライアントからサーバーへの通信は NIC に制限されているため (100MB/秒)、ドライブに十分な負荷をかけることができません。
NFS-to-NFS を実行するときに NIC よりも高速にするには、localhost を使用していると想定しています。これにより、NIC の制限速度を超えることができます (問題ではないことを示すためにボンディングを行ったとおっしゃったと思います)

問題 1。報告されている転送速度は、高速なローカル間でさえ低いようです。ディスクが高速であれば、150MB/秒以上は期待できます。私の 3 ディスク raid0 システムは 3.0Gb/秒しか出ません (アダプタ制限)。ストライプ化すれば 450 MB/秒になります。あなたのディスク/コントローラは私の 2 倍の速度なので、ローカル間転送では 150MB/秒ではなく 300MB/秒 (ストライプ化のため) になると思います。あるいは、600MB/秒 (議論のために半分になるかもしれない FS オーバーヘッドを除く) になるかもしれません。

zpool 情報から、ディスク構成が Western Digital であり、次のようになっていることがわかりました。

ミラー-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
ミラー1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

これをあなたのiostat情報と比較してみましょう。すべてのテストのすべてのドライブのiostat情報があればいいのですが、あなたが提供したものだけで問題を診断できると思います。
sdbとsddは最大限に活用されています
ご指摘のとおり、これは奇妙な私は期待する全てドライブは RAID10 で使用率と統計のバランスをとる必要があります。これが [私の] 決定的な証拠です。
2 つを組み合わせる。最大容量のドライブは、最大容量でないドライブとは少し異なるモデルです。zpool の順序は sda/sdb sdc/sdd であると推測します (ただし逆の場合もあります)。
sda/sdcは68AX9N0です
sdb/sddは68EUZN0です

問題 2。WD20EFRX + 68AX9N0 + 68EUZN0 を Google で検索すると、次のページが見つかりました。http://forums.whirlpool.net.au/archive/2197640

68EUZN0 ドライブは約 8 秒後にヘッドをパークできるようですが、他のドライブはこの点に関してよりスマートです (またはその逆)。

したがって、NFS キャッシュ + FS キャッシュ + SSD キャッシュを考慮すると、基盤となるドライブはアイドル状態になり、ヘッドをパーキングしている可能性があります。私の推測では、NFS のキャッシュの追加レイヤーが限界を超えている原因です。

FS同期オプションを変更することでこれをテストできます。同期は非同期よりも優れている可能性があります。また、可能であれば、SSDキャッシュをオフにしてテストを再実行してください。目的は、パーキングが確実に機能することです。ない発生して結果を確認します。

ウェブページに記載されているように、駐車遅延間隔を調整できるユーティリティがいくつかあります。それがオプションである場合は、必ず徹底的に調べてください。

アップデート：

あなたの問題は、ストアアンドフォワード（配送保証付き）ネットワークを介したスループットの問題として考えることができます。ないNIC または同等のものについて話しています。

I/O 操作は、構造体に格納される要求 (読み取り/書き込み、buf_addr、buf_len など) を含むパケットのようなものだと考えてください。この要求パケット/構造体は、NFS、ZFS、デバイスドライバー、SATA コントローラー、ハードディスクなどのさまざまなキャッシュレイヤー間で渡されます。各ポイントでは、レイヤーへの到着時間と、要求が次のレイヤーに転送される出発時間があります。

この文脈では、実際に転送が行われるときの実際のディスク転送速度は、リンク速度に似ています。ほとんどの人がディスクについて考えるとき、転送速度のみを考慮し、転送が実際に開始された時間は考慮しません。

ネットワークルーターでは、パケットは到着しますが、送信リンクがクリアであっても、すぐに転送されるとは限りません。ルーターのポリシーによっては、ルーターはパケットを少し遅らせて、他のソース (UDP の場合は同じソース) からさらにパケットが到着することを期待し、小さなパケットを 1 つの大きなパケットに集約して、送信リンクでより効率的に送信できるようにすることがあります。

ディスクの場合、この「遅延」は、特定の FS レイヤーのキャッシュポリシーによって特徴付けられます。言い換えると、リクエストが T の時点でレイヤーに到着した場合、T+1 でレイヤーを出発して次のレイヤーに T+1 で到着するのではなく、T+n で出発/到着する可能性があります。FS キャッシュレイヤーは、シーク順序の最適化/ソートを実行できるように、これを実行する場合があります。

表示される動作は、輻輳のためにウィンドウが縮小された TCP ソケットと非常によく似ています。

テストを分割することが重要だと思います。現在、読み取りと書き込みを行っています。そして、どちらが制限要因/ボトルネックであるかはわかりません。テストを読み取りまたは書き込みに分割すると役立つと思います。適切なベンチマークプログラムでは、おそらくこれを実行します。私が推奨しているのは、[これらは単なる大まかな例であり、使用する正確な引数ではありません] のより洗練されたバージョンです。

書き込みの場合、time dd if=/dev/zero of=/whatever_file count=64g
読み取りの場合、time dd if=/whatever of=/dev/null count=64g

64GB の理由は、物理 RAM の 2 倍になり、ブロックキャッシュの影響を排除するためです。テスト間で sync コマンドを実行します。

これをローカル FS に適用し、NFS で繰り返します。

また、読む/dev/{sda,sdb,sdc,sdd} のそれぞれでテストする

これらのテスト中に iostat を実行します。

物理 RAW ディスクで読み取りテストを実行すると、ハードウェアが実際にどの程度の速度で実行できるかの基準値/最大値が得られることに注意してください。RAW デバイスの読み取りは、ドライブの転送仕様の最大機能に近似している必要があります。予想される書き込み速度は、ハードディスクの場合と同程度であるはずです。そうでない場合、その理由は? すべてのディスクはほぼ同じ速度でテストされるはずです。ここで私が求めているのは、以前のテストで 2 つのディスクだけが最大速度に達した理由です。

計算してみると、32GB で最大転送速度が 600MB/秒だとすると、それを満杯にしたりフラッシュしたりするには最低でも 50 秒かかります。では、パークタイムアウトはどのくらいに設定すればよいのでしょうか?

また、mem= ブートパラメータを使用してカーネルが許可する物理 RAM の量を減らすことで、状況を少し変えることができます。mem=8g などを試して、どのような効果があるかを確認してください。ブロックレイヤーキャッシュフラッシュポリシーを調整できる /proc エントリもいくつかあります。

また、私のファイルシステムはext4で、noatimeでマウントされています。zfs set atime=off ...

また、システムログも確認してください。ドライブがセンスエラーを報告し、システムがより低い転送速度を使用するように再構成する場合があります。

また、ドライブの SMART データも確認してください。何か異常な点はありませんか? 特定のドライブでソフトリトライが多すぎるなど。

前にも言ったように、ローカルディスクのパフォーマンスは期待していたよりもずっと低いです。NFS でシステム全体に取り組む前に、まずその問題を解決する必要があると思います。RAID ディスクの使用率がすべてバランスが取れていて、概ね適切であれば、それほど心配する必要はないでしょう。

私のシステム（WDC ディスクも搭載）は NFS 用に設定されていません（rsync を頻繁に使用します）。今後 1 ～ 2 日間で、緊急にやらなければならないことがあります。その後、試してみる時間があります（私自身も興味があります）。

アップデート#2:

ZFSの不均衡問題についてよく気づきました。これは私の「問題#1」を説明するのに役立ちます。かもしれない再バランス操作によって、NFS のレイテンシ/タイミングが何らかの形で混乱し、「TCP ウィンドウ/バックオフ」動作が発生すると、NFS の不安定さも説明できます。可能性はそれほど高くありませんが、それでも可能性はあります。

rsyncテストではNFSを使用する必要はありません。サーバーにssh接続できる場合はrsyncを使用します。そしてNFS は冗長です。NFS では、cp などを使用するだけです。rsync を実行するには、ssh 経由で基盤となる ZFS に直接アクセスします。これは、NFS マウントがなくても機能します [私が使用する rsync 構成は次のとおりです]:

エクスポート RSYNC_SSH="/usr/bin/ssh"
エクスポート SSH_NOCOMPRESS=1
rsync /wherever1 サーバー:/zfsmount/whatever

これをローカルホストまたはボンディングで実行すると、パフォーマンスが期待どおりになる場合があります（ZFSのアンバランスの問題を除く）。そうであれば、問題は明らかにNFSに絞り込まれます。自体。

NFS のカーネルソースを少し調べてみました。少し調べた限りでは、タイムリーさに関して気に入りませんでした。NFS はリンクが低速だった 80 年代に始まったため、NIC 帯域幅を節約するためのコードが [今でも] たくさんあります。つまり、絶対に必要な場合にのみアクションを「コミット」します。必ずしも私たちが望んでいることではありません。私の空想的なネットワークルーターポリシーのアナロジーで言えば、NFS のキャッシュは「T+n」遅延のキャッシュのようです。

NFS のキャッシュを無効にして、できるだけ早くその要求を ZFS に渡すように、できる限りのことをすることをお勧めします。ZFS をスマートにして、NFS を「ダムパイプ」にします。NFS キャッシュは、本質的に汎用的なものにしかなりません (たとえば、バックアップストアが RAID であることや、マウントされているベース FS の特殊な特性についてはあまり認識しません)。ZFS は、RAID とそれを構成するディスクについて詳細な情報を持っています。したがって、ZFS のキャッシュは、選択に関してよりインテリジェントになります。

NFS を同期マウントするようにしてみてはどうでしょうか。これでうまくいくかもしれません。また、noatime について何か見たので、そのオプションもオンにしてください。他の NFS チューニング/マウントオプションがあるかもしれません。NFS がいつもの容疑者であれば、うまく動作するように再構成できると思います。

一方、NFS を制御するオプションがない場合、rsync over ssh は実行可能な代替手段になりますか? 実際の使用例は何ですか? 高性能を必要とする大規模なバルク転送の経路として NFS を使用しているようです ([たとえば] ユーザーのホームディレクトリの自動マウントポイントとしてのみ使用するのではなく)。これは、サーバーへのクライアントバックアップなどのためですか?

Answer 1