Utilização irregular de discos no volume lógico formatado em xfs

Question

Temos um servidor de backup com 66 TB de espaço disponível, configurado da seguinte forma:

12 arrays RAID10 de 6 TB - > 12 PVs - > 1 VG - > 1 LV - > xfs

Este sistema de arquivos é usado exclusivamente para backups (através do BackupPC). Ele recebe um pouco de E / S, mas definitivamente não é tanto que o hardware tenha problemas com ele. No entanto, estamos experimentando muitos backups com falha e recentemente percebi que até mesmo a gravação de um único arquivo de 10 linhas na montagem leva > 20 segundos. Uma corrida de iostat mostra porque:

[root@lolno BackupPC]# iostat 
Linux 2.6.18-194.17.1.el5 (lolno)      06/27/2012

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          19.93    0.00    9.53   31.95    0.00   38.59

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               5.34       115.29        43.07  874600222  326773590
sda1              0.00         0.00         0.00       3586        126
sda2              5.34       115.29        43.07  874594516  326773464
sdb             207.33      3544.02      1594.70 26886233184 12097955904
sdc              11.39       844.42      1033.16 6406058328 7837945704
sdd              11.20       622.92       481.77 4725691832 3654875728
sde              15.84      1812.99      1661.13 13754015304 12601927592
sdf              14.86      1483.24       888.80 11252361120 6742733600
sdg              11.67      1020.94       746.05 7745220408 5659828008
sdh              22.60      1127.12      1424.24 8550776952 10804834600
sdi              12.66      1176.71      1043.97 8926929272 7919898000
sdj              13.50      1140.80       912.27 8654489384 6920787296
sdk              13.14      1314.36      1041.48 9971220872 7901060992
sdl              11.16       674.53       366.49 5117257008 2780306920
sdm              10.82       829.36       604.99 6291851320 4589685592
dm-0              2.82        24.81         9.80  188208594   74373432
dm-1              0.00         0.00         0.00        680          0
dm-2              2.52        50.08         5.81  379928338   44067760
dm-3              8.48        40.40        27.46  306454472  208332272
dm-4            364.33     15591.41     11799.05 118282051176 89511839936

Como você pode ver, em vez de a E / S ser distribuída uniformemente entre os discos / PVs, a grande maioria concentrou-se em um único disco. O que causaria isso?

Mais algumas informações sobre o sistema:

Ele está rodando o CentOS 5.5, com o kernel 2.6.18-194.17.1.el5

[root@lolno BackupPC]# xfs_info /data 
meta-data=/dev/mapper/backup_vg1-BackupLV isize=256    agcount=66, agsize=268435455 blks 
         =                       sectsz=4096  attr=0 
data     =                       bsize=4096   blocks=17581608960, imaxpct=25 
         =                       sunit=0      swidth=0 blks, unwritten=1 
naming   =version 2              bsize=4096   
log      =internal               bsize=4096   blocks=32768, version=2 
         =                       sectsz=4096  sunit=1 blks, lazy-count=0 
realtime =none                   extsz=4096   blocks=0, rtextents=0 


[root@lolno BackupPC]# lvdisplay -v /dev/backup_vg1/BackupLV
        Using logical volume(s) on command line
    --- Logical volume ---
    LV Name                /dev/backup_vg1/BackupLV
    VG Name                backup_vg1
    LV UUID                L8i09U-lVxh-1ETM-mNRQ-j3es-uCSI-M1xz45
    LV Write Access        read/write
    LV Status              available
    # open                 1
    LV Size                65.50 TB
    Current LE             17169540
    Segments               12
    Allocation             inherit
    Read ahead sectors     auto
    - currently set to     256
    Block device           253:4

Meu primeiro pensamento foi que isso tem algo a ver com a falta de striping no xfs, mas de acordo com link

"Ao criar sistemas de arquivos em volumes lvm ou md, o mkfs.xfs escolhe uma geometria ideal."

Então, isso não está acontecendo aqui, ou há algo mais acontecendo?

    

Answer 1

De agcount=66 , você pode ver que tem 66 Grupos de alocação (portanto, 66 possíveis encadeamentos de E / S), mas apenas 12 dispositivos de blocos físicos.

XFS irá tentar colocar cada novo diretório em um AG diferente, então se você estiver fazendo muito IO no mesmo diretório, você pode estar fazendo IO de encadeamento único para o AG , que é armazenado no dispositivo de um bloco.

Também é possível que, mesmo se você estiver fazendo IO para diferentes AGs, vários desses 66 AGs estejam no mesmo dispositivo de bloco. 66/12 = 5.5, então você pode ter até 5 threads IO escrevendo dados para 5 AGs no dispositivo de bloco subjacente.

De sunit=0 swidth=0 você pode ver que o sistema de arquivos não está ciente da matriz RAID subjacente.

Eu acho que seu sistema de arquivos foi feito incorretamente. mkfs.xfs não é tão inteligente assim.

Faça uma leitura da documentação do XFS, saiba como o sistema de arquivos está estruturado e como os dados existentes provavelmente acabarão se espalhando por essas estruturas. É um sistema de arquivos surpreendentemente fácil de entender.

Você está em uma boa posição aqui porque, na verdade, você tem dados para analisar, não está trabalhando com algumas especificações imaginárias dos desenvolvedores do aplicativo, que serão alteradas com o tempo.

Re-crie seu sistema de arquivos para melhor se adequar aos seus dados, dispositivos de bloqueio e layout de RAID. Em particular, a pergunta "Como calcular corretamente o sunit, os resultados do swidth para desempenho ideal" no FAQ será útil para você, embora definitivamente não seja a única coisa pela qual você deve prestar atenção:

• link
• link