resultados contraditórios dd e iostat, ext4 e xfs, nos volumes do EBS

2

Estou vendo o que me parece ser um resultado contraditório quando observo o desempenho do disco com dd versus iostat em dois hosts (instâncias do EC2 com uma unidade EBS). Os hosts são idênticos, exceto que um usa ebs formatados em EXT4 e os outros ebs formatados em XFS.

Se eu observar o iostat, o host EXT4 parece superar o host XFS. TB estão fazendo aproximadamente o mesmo throughput de gravação (cerca de 25MB / s) com cerca de 100% de utilização, mas o host EXT4, em média, tem menos espera (menor latência de disco). É este menor espera que me faz dizer EXT4 está superando o XFS:

EXT4:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdf              0.00    11.00    0.00 6331.00     0.00    26.96     8.72    71.00   11.32   0.16  99.60

XFS:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdf              0.00     2.00    0.00 6211.00     0.00    27.38     9.03   144.95   23.24   0.16 100.40

Mas, se estiver usando dd para medir o desempenho, o XFS é o vencedor, já que leva muito menos tempo para concluir uma gravação totalmente síncrona. O comando é dd bs=1M count=256 if=/dev/zero of=./test conv=fdatasync :

EXT4:

2.8 MB/s

XFS:

24.0 MB/s

Qual seria a razão para o EXT4 parecer muito melhor com iostat , mas parecendo muito pior com dd ?

ATUALIZAÇÃO 25/05/2018: Depois de executar os hosts por alguns dias, dd e sync agora mostram tempos de resposta equivalentes para ext4 e xfs. Eu suspeito que isso tem a ver com uma diferença (se alguma?) Na forma como eles lidam com algo como arquivos esparsos. No primeiro dia em que os hosts estavam ativos, eles estavam ocupados instalando novos arquivos no sistema de arquivos (esse é um aplicativo de cache de grafite). Isso se acalmou onde pequenas atualizações estão sendo gravadas nesses arquivos, mas novos arquivos não estão mais sendo criados e a quantidade total de espaço em disco usado não está mais aumentando.

Portanto, deve haver algo fundamentalmente diferente na maneira como o XFS aloca novos blocos de disco em relação ao EXT4. Qualquer insight sobre o que isso poderia ser, seria bem-vindo.

    
por Michael Martinez 24.05.2018 / 00:30

1 resposta

2

Corrija-me se estiver errado, mas acredito que você use volumes do EBS.

Tente formatar a partição ext4 sem lazy initialization , pois isso pode afetar o desempenho do teste.

mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/xvdf


Volumes EBS
Vários fatores determinarão o desempenho do volume do EBS. Eles não são totalmente intuitivos.

  1. Type of the volume . IOPS provisionados io1 , uso geral gp2 , taxa de transferência otimizada HDD st1 , Cold HDD sc1 . características.

  2. Size of the volume . Geralmente, quanto maior o volume, melhor o desempenho. Com exceção do IOPS provisionado pelo EBS (io1), os volumes usam um modelo de burst [1] e o I / O pode flutuar ou cair significativamente se all I/O credits are used . Em suma, cada volume recebe, no mínimo, 100 IOPS de base e, para cada +1 GB adicionado (após ~ 33 GB), o desempenho aumentará para 3 IOPS. Além disso, o volume pode aumentar até 3000 IOPS se houver créditos de E / S suficientes disponíveis.

  • EC2 Instance type . Maior a instância, mais rápido o desempenho da rede. Também é importante se é uma instância otimizada do EBS ou não.

  • Se você restaurasse seu volume a partir de um instantâneo, teria que pré-aquecer o volume para obter o máximo desempenho. Consulte o link

  • Mais detauls:
    [1] link

    Atualização 1

    É difícil dizer por que você vê esses resultados porque não há informações suficientes em seu post para deduzir isso.

    Este modelo do CloudFormation é minha tentativa de recriar seus resultados. link

    EXT4
    wrqm/s  w/s     wMB/s   avgrq-sz    avgqu-sz    await   svctm    %util  
    0.00    528.62  66.08   255.84      127.07      217.16  1.61     85.39    
    2.69    287.21  35.86   255.71      142.20      504.73  3.52    101.01    
    0.00    285.28  35.59   255.49      134.93      462.90  3.52    100.33    
    3.02    277.52  34.54   254.89      115.54      460.62  3.51     97.32    
    0.00      0.00   0.00     0.00        0.00        0.00  0.00      0.00    
    512+0 records in  
    512+0 records out  
    536870912 bytes (537 MB) copied, 11.9003 s, 45.1 MB/s  
    
    XFS
    wrqm/s  w/s     wMB/s   avgrq-sz    avgqu-sz    await   svctm    %util
    1.68    542.28  67.44   254.07      176.84      301.59  1.66     90.47
    0.00    284.95  35.62   256.00      143.74      508.38  3.52    100.33
    0.00    285.28  35.58   255.46      184.36      609.81  3.52    100.33
    0.00    265.10  32.95   253.27      162.34      692.59  3.48     92.75
    0.00      0.00   0.00     0.00        0.00        0.00  0.00      0.00
    
    512+0 records in  
    512+0 records out  
    536870912 bytes (537 MB) copied, 11.7641 s, 45.6 MB/s  
    
    df
    Filesystem      Size  Used Avail Use% Mounted on
    devtmpfs        1.9G   72K  1.9G   1% /dev
    tmpfs           1.9G     0  1.9G   0% /dev/shm
    /dev/xvda1      9.8G  1.2G  8.5G  12% /
    /dev/xvdb       3.9G  8.1M  3.7G   1% /media/ephemeral0
    /dev/xvdf1      3.7G  520M  3.0G  15% /mnt/ext4
    /dev/xvdf2      3.9G  545M  3.3G  14% /mnt/xfs
    
    montar
    /dev/xvdf1 on /mnt/ext4 type ext4 (rw,relatime,data=ordered)
    /dev/xvdf2 on /mnt/xfs type xfs (rw,relatime,attr2,inode64,noquota)
    
        
    por 24.05.2018 / 09:38