web-dev-qa-db-ja.com

Rsyncがハングする：file_listポインタ配列をNバイトに拡張し、移動しました

Rsyncは、一部のファイルをローカルフォルダーからNFSフォルダーに転送した後、「割り込み可能なスリープ」モードに入ります。バックアップしようとしているフォルダには、180 GBを超えるデータが含まれています。

これは、ハングする前にrsyncが出力するものです。

[sender] expand file_list pointer array to 524288 bytes, did move

Ubuntu Server 14.04 LTSをrsyncバージョン3.1.0プロトコルバージョン31で実行していますが、rsyncを次のオプションで実行しています。

/usr/bin/rsync -rHAXxvvut --numeric-ids --progress {SRC_FOLDER} {NFS_FOLDER}

ヒントをありがとう

linuxubuntunfsrsyncubuntu-14.04
3
jithujose

使用しているrsyncがオープンソースソフトウェアであることを考えると、 関連するソースコード へのアクセスは非常に簡単です。

メインの_.tar.gz_をダウンロードし、Ubuntuパッチ（rsync_3.1.0-2ubuntu0.4.diff.gz）を適用すると、使用しているrsyncの基礎となるコードが完成します。このようなもの：

_$ mkdir rsync
$ cd rsync/
$ wget http://archive.ubuntu.com/ubuntu/pool/main/r/rsync/rsync_3.1.0.orig.tar.gz
$ wget http://archive.ubuntu.com/ubuntu/pool/main/r/rsync/rsync_3.1.0-2ubuntu0.4.diff.gz
$ gzip -d rsync_3.1.0-2ubuntu0.4.diff.gz
$ tar zxvf rsync_3.1.0.orig.tar.gz 
$ cd rsync-3.1.0/
$ patch -p1 < ../rsync_3.1.0-2ubuntu0.4.diff
_

これで、単純なgrepで、エラーメッセージのコンテキストをすばやく確認できます。

_$ grep -r 'expand file_list pointer array to' 
flist.c:        rprintf(FCLIENT, "[%s] expand file_list pointer array to %s bytes, did%s move\n",
_

エラーメッセージが単一のファイルの単一のフラグメントで使用されているため、幸運です。 Nameli：flist.c.

見てみましょう：

flist.c context

エラーメッセージを含むルーチン（行325、326、327、328）は_flist_expand_という名前で、ファイルリスト全体（rsyncへ）を適切なサイズのメモリ内構造（別名：rsyncに必要なファイルが多いほど、rsync計算を処理するために必要なメモリが多くなります。そのため、このようなリストは「事前に」わかっていないため、割り当てることによって動的に計算する必要があります。 「リスト」へのメモリの適切なチャンク（多かれ少なかれ））。

だから、私はあなたの問題があなたがrsyncしているデータのサイズに依存している[〜＃〜]ではない[〜＃〜]、しかし、ファイル数について。内部のサブフォルダーに注目して、rsyncを複数のサブrsyncに分割してみます。

実際には、次の点を調査することをお勧めします。

  1. 328行目：_(new_ptr == flist->files) ? " not" : "");_
  2. 334行目：out_of_memory("flist_expand");

しかし、これは私の最初の目標をはるかに超えています:-)

とにかく、ログを確認すると、「メモリ不足」のメッセージが表示されると思います... :-)

HTH！

1
Damiano Verzulli

役立つかもしれない2つの発言

  • 常に満足している-aオプション（man "archive mode; equals -rlptgoD（no -H、-A、-X）"から））

  • rsyncは、NFSがファイルへのアクセスを許可するのを待っている可能性があります。 NFSは実際にrsyncをロックできる（おそらく特定のファイルを上書きするとき）ようで、「スリープ」に入る直前にどのファイルがrsyncによってアクセスされているかを確認するのは興味深いでしょう。 rsyncによって現在開かれているファイルを確認するコマンドがありますlsof -ad3-999 -c rsync（from askubunt ）

0
Ring Ø

私は同じ問題を抱えており、転送をリモートで行うことで問題を回避することができました。たとえば、rsync -avvxAX source/ destination/、 やった rsync -avvxAX source/ root@localhost:destination/

rsyncはおそらくローカル転送のための特定の最適化を持っています。問題の正確な原因がわかるまでは、この回避策で問題が解決します。

私のシステム：Gentoo Linux、カーネル4.3.0、systemd、rsync 3.1.2プロトコルバージョン31

0
Priyadi

Rsyncを使用してコンテンツをNFSフォルダーに転送することは、非常に非効率的です。 rsyncがリモートファイルのチェックサムを取得したり、リモートファイルを適切に変更したりするときに必要なことを考えてください。ファイルサーバーで実行されているrsyncプロセスとrsyncで通信する方がはるかに優れています。可能であれば、最初にそれを変更してから、現在の問題がまだ存在するかどうかを確認します。つまりsshでrsyncを使用するか、rsyncデーモンプロセスを実行し、NFSを完全に除外します。

Rsyncが何をしているかを知るには、straceが役立つかもしれません：

strace -p <PID>

または、straceでrsyncを開始します。

strace rsync [rsync options] <src> <target>

PIDで実行中のプロセスにアタッチするには、root権限が必要になる場合がありますが、これは（rootによって）変更できます。

0
mc0e