Почему posix.lstat занимает так много времени? (двойное резервное копирование файловой системы virtio 9p)
У меня есть файловая система, смонтированная с 9p virtio через KVM, и я делаю ее резервное копирование, используя двойственность на удаленный SSH-сервер. Я пытаюсь ускорить процесс резервного копирования, который кажется мне неоправданно медленным.
Исходный размер составляет 20 ГБ в файлах 107.651, которые находятся в файловой системе ext4 на хосте виртуальной машины под управлением Ubuntu 14.04, поверх массива Raid10 на контроллере 3ware с использованием дисков 15 КБ (WD VelociRaptors), без BBWC. Сама виртуальная машина - это Ubuntu 12.04.5, монтирующая файлы с помощью p9 поверх virtio, драйвер "путь", режим "сопоставленный", политика записи "немедленная". Назначением через SSH является сервер HP с 512 МБ BBWC с 12x 2 ТБ дисками SAS, что подтверждается невероятной скоростью.
Если ничего не помогает, я просто попробую запустить дублирование на хосте виртуальной машины, чтобы устранить доступ к файлам со средним уровнем 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}
1 ответ
9p это проблема. Выполнение дублирования на хосте VM, где расположены данные, было выполнено за 55 секунд.
Эта ошибка, видимо, все еще остается открытой, что говорит о тех же проблемах производительности. Он предлагает добавить msize=262144 к опциям монтирования, что немного ускоряет доступ, но по-прежнему далеко не так быстр, как прямой доступ.
Итак, в заключение, не используйте 9p сверх virtio и ожидайте высокую скорость доступа к файлам. В моем случае, приложение, которое получает доступ к этим файлам через 9p, не сильно подвержено влиянию, но другие (например, двойственность).