Linux Software RAID 5 Desempenho aleatório de pequenas gravações Abismal - Reconfiguration Advice

Question

Tenho 3 HDDs de 1 TB e 3 HDDs de 500 GB. Neste momento, cada tamanho de agrupamento está em um RAID 5, ambos em um grupo de volumes LVM (com LVs distribuídos).

Eu estou achando que isso é muito lento para o meu uso em pequenas gravações aleatórias. Eu brinquei com tamanhos de distribuição tanto no nível do RAID quanto no nível de distribuição do LVM, assim como o aumento do tamanho do buffer do stripe cache e readahead. Eu também desabilitei o NCQ conforme o conselho usual.

Então eu terminei com o Linux software raid 5. Sem um controlador dedicado, não é útil para meus propósitos.

Estou adicionando outra unidade de 1 TB e outra unidade de 500 GB para 4 de cada.

Como você configuraria as oito unidades para obter o melhor desempenho de gravação aleatória pequena? Excluindo o RAID 0 simples, é claro, já que o ponto desta configuração é obviamente também para redundância. Considerei colocar os 4 discos de 500 GB em 2 RAID 0s e adicioná-los a um RAID 10 dos outros 4 HDs de 1 TB, para um RAID 10 de 6 discos, mas não tenho certeza de que essa seja a melhor solução. O que você diz?

Editar: não há mais orçamento para atualizações de hardware. O que estou realmente perguntando é, na medida em que as quatro unidades de 1 TB podem ser RAID 10 muito diretamente, o que eu faço com as quatro unidades de 500 GB de forma que elas se encaixem melhor com a RAID 10 de 4x1TB sem se tornar um problema de desempenho ou redundância? A outra ideia que tive foi para o RAID 10 todas as quatro unidades de 500 GB juntas e depois usar o LVM para adicionar essa capacidade com o RAID10 de 4x1TB. Existe algo melhor que você possa pensar?

Outra edição: a matriz existente é formatada da seguinte forma:

1 TB ext4 formatted lvm striped file share. Shared to two Macs via AFP.
1 500 GB lvm logical volume exported via iscsi to a Mac, formatted as HFS+. Used a Time Machine backup.
1 260 GB lvm logical volume exported via iscsi to a Mac, formatted as HFS+. Used as a Time Machine backup.
1 200 GB ext4 formatted lvm partition, used a disk device for a virtualised OS installtion.
An lvm snapshot of the 500 GB time machine backup.

Uma coisa que eu não tentei é substituir os LVs do Time Machine por um arquivo no sistema de arquivos ext4 (para que a montagem iscsi aponte para o arquivo ao invés de um dispositivo de bloco). Tenho a sensação de que isso resolverá meus problemas de velocidade, mas me impedirá de tirar fotos dessas partições. Então não tenho certeza se vale a pena.

Futuramente, pretendo transferir uma biblioteca do iPhoto e do iTunes para o servidor em outra montagem iscsi HFS +, e testei como comecei a perceber o desempenho de gravação aleatória.

Se você estiver curioso, usei as informações na seção Raid Math deste URL: link para descobrir como configurar tudo para a partição ext4 (e, como resultado, estou vendo um excelente desempenho), no entanto, isso não parece ter feito nada de bom para os volumes HFS + compartilhados iscsi.

Muito mais detalhes:

 output of lvdisplay:

  --- Logical volume ---
  LV Name                /dev/array/data
  VG Name                array
  LV UUID                2Lgn1O-q1eA-E1dj-1Nfn-JS2q-lqRR-uEqzom
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                1.00 TiB
  Current LE             262144
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:0

  --- Logical volume ---
  LV Name                /dev/array/etm
  VG Name                array
  LV UUID                KSwnPb-B38S-Lu2h-sRTS-MG3T-miU2-LfCBU2
  LV Write Access        read/write
  LV snapshot status     source of
                         /dev/array/etm-snapshot [active]
  LV Status              available
  # open                 1
  LV Size                500.00 GiB
  Current LE             128000
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:1

  --- Logical volume ---
  LV Name                /dev/array/jtm
  VG Name                array
  LV UUID                wZAK5S-CseH-FtBo-5Fuf-J3le-fVed-WzjpOo
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                260.00 GiB
  Current LE             66560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:2

  --- Logical volume ---
  LV Name                /dev/array/mappingvm
  VG Name                array
  LV UUID                69k2D7-XivP-Zf4o-3SVg-QAbD-jP9W-cG8foD
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                200.00 GiB
  Current LE             51200
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:3

  --- Logical volume ---
  LV Name                /dev/array/etm-snapshot
  VG Name                array
  LV UUID                92x9Eo-yFTY-90ib-M0gA-icFP-5kC6-gd25zW
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/array/etm
  LV Status              available
  # open                 0
  LV Size                500.00 GiB
  Current LE             128000
  COW-table size         500.00 GiB
  COW-table LE           128000
  Allocated to snapshot  44.89% 
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     2048
  Block device           251:7


output of pvs --align -o pv_name,pe_start,stripe_size,stripes

PV         1st PE  Stripe  #Str
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     1
  /dev/md0   192.00k      0     0
  /dev/md11  512.00k 256.00k    2
  /dev/md11  512.00k 256.00k    2
  /dev/md11  512.00k 256.00k    2
  /dev/md11  512.00k      0     1
  /dev/md11  512.00k      0     1
  /dev/md11  512.00k      0     0
  /dev/md12  512.00k 256.00k    2
  /dev/md12  512.00k 256.00k    2
  /dev/md12  512.00k 256.00k    2
  /dev/md12  512.00k      0     0

output of cat /proc/mdstat

md12 : active raid5 sdc1[1] sde1[0] sdh1[2]
      976770560 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]

md11 : active raid5 sdg1[2] sdf1[0] sdd1[1]
      1953521152 blocks level 5, 256k chunk, algorithm 2 [3/3] [UUU]



output of  vgdisplay:


--- Volume group ---
  VG Name               array
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               3
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2.73 TiB
  PE Size               4.00 MiB
  Total PE              715402
  Alloc PE / Size       635904 / 2.43 TiB
  Free  PE / Size       79498 / 310.54 GiB
  VG UUID               PGE6Oz-jh96-B0Qc-zN9e-LKKX-TK6y-6olGJl



output of dumpe2fs /dev/array/data | head -n 100 (or so)

dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /mnt/array/data
Filesystem UUID:          b03e8fbb-19e5-479e-a62a-0dca0d1ba567
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              67108864
Block count:              268435456
Reserved block count:     13421772
Free blocks:              113399226
Free inodes:              67046222
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      960
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              128
RAID stripe width:        128
Flex block group size:    16
Filesystem created:       Thu Jul 29 22:51:26 2010
Last mount time:          Sun Oct 31 14:26:40 2010
Last write time:          Sun Oct 31 14:26:40 2010
Mount count:              1
Maximum mount count:      22
Last checked:             Sun Oct 31 14:10:06 2010
Check interval:           15552000 (6 months)
Next check after:         Fri Apr 29 14:10:06 2011
Lifetime writes:          677 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      9e6a9db2-c179-495a-bd1a-49dfb57e4020
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000059af
Journal start:            1




output of lvs array --aligned -o seg_all,lv_all

  Type    #Str Stripe  Stripe  Region Region Chunk Chunk Start Start SSize   Seg Tags PE Ranges                                       Devices                             LV UUID                                LV           Attr   Maj Min Rahead KMaj KMin KRahead LSize   #Seg Origin OSize   Snap%  Copy%  Move Convert LV Tags Log Modules 
  striped    2 256.00k 256.00k     0      0     0     0     0      0   1.00t          /dev/md11:0-131071 /dev/md12:0-131071           /dev/md11(0),/dev/md12(0)           2Lgn1O-q1eA-E1dj-1Nfn-JS2q-lqRR-uEqzom data         -wi-ao  -1  -1   auto 251  0      1.00m   1.00t    1             0                                                 
  striped    2 256.00k 256.00k     0      0     0     0     0      0 500.00g          /dev/md11:131072-195071 /dev/md12:131072-195071 /dev/md11(131072),/dev/md12(131072) KSwnPb-B38S-Lu2h-sRTS-MG3T-miU2-LfCBU2 etm          owi-ao  -1  -1   auto 251  1      1.00m 500.00g    1        500.00g                                        snapshot
  linear     1      0       0      0      0  4.00k 4.00k    0      0 500.00g          /dev/md11:279552-407551                         /dev/md11(279552)                   92x9Eo-yFTY-90ib-M0gA-icFP-5kC6-gd25zW etm-snapshot swi-a-  -1  -1   auto 251  7      1.00m 500.00g    1 etm    500.00g  44.89                                 snapshot
  striped    2 256.00k 256.00k     0      0     0     0     0      0 260.00g          /dev/md11:195072-228351 /dev/md12:195072-228351 /dev/md11(195072),/dev/md12(195072) wZAK5S-CseH-FtBo-5Fuf-J3le-fVed-WzjpOo jtm          -wi-ao  -1  -1   auto 251  2      1.00m 260.00g    1             0                                                 
  linear     1      0       0      0      0     0     0     0      0 200.00g          /dev/md11:228352-279551                         /dev/md11(228352)                   69k2D7-XivP-Zf4o-3SVg-QAbD-jP9W-cG8foD mappingvm    -wi-a-  -1  -1   auto 251  3      1.00m 200.00g    1             0                                                 




cat /sys/block/md11/queue/logical_block_size 
512
cat /sys/block/md11/queue/physical_block_size 
512
cat /sys/block/md11/queue/optimal_io_size 
524288
cat /sys/block/md11/queue/minimum_io_size 
262144

cat /sys/block/md12/queue/minimum_io_size 
262144
cat /sys/block/md12/queue/optimal_io_size 
524288
cat /sys/block/md12/queue/logical_block_size 
512
cat /sys/block/md12/queue/physical_block_size 
512

Edit: Então ninguém pode me dizer se há algo errado aqui? Nenhum conselho concreto em tudo? Hmmm.

    

Answer 1

Desculpe, mas o RAID 5 é SEMPRE ruim para pequenas gravações, a menos que o controlador tenha muito cache. Há muitas leituras e gravações para a soma de verificação.

A melhor cama é o Raid 10 em um controlador de hardware - para um desempenho real em GRAL, adquira algo como um adaptec e faça HALF as unidades SSD ... assim todas as leituras irão para o SSD que lhe dará toneladas de desempenho , embora as gravações obviamente tenham que ser divididas. Não tenho certeza se o Linux Software pode fazer o mesmo.

O resto depende totalmente do seu padrão de uso e basicamente - você não nos contou nada sobre isso.

    

Answer 2

Opção A.) Você precisa do espaço? Você poderia "reduzir o curso" das unidades de 1 TB para 500 GB e executar uma matriz RAID10 de 8 discos (para 2 TB de espaço utilizável). Já que você não mencionou, vou assumir que eles são todos spindles de 7200rpm, então você está olhando para ~ 400 gravações aleatórias por segundo.

Essa é a sua melhor opção de desempenho, qualquer outra coisa exigiria melhor hardware ou raid0.

Opção B.) Uma matriz RAID10 de 4 discos de unidades de 1TB, outra matriz de 4 discos de unidades de 500 GB, abrangência simples de lvm. Isso dá a você 200 iops de gravação aleatórios em um e 200 iops de gravação aleatórios no outro.

Opção C.) Uma matriz RAID10 de 8 discos dos primeiros 500 GB de todas as unidades e, em seguida, uma matriz RAID10 de 4 discos dos "back" de 500 GB das unidades de 1 TB, o lvm abrange. Isso dará um pico de 400 iops de gravação aleatória quando você estiver na seção de 8 discos do VG.

Você não nos disse realmente nada sobre o aplicativo, se é um registro de log seqüencial, é melhor para C. Se estiver dividido em pelo menos dois segmentos de escrita paralelos, prefiro a simplicidade de B (e não os junte).

    

Answer 3

Além de configurar o RAID e o LVM, você tentou um elevador de E / S de disco diferente? CFQ parece ser o padrão para muitas distribuições hoje em dia e para certas cargas de trabalho, tudo bem. Para mim, ele me mordeu muitas vezes - por exemplo, um servidor de backup fazendo backup de cerca de 20 hosts, totalizando cerca de 30 milhões de arquivos e alguns terabytes, foi surpreendentemente lento e a E / S levou muito tempo.

Depois que mudei para o agendador deadline , todas as operações nesse servidor se tornaram duas vezes mais rápidas que antes. OK, no meu caso o sistema de arquivos era (e ainda é ...) o XFS, e no passado o combo XFS + CFQ teve suas armadilhas, mas vale a pena tentar de qualquer maneira.

Se você quiser alterar o elevador de E / S imediatamente:

echo deadline >/sys/block/yourdisk/queue/scheduler

Se você quiser tornar essa mudança permanente, adicione à linha kernel em seu grub.conf - ou qualquer outro gerenciador de inicialização que você use - parâmetro elevator=deadline .

Você também pode tentar os anticipatory e noop agendadores.

    

Answer 4

O RAID 5 é intrinsecamente ruim para pequenas gravações, porque ele precisa ler cada bloco de ataque em cada unidade antes de gravar no disco. Controladores de hardware contornam isso tendo um cache de bateria que evita ter que esperar os discos procurarem. Esse cache ajudará todas as pequenas gravações, não apenas no Raid 5, mas é especialmente útil lá.

Poderia haver uma solução: tente alternar seu sistema de arquivos para journalize de dados:

tune2fs -o journal_data /dev/md0

(Isso é para ext3 obviamente)

Você também pode querer aumentar o tamanho do diário. Você pode ir ainda mais rápido usando outro dispositivo para o journalling. Normalmente, se você tiver um Raid 1 para o seu sistema e um grande Raid 5 para dados, reserve um volume no primeiro; Dessa forma, o comprometimento do periódico será muito mais rápido, já que requer metade das buscas. (man tune2fs para mais informações sobre como fazer isso)

Nota importante: eu não testei isso. Deve funcionar, mas também é possível que não dê tantas vantagens quanto teoricamente poderia.