web-dev-qa-db-ja.com

rsyncの実行に時間がかかりすぎる

ロードバランサのセットアップに2台のサーバーが含まれています。これら2つのサーバーは互いにミラーリングします。 blanacerの主な用途は、静的ファイルの提供です。それらをサーバーAとサーバーBと呼びましょう。

サーバーAは、別のネットワーク上のリモートホストからファイルを取得します。取得されるリモートファイルはコミュニティWebサイトのメディアファイルであるため、ファイルの同期を維持するには、rsyncを30分ごとに実行する必要があります。他の賢明なユーザーには壊れた画像などが表示されます。サーバーAもhttp経由でファイルを提供しています。ピーク時間は400MB/Sです。

サーバーBはサーバーA上のファイルとrsyncします。一貫性を保つために、rsyncも30分ごとに実行されます。サーバーBもhttp経由でファイルを提供しており、ピーク時間は400MB/Sです。

AとBの負荷は、8.00、8.10、7.68などの非常に高い負荷平均でした。

サーバーの負荷を減らし、rsyncの効率を向上させるためにセットアップを改善するにはどうすればよいですか？

ありがとうございました

linuxrsyncload-balancing
6
myhusky

これは、この高いプロセッサ使用率の原因によって異なります。 Rsyncがファイルのチェックサムを生成することによってプロセッサ使用率が高くなっている場合は、いくつかの対処方法があります。

チェックサムはまったく必要ない場合があります。デフォルトでは、rsyncは変更時刻とファイルサイズに基づいてファイルが異なると判断します。 「-c "オプション。チェックサムを比較してファイルが異なると判断します。チェックサムが必要ない場合は、オプションを省略してください。

チェックサムが必要な場合は、チェックサムキャッシュが機能する場合があります。同期しているファイルが頻繁に変更されない場合は、cronジョブで1日に1回チェックサムを生成でき、rsyncは生成されたチェックサムを使用します。 Rsyncは、新しいファイルや、チェックサムが作成されたときとは異なる変更時刻またはサイズを持つファイルのチェックサムを生成します。

この情報はrsync3.0.5に基づいていますが、3.0.6でも同じように機能するはずです。 rsyncを再コンパイルする必要があります。チェックサムキャッシュはパッチです。ここに私がrsyncをコンパイルするために使用したものがあります：

rsync_version="3.0.5"
scriptroot="Set this to your working directory."
mkdir -p $scriptroot/rsync-source/rsync-working
cd $scriptroot/rsync-source/rsync-working
tar xvzf ../rsync-${rsync_version}.tar.gz
tar xvzf ../rsync-patches-${rsync_version}.tar.gz
cd $scriptroot/rsync-source/rsync-working/rsync-${rsync_version}
patch -p1 < patches/checksum-reading.diff
./configure
make

次に、rsyncsumsを使用してチェックサムを生成します。 rsyncを呼び出すときは、「--sumfiles=lax "オプション。

4
Schof

多くのサイトが-avzuhをアーカイブに推奨しています。いくつかのテストの結果、変更が加えられていなくても、（500gのポータブルHDから職場から自宅へのバックアップを実行する）永遠に時間がかかるのは-z（圧縮）であることがわかりました。

-zを使用すると、約1時間（変更なし）かかり、-zを使用しない場合は約30秒かかります。

3
Brian

使用しているバージョンは記載していません。 RHEL/Centosを使用している場合、バージョン2.xでスタックしている可能性があります。 2.xの問題は、すべてのディレクトリをスキャンし、転送を行う前にファイルリストを送信することです。ツリーが十分に大きい場合、転送が実際に開始されたときにキャッシュからプッシュされるリスクがあり、その結果、ディスクアクティビティが2倍になるため、これは悪いことです。さらに、接続が不安定な場合、接続が早期に切断されるため、何も転送されません。

ただし、バージョン3.0以降では、ディレクトリ構造がスキャンされます。 RHEL/Centosで3.xにアップグレードするには、Fedora（バージョン10以下。形式が変更され、RHELとわずかに互換性がないため）SRPMを http://koji.feodraproject.org からダウンロードしました。 =、および発行：

rpmbuild --rebuild rsync.xxxx.src.rpm

両方のマシンに新しいパッケージをインストールする必要があります。

3
niXar

負荷分散とフェイルオーバー/ディザスタリカバリの両方で、私は実験を始めています [〜＃〜] drbd [〜＃〜] -ネットワーク上のRAID-1のようなものです。

Rsyncに固執し、主に静的なファイルセットをミラーリングしている場合は、この方法でrsyncにファイルリストを渡します。rsyncは、ファイルリストを作成するためにローカルファイルシステムのポーリングに最初に時間を費やすことはありません。ファイルリストは非常にクールです-リストにディレクトリを含めると、rsyncはそのディレクトリを動的にスキャンして送信します（つまり、そのディレクトリが頻繁に変更される傾向がある場合）

ミラーリング権にセカンダリNICを使用していますか？

2
DisabledLeopard

ファイル変更の頻度とファイル数によっては、変更を待ってから通知のみを送信する方がよい場合があります。これは、変更の頻度が低く、ファイルの総数が多い場合に非常に適しています。その場合、rsyncはディスクをヒットしてすべてのファイルをstat（）し、それらが変更されているかどうかを確認します。

http://inotify-tools.sourceforge.net/ は、Linuxのinotify（ファイル変更モニター）をrsyncに大まかに接続する方法に関する簡単な例（例1を参照）があります。

理想的には、これはrsync自体に統合されます（それを行った実験バージョンがどこかにあると思いますが、今は見つかりません...）

1
Rutger Nijlunsing

-vオプションを指定してrsyncを実行すると、何が実行されているか、いつ実行されているかを確認できます。また、出力をログに記録して、いつ開始していつ終了するかを確認します。

高負荷を引き起こしているのはrsyncであると確信していますか？多分それは何か他のものです。これを確認するには、rsyncを無効にするか、60分ごとにrsyncに変更して、負荷が下がるかどうかを確認します。

vmstat を使用して、サーバーの動作を確認します。大量のIOですか？それとも交換ですか？ iostatを使用して、IOを使用しているものを確認できます。多くのCPUが使用されているため、サーバーの速度が低下していますか？または多くのスワッピング？またはディスクIOがたくさんありますか？

あなたのRAMはどのようなものですか？どれくらい使用されていますか？Linuxは未使用のRAMをディスクのキャッシュとして使用します。もっとある場合はRAM I/Oは「改善」されます。

どんな種類のディスクがありますか？より多くのディスクまたはより高速なディスクを入手して、それらを襲撃することができます。これにより、パフォーマンスが向上します。

0
Rory