rsyncを使用して、約28TBのイメージを36TBのRAID 5にコピーしました。ソースにはSSDがあり、ターゲットにはRAID 5構成の6つの8TB 7200 SATA3 512eドライブがあります。
サーバーは10G光ファイバ接続を介して接続されます。それらはスイッチの唯一の2台の機械です。
ソースはCentOS 6.8で、ターゲットはUbuntu 18.04です。
HDDが600MB/sの全体の書き込み速度を得ることができないことがわかっていますが、少なくとも200MB/sの範囲を期待するとき、現在は65MB/sしか得ていません。
速度は約72 MB / sから始まり、徐々に83 MB / sに増加し、約1時間65 MB / sに低下しました。現在5日間の移行が進行中です。
これは非常に遅いようです。スピードを上げる方法の提案や、なぜそんなに遅いのかについての説明を聞きたいです。実行するコマンド：
rsync -a --info=progress2 user@sourceserver:/images/library/ /images/library
更新：
ssh + tarを使用してディレクトリをテストしました。 （rsyncの代わりに）
55秒で24Gを送信できました。これは許可されています。次に、データセット全体に適用します。前述の遅い伝送速度で急速に戻ってきました。
その後、転送を停止して単一のディレクトリテストを試みましたが、55秒で24Gに達しました。
だから、一度に1つのディレクトリごとにtar + sshスクリプトを作成しました。最初の2つのディレクトリは高速ですが、遅くなります。
最後に確認したディレクトリから17Gに20分を費やしました。
RAID 5の問題かもしれませんか？
更新：今確認した速い速度は、ページキャッシュからデータを転送するようです。 （同じディレクトリで再テストして削除しました。）新しいディレクトリを使用すると、24Gの速度が3分遅くなりました。しかし、書き込みの可能性を示すようです。
問題はソースにある可能性があると思います。 ssh + tarを使用して複数のプロセス（6）を実行してみましたが、クロールが遅かったです。 netcatを試しましたが、ssh + tarよりも高速ではありません。現在最も信頼性が高く迅速な方法は、3秒間隔で各ディレクトリを繰り返すスクリプトでssh（arcfour）+ tarを使用することです。この方法では、約6〜7分で35Gコピーが作成されます。
これまでの2泊真夜中以降、転送時間がほぼ2倍になったことを確認し、スクリプトを停止して再起動するまでその速度を維持しました。
注：ソースファイルシステムはxfsで、ターゲットファイルシステムはext4です。文が長くなってすみません。小さな28TBファイルを転送する最速の方法を見つけるのに良い練習になりそうです。
答え1
2つの点：
- まず、rsyncはデフォルトでSSHを介して機能します。それ遅い。出力を確認してくださいトップまたはトップ次の内容が表示されることがあります。
最高 - 18:04:39 最大 113 日, 3:47, ユーザー 3 人, 負荷平均: 0,50, 0,59, 0,62
タッシュ：合計489個、アンクール4個、ベール485個、アレテ0個、ゾンビ0個
%Cpu: 40,7 ut, 14,5 sy, 0,0 ni, 36,3 id, 3,4 wa, 0,0 hi, 5,1 si, 0,0 st
MiB メモリ: 合計 7976,3, 212,8 libr, 2717,9 util, 5045,7 タンプ/キャッシュ
MiB Éch: 合計 8583,0, 8381,2 libr, 201,8 util. 4598,0 メモリ割り当て
PIDユーティリティ。 PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM.
27262 emmanuel20 0 33956 7924 4204 R 58,3 0,1 0:21.51 ssh
31185 emmanuel20 0 52164 3208 2140 S 35,1 0,0 0:05.03 rsync
27249 Emmanuel20 0 1340140 158896 45432 S 8,9 1,9 4:40.63 python2
52 ルート 20 0 0 0 0 R 6,3 0,0 9:51.41 kswapd0
25149 ルート 20 0 324716 126192 63120 S 2,0 1,5 25:26.24 Xorg
25679 Emmanuel20 0 2555068 774108 100220 S 1,3 9,5 9:28.86 WebExtensions
rsync + sshがCPUをほぼ完全に捕獲するという事実に気づきましたか？
- 第二に、ターゲットアレイの種類と速度がわからない。たとえば、書き込みキャッシュが無効になっているハードウェアRAIDコントローラの場合、通常の書き込み速度がひどいことがあります。
より良いパフォーマンスを得る方法：
初期コピーの場合rsyncを使用しないでください。真剣に。同期いいですね。同期データ。ただし、これは空のターゲットを指すコピーには不十分です。前作に比べて良くなって遅くなりましたCP。だから私の提案は次のとおりです。NFS経由でcpを使用するハードウェア（最も遅い部分、ターゲットRAID、ネットワークなど）を最大限に活用できます。
ターゲットサーバーで編集/etc/export:
/mnt/raid *(rw、非同期、no_root_squash、no_subtree_check)
NFSを起動します。systemctl restart nfs-kernel-server
- ソースコンピュータからエクスポートをインストールします。
mount <server IP>:/mnt/raid /mnt/target
その後、すべてをコピーします。
cp -av /mnt/source /mnt/target
使用するのに最適画面またはマルチプレクサコピーを実行し、予期しないこと（Sshの切断など）を避けてください。
- 代替ソリューション：NFSが利用できない場合、または他のファイル共有プロトコル（CIFS / SMB、Fuse-FTP、WebDav ...）が利用できない場合は、最良のオプションは以下を使用することです。インターネット猫これと組み合わせるアスファルト。重要な部分はトラフィックを暗号化しない:
ターゲットマシンで次を実行します。インターネット猫仕える人:
cd /mnt/target ; nc -l -p 45724 | tar x
ソース側で次のコマンドを実行します。
cd /mnt/source; tar cf - * | nc <target IP> 45724
答え2
コアが多く、ネットワーク帯域幅も多いので、必要に応じて並列化することをお勧めします。複数のrsyncプロセスがそれぞれファイルセットの異なる部分を処理します。
答え3
結論は、小さなファイルが多いため、rsyncの転送速度が遅くなることです。
この場合、ストリーミング方法はより効率的です（例：ssh + tarを使用）。
更新：実際、私の場合、これは正しくありません（問題は解決されません）。私はテストとして使用するディレクトリでこれらのテストを実行しています。誰かがこれがページキャッシュにある可能性があると指摘したので、新しいディレクトリで再テストを試みたところ、速度が急激に低下しました。
答え4
私はこれがハードウェアの問題であると結論付けると信じています。この特定のサーバーは、中央ファンアセンブリなしで工場で出荷されたことがわかりました。ファンには、RAIDカードやその他のコンポーネントの空気の流れを防ぐカバーが含まれているため、サーバーの構成に必要です。この問題を解決するにはファンが必要です。これは、転送速度が徐々に遅くなる理由を説明できます。アイドル状態でもカードが目立つように暖かくなります。それ以来、中間ファンアセンブリを設置し、伝送速度は30〜40 MB / sで非常に安定しており、ギガビットネットワークで最高120 MB / sに達しました。 10Gで認証できるといいですが、もうアクセスできません。