HP ML370 G5、Smart Array P400、SAS RAID 1 + 0を使用して結合されたディスク)でOpenfiler 2.3を使用しています。
OpenfilerのWebベースの構成を使用してext3パーティションからNFS共有をセットアップし、別のホストから共有をマウントすることに成功しました。両方のホストは、専用のギガビットリンクを使用して接続されます。
dd
を使用した簡単なベンチマーク:
$ dd if=/dev/zero of=outfile bs=1000 count=2000000
2000000+0 records in
2000000+0 records out
2000000000 bytes (2.0 GB) copied, 34.4737 s, 58.0 MB/s
中程度の転送速度(58.0 MB /秒)を達成できると思います。
しかし、多くの小さなファイル(.php
および.jpg
、ファイルあたり約1〜4 kB)、合計サイズ〜300 MB、cp
プロセスは約10分で終了します。
NFSは上記のような小さなファイル転送には適していませんか?または、調整が必要なパラメータはありますか?
多くの小さなファイルを転送することが、単一の大きなファイルを転送するよりも常に遅い理由はたくさんあります。読み取りの場合、ファイルはディスクの周りに分散している可能性が高く、ファイルを取得するためにあらゆる場所でシークが必要になります。 Evanが述べたように、NFS(またはそのことについては他のファイルシステム)の場合にもメタデータが含まれており、これも事態を複雑にします。
NFSマウントのrsize
およびwsize
パラメーターを増やして、パフォーマンスが少し向上するかどうかを確認できます。また、 この質問 を確認して、NFSを最小限のレイテンシに調整することをお勧めします。これは、多くの小さなファイル転送の場合に役立つ多くの役立つアドバイスがあるためです。
私はNFSの経験はあまりありませんが、他のネットワークファイル共有プロトコルを使用した経験では、「多くの小さなファイル」のシナリオでは、ほぼ例外なくパフォーマンスが低下します。ラウンドトリップのレイテンシが発生し、レイテンシが増加するファイルの大規模なグループにわたって。
XFSのような別のファイルシステムで試しましたか?小さなiSCSIブロック転送を大量に実行するときの問題をすべて解決しました。なぜだかわかりません。
また、iSCSI/NFSは通常、かなり大きなデータフレーム(ジャンボフレームなど)用に構成されているため、小さなファイルを一度に1つずつコピーする場合は、問題が発生する可能性があります。たぶんtarしてから転送するとよいでしょう。
NFSを介して小さなファイルの大きなディレクトリツリーを転送し、サーバーにログインできるようにする場合は、次のように、クライアントで自動的に抽出されるtarファイルを作成するのが最善の方法です。
tar c mydirectory | ssh user @ Host tar -xf--C destdir
このようにして、単一の「ファイル」のみがネットワークを介して転送され、ホスト上にすべてのファイルがすぐに存在します。
TCP接続(mount -t nfs -o tcp Host:/ mount/target)を使用していることを確認します。最新のシステムのパフォーマンスには影響しません。ただし、ネットワークがロードされている場合、小さなIOは大幅に改善される可能性があります。
そして、他のファイルシステムも試す必要があります。 ext3は基本的に最も遅いです。堅固でよく知られていますが、ファイルサーバーには非常に適していません。 XFSの方がはるかに優れており、reiserfsも小規模なIOではるかに優れています。
Chrisの答え と同様の解決策は、定期的にファイルをクライアントにrsyncすることです。双方向の変更を行う場合は、unisonを使用することもできます。
エヴァンの答えに追加するだけで、コピーする各ファイルのメタデータ(ディレクトリエントリなど)を作成するためのオーバーヘッドもすべてあります。