为什么posix.lstat花了这么长时间？( 9p virtio文件系统的重复备份)
我已经通过KVM安装了一个带有9pvirtio的文件系统，并且正在使用欺骗方式将其备份到一个远程SSH服务器上。我正试图加快后备进程，对我来说，这似乎太慢了。
源代码大小为107.651个文件中的20GB，这些文件位于运行Ubuntu14.04的虚拟机主机上的ext4文件系统上，位于使用15K磁盘(WD VelociRaptors)的3ware控制器上的Raid10数组上，没有BBWC。虚拟机本身是Ubuntu12.04.5，它通过virtio、驱动程序“路径”、模式“映射”、写入策略“立即”安装p9文件。SSH上的目的地是一个HP服务器，它启用了512 to的BBWC，并启用了12x2TBSAS磁盘，确认速度非常快。
如果所有这些都失败了，我将尝试在虚拟机主机上运行的欺骗性，以消除在访问文件时的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 0python 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}回答 1
Server Fault用户
发布于 2017-01-03 14:06:52
9p是问题所在。在数据所在的VM主机上运行欺骗性，它在55秒内完成。
显然，这 bug仍然是开放的，它讨论的是相同的性能问题。它建议在挂载选项中添加msize=262144，这样可以稍微加快访问速度，但仍然远远不如直接访问快。
因此，总之，不要在virtio上使用9p，并且期望文件访问速度高。在我的示例中，通过9p访问这些文件的应用程序不会受到太大影响，但其他应用程序(如欺骗)则会受到很大影响。
https://serverfault.com/questions/823709
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号