実行中のXBianサーバーがあります(Raspberry PiバージョンのDebian)。同期inetdを介して(デフォルトデーモンではない)私はいくつかのディレクトリを提供しています外部4別々のモジュロファイルシステム(USBディスク)(そのモジュールには約100〜500 GBのデータと1000〜10000個のファイルがあります)最近、ファイルシステムの他の部分(アップロード、コピーなど、必ずしも上記のディレクトリではない可能性があります。 )を変更すると、これらのモジュールへのrsync呼び出しがタイムアウトすることがわかりました。
このようなルーチン rsync コマンドの場合rsync -vrt rsync://host:port/module ./
(つまり、サーバーとクライアントの両方の場所に同じデータがある場合)、ファイル転送が不要であると予想される rsync サーバーのログ・ファイルに次のログが表示されます。
2014/12/15 22:59:59 [###] connect from UNKNOWN (1.1.1.1)
2014/12/15 22:59:59 [###] rsync on share/ from UNKNOWN (1.1.1.1)
2014/12/15 22:59:59 [###] building file list
2014/12/15 23:16:23 [###] rsync: read error: Connection timed out (110)
2014/12/15 23:16:23 [###] rsync error: error in socket IO (code 10) at io.c(785) [sender=3.1.1]
クライアントログには次のログが表示されます(たとえば、同じトランスポート - サーバーは15分後にタイムアウトを報告し、クライアントは30分後にエラーを報告します)。
2014/12/15 23:00:01 [###] receiving file list
2014/12/15 23:29:26 [###] rsync: read error: Connection reset by peer (104)
2014/12/15 23:29:26 [###] rsync error: error in rsync protocol data stream (code 12) at /usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/io.c(764) [Receiver=3.0.9]
多くの問題がこのような状況を引き起こす可能性がありますが、他の問題が見つかったいくつかのファイルの最適化を実行した後、rsync転送が再び正常に完了し始めることがわかりました。その後、より多くのファイルを再度rsyncモジュールの外部ディレクトリにアップロードした後、タイムアウトリターンが表示されます。次に、タイムアウトエラーのあるログを表示するたびにデフラグを実行します(次を使用)。e4デフラグ)これで、私のシステムはrsync転送を再度正常に実行できます。
いくつかの追加の注意:
- 私のext4パーティションは現在空き容量の50%未満を使用しています。
- 他の小規模モジュールへのrsync呼び出しはタイムアウトしません。
- データ転送のない通話(例
rsync -rt rsync://host:post/module
:)もこの状態ではタイムアウトします。 - 追加のテストの後、最適化後に動作するようです。同期デフラグを再実行する前に一度正常に呼び出されました。同期呼び出しは実際にファイルの断片化を引き起こしますか? )
rsync設定を毎回デフラグする必要があるのはなぜですか。そのようなマイナーな不便が原因でrsyncが中断されないようにするにはどうすればよいですか?
答え1
tar
代わりに、/ dev / nullディレクトリの最適化を試してみてください。これによりディスクは変更されませんが、すべてのinodeがキャッシュされます。多くのファイルを含む大規模ディレクトリの場合、ext4はそのファイルをハッシュツリーにインデックス付けするため、readdir()はデフォルトでランダムな順序でファイルを返します。同じ順序で stat() を試みると、多くの照会が発生し、非常に遅くなります。
答え2
私はext3とext4のロギングシステムとext4に関するWikipediaの章に関する情報を収集してきました。割り当て遅延と潜在的なデータ損失rsync
これが断片化の潜在的な原因であると考えさせます。そのフレズが私をここに連れてきて、実際に私が要求したプロセスを説明する結果を見ました!tar
toさんの提案が/dev/null
良い解決策のようです。遅延割り当ての詳細については、リンクを読んでください。