为什么 posix.lstat 需要这么长时间？（9p virtio 文件系统的 duplicity 备份）

Question

我有一个通过 KVM 使用 9p virtio 安装的文件系统，并使用 duplicity 将其备份到远程 SSH 服务器。我试图加快备份过程，但对我来说，这似乎太慢了。

源文件大小为 20GB，包含 107,651 个文件，位于运行 Ubuntu 14.04 的虚拟机主机上的 ext4 文件系统上，位于使用 15K 磁盘（WD VelociRaptors）的 3ware 控制器上的 Raid10 阵列之上，没有 BBWC。虚拟机本身是 Ubuntu 12.04.5，使用 p9 通过 virtio 安装文件，驱动程序为“路径”，模式为“映射”，写入策略为“立即”。SSH 上的目标是一台启用了 512MB BBWC 的 HP 服务器，配有 12 个 2TB SAS 磁盘，速度非常快。

如果一切都失败了，我将尝试在虚拟机主机上运行 duplicity 来消除访问文件的 9p 中间层，以查看是否是 9p 的问题（我慢慢怀疑是这个问题）

以下是 duplicity 备份统计数据：

--------------[ 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}

Answer 1

9p 是问题所在。在数据所在的 VM 主机上运行 duplicity 是在55 秒。

这bug 显然仍未解决，它讨论了相同的性能问题。它建议将 msize=262144 添加到挂载选项中，这确实可以加快访问速度，但仍然离很远和直接访问一样快。

因此，总而言之，不要使用 9p 而不是 virtio 并期望高文件访问速度。就我而言，通过 9p 访问这些文件的应用程序不会受到太大影响，但其他应用程序（如 duplicity）会受到影响。