EC2にインストールされたEBSから同じインスタンスにインストールされている別のEFSに約1TBのデータを移動しようとしています。過去2週間で、rsyncを使用して約840 GBのデータをコピーできました。 rsync を実行して残りのデータをコピーすると、htop 出力に D 状態で表示されます。 Mail Pilerを使用するEメールアーカイブサーバー。使用されるrsyncコマンドは次のとおりです。
nohup rsync -vaAP --progress /var/piler/store/* /var/efs/store | tee /root/txlog_20June.txt &
誰かがこれについて明らかにして私を助けることができますか？これを行う他の方法はありますか？または、これを行うためにrsyncを調整できますか？
ベストアンサー1
問題が何であるかを正確に言うのは難しいですが、試すことができるいくつかのアイデアは次のとおりです。
Dステータスはスリープモードではないため、これはI / O操作によって発生する可能性が高いですrsync。何らかの理由でアクセスできないファイルへの入出力を待っているようです。 EFSとEBSはどちらもリモートファイルシステムです。 NFS共有でも同様の問題が発生しました。問題を調査するには、rsyncコマンドでシステムコールトレースを開始できます。これが必要ですstrace（最初にインストールする必要があるかもしれません）。次に、次のコマンドを試してください。
strace -eopen -ostrace.log rsync ...
-eopenopen()システムコールだけが追跡されます。-ofile出力を名前付きファイルに書き込みます。file
プロセスが状態で停止するのを待ちますD。プロセスがブロックされたら、ファイルを確認できますstrace.log。内容は次のようになります。
$ tail -f strace.log
[...]
open("...", O_RDONLY|O_CLOEXEC) = 3
open("...", O_RDONLY)
open("/path/to/suspect_file", O_RDONLY)
ログの最後のエントリ（上記の例）は、中断されていない/path/to/suspect_fileスリープ状態のファイルです。rsyncこれで、rsyncからファイルを除外したり、ブロックの理由を確認したり、手動でコピーしたりできます。
注：大量のファイルをコピーするプログラムは、ほとんどの時間を休まずにスリープ状態にします。これは、プログラムが基本ファイルシステムを待つのにほとんどの時間を費やすことを意味します（CPUサイクルに比べて非常に遅い）。