rsyncのパフォーマンスとスループットの最大化-直接接続されたギガビットサーバー

CentOS 6.5を実行する2つのDell R515サーバーがあり、それぞれのBroadcom NICの1つがもう1つに直接接続されています。直接リンクを使用して、rsh over sshを使用して、ペアのメインサーバーからセカンダリにバックアップを毎晩プッシュします。トラフィックを監視すると、約2MBpsのスループットが見られますが、これはギガビットポートから予想されるよりもはるかに低いです。両側でMTUを9000に設定しましたが、何も変わらないようです。

使用可能な最大スループットに到達するための推奨される設定と最適化のセットはありますか？さらに、rsync over ssh（または潜在的に単なるNFS）を使用して数百万のファイル（〜6Tbの小さなファイル-巨大なZimbraメールストア）をコピーしているため、探している最適化は特定のユースケースにより具体的である必要があるかもしれません。

それが重要な場合、私は両側でext4を使用しています

ありがとう

編集：私は次のrsyncオプションを使用して、ほぼ同様の結果を得ました。

rsync -rtvu --delete source_folder/ destination_folder/

rsync -avHK --delete --backup --backup-dir=$BACKUPDIR source_folder/ destination_folder/

現在、cp同じダイレクトケーブルリンクを使用してNFSエクスポートに使用する場合、同じレベルのパフォーマンスの低下が見られます。

EDIT2：同期を完了した後、実行できiperf、パフォーマンスが約990Mbits / secであることがわかりました。遅延は実際に使用されているデータセットが原因でした。

ファイル数とSSH暗号化のオーバーヘッドが最大の障壁になる可能性があります。このような転送ではワイヤ速度は表示されません。

改善するオプションは次のとおりです。

• 低コストの暗号化アルゴリズムでrsync + SSHを使用する（例-e "ssh -c arcfour"）
• HPN-SSHのようなものを使用して、SSHトランスポートで暗号化を完全に排除します。
• ブロックベースの転送。スナップショット、dd、ZFSのスナップショットの送信/受信など
• これが1回限りの転送またはまれな転送である場合tar、netcat（nc）、mbuffer、またはいくつかの組み合わせを使用します。
• CentOSのtuned-adm設定を確認してください。
• ファイルシステムのマウントからatimeを削除します。他のファイルシステムのマウントオプションを調べます。
• NIC送受信バッファ。
• rsyncコマンドの調整。う-W、ここで全ファイルのオプションメイク感覚？圧縮は有効ですか？
• 転送のタイプ（SSD、スピンドル数、RAIDコントローラーキャッシュ）に合わせてストレージサブシステムを最適化します。

おそらくご存知のように、多数の小さなファイル（MailDir形式などを使用するメールボックス）をコピーすることは、高帯域幅インターフェイスを利用するための最良の選択肢ではないことは間違いありません。SSHはおそらくそのための最良のトランスポートプロトコルではありません。セカンダリホストに送信する前に、ソースホストでtarを使用してtarballを作成してみます。

tar c /var/mail | ssh root@secondary-host 'tar x -C /var/backups'

増分バックアップが必要な場合-gは、tar のオプションを試してください。それでもスループットを最大化する必要がある場合は、sshではなくnetcatを使用してみてください。

寄与因子をばらばらにしてみてください：

• CPU（たとえば、ループバックを介してパイプされる/ dev / zeroのdd）
• ディスクI / O（たとえば、catにパイプされる大きなファイルのdd > / dev / null [短絡を防ぐためにパイプされる]）
• 物理ネットワークI / O（例えば、他のマシンにパイプされるdd）
• 等

個別にテストします。

Broadcomドライバーでいくつかの悪い経験があったので、最初の提案は、使用可能なネットワーク帯域幅を次の方法でテストすることです。 dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null