HP DL380p Gen8 (controlador p420i) I / O oddity em partições XFS

Question

Em servidores DL880 gen8 usando XFS em cima do LVM em cima do RAID 1 + 0 com 6 discos, uma carga de trabalho idêntica resulta em um aumento de dez vezes nas gravações em disco no RHEL 6 comparado ao RHEL 5, tornando os aplicativos inutilizáveis. / p>

Note que não estou olhando para otimizar o sistema de co6 tanto quanto possível, mas para entender por que o co6 se comporta de forma tão diferente e resolve isso.

vmstat / iostat

Nós temos uma configuração de replicação do MySQL, usando o mysql 5.5. Mysql escravos em servidores gen8 usando o RHEL 6 como o SO são mal executados, a inspeção com o vmstat e o iostat mostra que esses servidores fazem dez vezes a atividade de saída de página e dez vezes a quantidade de gravações no subsistema de disco. blktrace mostra que estas escritas não são iniciadas pelo mysql, mas pelo kernel.

Centos 5:

[dkaarsemaker@co5 ~]$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0     12 252668 102684 10816864    0    0     8   124    0    0  9  1 90  0  0
 1  0     12 251580 102692 10817116    0    0    48  2495 3619 5268  6  1 93  0  0
 3  0     12 252168 102692 10817848    0    0    32  2103 4323 5956  6  1 94  0  0
 3  0     12 252260 102700 10818672    0    0   128  5212 5365 8142 10  1 89  0  0

[dkaarsemaker@co5 ~]$ iostat 1
Linux 2.6.18-308.el5 (bc290bprdb-01.lhr4.prod.booking.com)  02/28/2013

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.74    0.00    0.81    0.25    0.00   90.21

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      277.76       399.60      5952.53 2890574849 43058478233
cciss/c0d0p1      0.01         0.25         0.01    1802147      61862
cciss/c0d0p2      0.00         0.01         0.00     101334      32552
cciss/c0d0p3    277.75       399.34      5952.52 2888669185 43058383819
dm-0             32.50        15.00       256.41  108511602 1854809120
dm-1            270.24       322.97      5693.34 2336270565 41183532042

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.49    0.00    0.79    0.08    0.00   91.64

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      300.00        32.00      4026.00         32       4026
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    300.00        32.00      4026.00         32       4026
dm-0              0.00         0.00         0.00          0          0
dm-1            300.00        32.00      4026.00         32       4026

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.25    0.00    0.46    0.21    0.00   95.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      507.00       160.00     10370.00        160      10370
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    507.00       160.00     10370.00        160      10370
dm-0              0.00         0.00         0.00          0          0
dm-1            507.00       160.00     10370.00        160      10370

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.33    0.00    0.50    0.08    0.00   94.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      318.00        64.00      4559.00         64       4559
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    319.00        64.00      4561.00         64       4561
dm-0              0.00         0.00         0.00          0          0
dm-1            319.00        64.00      4561.00         64       4561

E no Centos 6, um aumento de dez vezes nas gravações paginadas e em disco:

[root@co6 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 361044  52340 81965728    0    0    19  1804   36  110  1  1 98  0  0  
 0  0      0 358996  52340 81965808    0    0   272 57584 1211 3619  0  0 99  0  0  
 2  0      0 356176  52348 81966800    0    0   240 34128 2121 14017  1  0 98  0  0 
 0  1      0 351844  52364 81968848    0    0  1616 29128 3648 3985  1  1 97  1  0  
 0  0      0 353000  52364 81969296    0    0   480 44872 1441 3480  1  0 99  0  0  

[root@co6 ~]# iostat 1
Linux 2.6.32-279.22.1.el6.x86_64 (bc291bprdb-01.lhr4.prod.booking.com)  02/28/2013  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.08    0.00    0.67    0.27    0.00   97.98

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             373.48      1203.02    115203.05   11343270 1086250748
dm-0             63.63        74.92       493.63     706418    4654464
dm-1            356.48      1126.72    114709.47   10623848 1081596740

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.19    0.06    0.00   99.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             330.00        80.00     77976.00         80      77976
dm-0              0.00         0.00         0.00          0          0
dm-1            328.00        64.00     77456.00         64      77456

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.00    0.19    0.63    0.00   98.81

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             570.00      1664.00    128120.00       1664     128120
dm-0              0.00         0.00         0.00          0          0
dm-1            570.00      1664.00    128120.00       1664     128120

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.66    0.00    0.47    0.03    0.00   98.84

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             317.00       448.00     73048.00        448      73048
dm-0             34.00         0.00       272.00          0        272
dm-1            309.00       448.00     72776.00        448      72776

Limitando

Os servidores da Gen 8 usando RHEL 5 e os servidores gen 7 usando RHEL 5 ou 6 não são exibidos este problema. Além disso, o RHEL 6 com ext3 como sistema de arquivos em vez de xfs padrão não mostra o problema. O problema realmente parece estar em algum lugar entre o XFS, o hardware gen8 e o centos 6. O RHEL 6 também mostra o problema.

Editar 29/04: adicionamos o HBA qlogic à máquina G8. Usar o XFS no armazenamento de canal de fibra não mostra o problema. Então, é definitivamente algo na interação entre o xfs / hpsa / p420i.

XFS

O novo xfs no rhel 8 parece ser capaz de detectar a largura da faixa subjacente, mas somente nos controladores p420i usando o driver hpsa, e não os controladores p410i usando cciss.

saída xfs_info:

[root@co6 ~]# xfs_info /mysql/bp/
meta-data=/dev/mapper/sysvm-mysqlVol isize=256    agcount=16, agsize=4915136 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=78642176, imaxpct=25
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=38400, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

sunit / swidth são ambos 0 em toda a configuração marcada como OK acima. Parecemos estar incapaz de mudar isso, seja no mkfs ou com a opção de montagem noalign. Nós também não sei se esta é a causa.

Hugepages

Outras pessoas com problemas de XFS no rhel 6, dizem que desativando os abraços e Hepepages especialmente transparentes podem ser benéficas. Nós desativamos ambos, o problema não desapareceu.

Já testamos e observamos muitas coisas, mas nenhuma das seguintes ajudou:

• Usando numactl para influenciar alocações de memória. Percebemos que g7 e g8 têm um layout numa numa diferente, nenhum efeito foi visto
• Novos kernels (novos como 3.6) não parecem resolver isso. Nem o uso do fedora 17.
• O iostat não relata um aumento de dez vezes nas transações de gravação, apenas no número de bytes gravados
• Utilizar diferentes agendadores de E / S não tem efeito.
• Montar o sistema de arquivos relevante noatime / nobarrier / nopdiratime não ajudou
• Alterar / proc / sys / vm / dirty_ratio não teve efeito
• Isso acontece em sistemas baseados em 2640 e 2670 CPUs
• o hpsa-3.2.0 não corrige o problema

Answer 1

O XFS e o EL6 caíram em um estado feio ... Eu abandonei o XFS em sistemas EL6 por causa de vários recursos / alterações do upstream que estão entrando no kernel do Red Hat ...

Este foi uma surpresa e causou algum pânico: Por que meus sistemas de arquivos XFS estão subitamente consumindo mais espaço e arquivos esparsos?

Desde novembro de 2012, a versão do XFS lançada em kernels mais recentes que 2.6.32-279.11.1.el6 tem um problema de carga e desempenho irritante decorrente do Red Hat Bugzilla 860787 . Desde então, tive desempenho imprevisível e filas de execução mais altas do que a média.

Para novos sistemas, estou usando o ZFS ou apenas o ext4. Para sistemas mais antigos, estou congelando-os em 2.6.32-279.11.1.el6 .

Tente reverter para essa versão com:

yum install kernel-2.6.32-279.11.1.el6.x86_64

Além do acima, devido ao tipo de controlador RAID que você está usando, as otimizações típicas estão em ordem:

Monte seus sistemas de arquivos XFS noatime . Você também deve aproveitar a Estrutura ajustada com:

tuned-adm profile enterprise-storage

para definir readahead, nobarrier e I / O elevator para uma boa linha de base.

Editar:

Existem muitas recomendações sobre a otimização do sistema de arquivos XFS. Eu usei o sistema de arquivos exclusivamente na última década e tive que ocasionalmente ajustar os parâmetros conforme ocorriam mudanças subjacentes no sistema operacional. Eu não experimentei uma diminuição dramática no desempenho, como a sua, mas também não uso o LVM.

Acho que é irracional esperar o EL5 para agir da mesma maneira que o EL6 , dada a diferente geração do kernel, padrões compilados, agendadores, pacotes, etc.

O que eu faço neste momento ??

• Eu examinaria os parâmetros do mkfs.xfs e como você está construindo os sistemas. Você está usando o particionamento XFS durante a instalação ou criando as partições após o fato? Eu faço a criação do sistema de arquivos XFS após a instalação principal do sistema operacional porque tenho mais flexibilidade nos parâmetros fornecidos.

• Meus parâmetros de criação do mkfs.xfs são simples: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1 , por exemplo.

• Minhas opções de montagem são: noatime,logbufs=8,logbsize=256k,nobarrier Eu permitiria a pré-alocação dinâmica do XFS rodar nativamente e não restringir como você tem aqui. Meu desempenho melhorou com isso.

• Não uso o LVM . Especialmente no topo do hardware RAID ... Especialmente nos controladores HP Smart Array, onde existem algumas funções nativas do LVM para o dispositivo. No entanto, usando o LVM, você não tem acesso a fdisk para criação de partições brutas. Uma coisa que mudou de EL5 para EL6 é o alinhamento da partição no instalador e muda para o fdisk para definir o setor inicial em um limite de cilindro.

• Verifique se você está executando seus controladores e unidades HP Smart Array no nível de revisão atual. Nesse ponto, faz sentido atualizar o servidor inteiro para o atual HP Service Pack para revisão de firmware ProLiant . Este é um DVD inicializável que atualizará todos os componentes detectados no sistema.

• Eu verificaria as configurações do controlador RAID. Pastebin a saída de hpacucli ctrl all show config detail . Aqui está o meu. Você quer uma proporção de cache com tendência para escritas versus leituras. 75:25 é a norma. O tamanho padrão strip de 256K deve ser bom para esta aplicação.

• Eu potencialmente tentaria isso sem o LVM.

• Quais são seus parâmetros sysctl.conf ?

Answer 2

Tivemos o problema semelhante e descobrimos que isso se deve à alteração na versão do log do XFS. Os logs da versão 2 respeitam o conjunto de larguras de distribuição usado com o mkfs.xfs. Se você faz muito fsync, seu cartão de raid não pode mais falsificar as gravações de logs. Você pode testá-lo formatando a partição sem qualquer configuração de navegação (não faz nenhuma diferença com o RAID 1 + 0). Você pode verificar isso com o blktrace / seekwatcher para ver se envolve muita atualização de log.