web-dev-qa-db-ja.com

posix.lstatにこれほど長い時間がかかるのはなぜですか？ （9p virtioファイルシステムの重複バックアップ）

KVMを介して9pvirtioでマウントされたファイルシステムがあり、重複を使用してリモートSSHサーバーにバックアップしています。バックアッププロセスを高速化しようとしていますが、これは私には不当に遅いようです。

ソースサイズは107.651ファイルで20GBです。これは、Ubuntu 14.04を実行している仮想マシンホストのext4ファイルシステム上にあり、BBWCなしで15Kディスク（WD VelociRaptors）を使用する3wareコントローラー上のRaid10アレイ上にあります。仮想マシン自体はUbuntu12.04.5であり、virtio、ドライバー「パス」、モード「マップ」、書き込みポリシー「即時」を介してファイルをマウントします。 SSH経由の宛先は、12x 2TB SASディスクで512MBBBWCが有効になっているHPサーバーであり、非常に高速であることが確認されています。

他のすべてが失敗した場合は、仮想マシンホストで重複を実行して、ファイルにアクセスする際の9p中間層を排除し、9pが問題であるかどうかを確認します（これはゆっくりと疑っています）。

重複バックアップの統計は次のとおりです。

--------------[ Backup Statistics ]--------------
StartTime 1483275839.07 (Sun Jan  1 14:03:59 2017)
EndTime 1483332365.62 (Mon Jan  2 05:46:05 2017)
ElapsedTime 56526.55 (15 hours 42 minutes 6.55 seconds)
SourceFiles 107651
SourceFileSize 21612274293 (20.1 GB)
NewFiles 24
NewFileSize 69952 (68.3 KB)
DeletedFiles 11
ChangedFiles 38
ChangedFileSize 6825600 (6.51 MB)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 73
RawDeltaSize 47509 (46.4 KB)
TotalDestinationSizeChange 103051 (101 KB)
Errors 0

python cProfileの実行により、次の関数が最も長い実行時間を要したことが返されました。

29225254 function calls (29223127 primitive calls) in 56578.118 seconds
   ncalls   tottime  percall   cumtime  percall filename:lineno(function)
   107700 28238.712    0.262 28238.712    0.262 {posix.lstat}
   107650 28016.367    0.260 28016.367    0.260 {posix.access}
      892   190.827    0.214   190.827    0.214 {posix.listdir}
        2    49.552   24.776    49.552   24.776 {method 'readline' of 'file' objects}
       82    11.113    0.136    11.113    0.136 {open}
pythonduplicityvirtioposix9p
1
jjakob

9pが問題です。データが配置されているVMホストで重複を実行すると、55秒で実行されました。

This バグは明らかにまだ開いており、同じパフォーマンスの問題について説明しています。マウントオプションにmsize = 262144を追加することをお勧めします。これにより、アクセスが少し高速化されますが、それでも直接アクセスほど高速ではありません。

したがって、結論として、virtioではなく9pを使用せず、高いファイルアクセス速度を期待してください。私の場合、9pを介してこれらのファイルにアクセスするアプリケーションはそれほど影響を受けませんが、他のアプリケーション（重複など）は影響を受けます。

1
jjakob