Por que o posix.lstat está demorando tanto? (backup de duplicidade do sistema de arquivos 9p virtio)

Question

Eu tenho um sistema de arquivos montado com 9p virtio através do KVM, e estou fazendo backup usando duplicidade para um servidor SSH remoto. Eu estou tentando acelerar o processo de backup, que parece excessivamente lento para mim.

O tamanho da fonte é de 20 GB em 107.651 arquivos, que estão em um sistema de arquivos ext4 no host da máquina virtual executando o Ubuntu 14.04, em cima de um array Raid10 em um controlador 3ware usando discos de 15K (WD VelociRaptors), sem BBWC. A máquina virtual em si é o Ubuntu 12.04.5 montando os arquivos com p9 sobre virtio, driver "path", modo "mapeado", write policy "immediate". O destino sobre SSH é um servidor HP com 512 MB de BBWC ativado com discos SAS 12x de 2 TB, confirmado como sendo incrivelmente rápido.

Se tudo mais falhar, tentarei executar a duplicidade no host da máquina virtual para eliminar a camada intermediária 9p ao acessar os arquivos para ver se 9p é o problema (que eu suspeito que seja)

Aqui estão as estatísticas de backup de duplicidade:

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

A execução python cProfile retornou as seguintes funções que levaram o tempo de execução mais longo:

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 é o problema. Executando a duplicidade no host da VM, onde os dados estão localizados, isso foi feito em 55 segundos .

Esse bug aparentemente ainda está aberto, o que fala sobre o mesmo desempenho problemas. Sugere adicionar msize = 262144 às opções de montagem, o que acelera o acesso um pouco, mas ainda está longe de ser tão tão rápido quanto o acesso direto.

Então, concluindo, não use 9p over virtio e espere alta velocidade de acesso aos arquivos. No meu caso, o aplicativo que acessa esses arquivos em 9p não é muito afetado, mas outros (como duplicidade) são.