Почему 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, не сильно подвержено влиянию, но другие (например, двойственность).

Другие вопросы по тегам