Espera de E / S Excessiva Recorrente Estranha

Question

Eu sei muito bem que a espera de E / S foi discutida várias vezes neste site, mas todos os outros tópicos parecem cobrir a latência de E / S constante , enquanto o problema de E / S que precisamos para resolver em nosso servidor ocorre em intervalos irregulares (curtos), mas está sempre presente com picos de até 20kms de espera e tempos de serviço de 2 segundos. O disco afetado é / dev / sdb (Seagate Barracuda, para detalhes, veja abaixo).

Uma saída iostat -x típica, às vezes, se parece com isso, que é uma amostra extrema, mas não é rara:

iostat (Oct 6, 2013)
  tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
 0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
 0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
16.00      0.00    156.00      9.75     21.89    288.12     36.00     57.60
 5.50      0.00     44.00      8.00     48.79   2194.18    181.82    100.00
 2.00      0.00     16.00      8.00     46.49   3397.00    500.00    100.00
 4.50      0.00     40.00      8.89     43.73   5581.78    222.22    100.00
14.50      0.00    148.00     10.21     13.76   5909.24     68.97    100.00
 1.50      0.00     12.00      8.00      8.57   7150.67    666.67    100.00
 0.50      0.00      4.00      8.00      6.31  10168.00   2000.00    100.00
 2.00      0.00     16.00      8.00      5.27  11001.00    500.00    100.00
 0.50      0.00      4.00      8.00      2.96  17080.00   2000.00    100.00
34.00      0.00   1324.00      9.88      1.32    137.84      4.45     59.60
 0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
22.00     44.00    204.00     11.27      0.01      0.27      0.27      0.60

Deixe-me fornecer mais algumas informações sobre o hardware. É uma caixa Dell 1950 III com Debian como SO, onde uname -a relata o seguinte:

Linux xx 2.6.32-5-amd64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64 GNU/Linux

A máquina é um servidor dedicado que hospeda um jogo online sem nenhum banco de dados ou aplicativos pesados de E / S em execução. O aplicativo principal consome cerca de 0,8 da RAM de 8 GBytes e a carga média da CPU é relativamente baixa. O jogo em si, no entanto, reage bastante à latência de I / O e, portanto, nossos jogadores experimentam um atraso enorme no jogo, o qual gostaríamos de resolver o mais rápido possível.

iostat:
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.77    0.01    1.05    1.59    0.00   95.58

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb              13.16        25.42       135.12  504701011 2682640656
sda               1.52         0.74        20.63   14644533  409684488

O tempo de atividade é:

19:26:26 up 229 days, 17:26,  4 users,  load average: 0.36, 0.37, 0.32

Controlador de disco rígido:

01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

Harddisk:

Array 1, RAID-1, 2x Seagate Cheetah 15K.5 73 GB SAS
Array 2, RAID-1, 2x Seagate ST3500620SS Barracuda ES.2 500GB 16MB 7200RPM SAS

Informações de partição do df:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1            480191156  30715200 425083668   7% /home
/dev/sda2              7692908    437436   6864692   6% /
/dev/sda5             15377820   1398916  13197748  10% /usr
/dev/sda6             39159724  19158340  18012140  52% /var

Mais algumas amostras de dados geradas com iostat -dx sdb 1 (11 de outubro de 2013)

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdb               0.00    15.00    0.00   70.00     0.00   656.00     9.37     4.50    1.83   4.80  33.60
sdb               0.00     0.00    0.00    2.00     0.00    16.00     8.00    12.00  836.00 500.00 100.00
sdb               0.00     0.00    0.00    3.00     0.00    32.00    10.67     9.96 1990.67 333.33 100.00
sdb               0.00     0.00    0.00    4.00     0.00    40.00    10.00     6.96 3075.00 250.00 100.00
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     4.00    0.00   0.00 100.00
sdb               0.00     0.00    0.00    2.00     0.00    16.00     8.00     2.62 4648.00 500.00 100.00
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     2.00    0.00   0.00 100.00
sdb               0.00     0.00    0.00    1.00     0.00    16.00    16.00     1.69 7024.00 1000.00 100.00
sdb               0.00    74.00    0.00  124.00     0.00  1584.00    12.77     1.09   67.94   6.94  86.00

Os gráficos de características gerados com o rrdtool podem ser encontrados aqui:

iostat plot 1, intervalo de 24 min: link

gráfico de iostat 2, intervalo de 120 min: link

Como temos um cache bastante grande de 5,5 GBytes, achamos que seria uma boa ideia testar se os picos de espera de E / S talvez fossem causados por eventos de falta de cache. Portanto, fizemos uma sincronização e, em seguida, isso para liberar o cache e os buffers:

echo 3 > /proc/sys/vm/drop_caches

e, logo em seguida, os tempos de espera e de serviço de E / S virtualmente passaram pelo teto, e tudo na máquina parecia um movimento lento. Durante as próximas horas, a latência se recuperou e tudo estava como antes - intervalos pequenos a médios em intervalos curtos e imprevisíveis.

Agora, minha pergunta é: alguém tem alguma idéia do que poderia causar esse comportamento irritante? É a primeira indicação de que a matriz de disco ou o controlador RAID estão morrendo, ou algo que pode ser facilmente consertado com a reinicialização? (No momento, estamos muito relutantes em fazer isso, no entanto, porque temos medo de que os discos não voltem a aparecer novamente.)

Qualquer ajuda é muito apreciada.

Obrigado antecipadamente, Chris.

Editado para adicionar: vemos um ou dois processos indo para o estado 'D' no topo, um dos quais parece ser o kjournald com bastante frequência. Se não me engano, no entanto, isso não indica que os processos causam a latência, mas sim aqueles afetados por ele - corrija-me se estiver errado. As informações sobre os processos ininterruptamente adormecidos nos ajudam de alguma forma a resolver o problema?

@Andy Shinn solicitou dados smartctl, aqui está:

smartctl -a -d megaraid,2 /dev/sdb yields:

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

Device: SEAGATE  ST3500620SS      Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:13 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Current Drive Temperature:     20 C
Drive Trip Temperature:        68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
  Blocks sent to initiator = 1236631092
  Blocks received from initiator = 1097862364
  Blocks read from cache and sent to initiator = 1383620256
  Number of read and write commands whose size <= segment size = 531295338
  Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 36556.93
  number of minutes until next internal SMART test = 32

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   509271032       47         0  509271079   509271079      20981.423           0
write:         0        0         0         0          0       5022.039           0
verify: 1870931090      196         0  1870931286   1870931286     100558.708           0

Non-medium error count:        0

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                  16   36538                 - [-   -    -]
# 2  Background short  Completed                  16   36514                 - [-   -    -]
# 3  Background short  Completed                  16   36490                 - [-   -    -]
# 4  Background short  Completed                  16   36466                 - [-   -    -]
# 5  Background short  Completed                  16   36442                 - [-   -    -]
# 6  Background long   Completed                  16   36420                 - [-   -    -]
# 7  Background short  Completed                  16   36394                 - [-   -    -]
# 8  Background short  Completed                  16   36370                 - [-   -    -]
# 9  Background long   Completed                  16   36364                 - [-   -    -]
#10  Background short  Completed                  16   36361                 - [-   -    -]
#11  Background long   Completed                  16       2                 - [-   -    -]
#12  Background short  Completed                  16       0                 - [-   -    -]

Long (extended) Self Test duration: 6798 seconds [113.3 minutes]

smartctl -a -d megaraid,3 /dev/sdb yields:

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

Device: SEAGATE  ST3500620SS      Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:26 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Current Drive Temperature:     19 C
Drive Trip Temperature:        68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
  Blocks sent to initiator = 288745640
  Blocks received from initiator = 1097848399
  Blocks read from cache and sent to initiator = 1304149705
  Number of read and write commands whose size <= segment size = 527414694
  Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 36596.83
  number of minutes until next internal SMART test = 28

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   610862490       44         0  610862534   610862534      20470.133           0
write:         0        0         0         0          0       5022.480           0
verify: 2861227413      203         0  2861227616   2861227616     100872.443           0

Non-medium error count:        1

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                  16   36580                 - [-   -    -]
# 2  Background short  Completed                  16   36556                 - [-   -    -]
# 3  Background short  Completed                  16   36532                 - [-   -    -]
# 4  Background short  Completed                  16   36508                 - [-   -    -]
# 5  Background short  Completed                  16   36484                 - [-   -    -]
# 6  Background long   Completed                  16   36462                 - [-   -    -]
# 7  Background short  Completed                  16   36436                 - [-   -    -]
# 8  Background short  Completed                  16   36412                 - [-   -    -]
# 9  Background long   Completed                  16   36404                 - [-   -    -]
#10  Background short  Completed                  16   36401                 - [-   -    -]
#11  Background long   Completed                  16       2                 - [-   -    -]
#12  Background short  Completed                  16       0                 - [-   -    -]

Long (extended) Self Test duration: 6798 seconds [113.3 minutes]

    

Answer 1

(Eu suponho que seus discos estejam diretamente conectados ao servidor, e não ao NFS, por exemplo).

O que é importante é que o seu svctm (em iostat output) é extremamente alto, o que sugere problemas de hardware com RAID ou discos. Svctm para discos normais deve ser em torno de 4 (ms). Pode ser menos, mas não muito maior.

Infelizmente, smartctl output não é informativo no seu caso. Ele tem erros corrigidos, mas isso pode ser normal. Teste longo parece estar concluído OK, mas isso é inconclusivo novamente. O ST3500620SS parece ser um bom disco antigo tipo servidor / RAID, que deve responder rapidamente a erros de leitura (ao contrário dos discos desktop / não-RAID), o que poderia ser um problema de hardware mais complicado do que apenas setores defeituosos. Tente encontrar algo incomum (como altas taxas de erro) nas estatísticas de RAID: link

Minha sugestão é que a substituição de discos seja o próximo passo.

Atualizar :

O

Svctm é um fator mais importante, pois o util% é apenas conseqüência do svctm sendo anormalmente alto.

Eu vi um problema semelhante quando os discos desktop foram instalados no Promise RAID. Discos de desktop projetados para tentar reparar erros de leitura por muitas tentativas longas, o que contribui para a latência (esses erros de leitura podem ser causados por algum outro fator, como vibração , que é muito mais strong na sala do servidor Área de Trabalho). Ao contrário disso, os discos projetados para serem usados no RAID apenas reportam rapidamente quaisquer erros ao controlador RAID, o que pode corrigi-los com a redunci- ção do RAID. Além disso, os discos do servidor podem ser projetados para serem mais resistentes mecanicamente contra vibrações strongs constantes. Existe um mito comum de que os discos do servidor são os mesmos do desktop, sendo mais caros, o que é errado, eles são realmente diferentes.

Q: Ah, o que eu queria perguntar: se é um problema de hardware, você não acha que o problema deveria estar continuamente visível e não desaparecer por algum tempo? Por acaso você tem alguma explicação para esse efeito?

A:

1. O problema pode estar sempre presente, mas só é visível em alta carga.
2. Os níveis de vibração podem ser diferentes na hora diferente do dia (dependendo, por exemplo, do que os servidores próximos fazem). Se o seu problema é que os discos são afetados pela vibração, ele definitivamente pode desaparecer e reaparecer. Eu vi um comportamento semelhante quando tive meu problema de 'discos de desktop'. (Claro, seus discos são servidores e são recomendados para RAIDs, então não é exatamente o mesmo problema. Mas poderia ser similar.)

Answer 2

Eu tive um problema muito parecido. IBM ServeRaid M5110 (remarcado como LSI 9265-8i) e CentOS 6.x

O primeiro VD foi o RAID0 de 4 drives Hitachi da marca IBM.

Então compramos os SSDs Samsung PM853T e os instalamos em outros 4 drives e criamos outro RAID0. Quando trocávamos nossa carga de trabalho de pratos para SSDs, cada IO de 1 hora aumentava rapidamente, e todas as operações parariam. A carga passaria de regular ~ 2 para mais de 80. Após alguns segundos, tudo se acalmaria e os aplicativos continuariam funcionando.

Tal situação nunca ocorreu em bandejas.

Então, minha primeira impressão foi de algum tipo de incompatibilidade entre a LSI e a Samsung. Depois de alguns dias, e muita cabeça arranhando e depurando, descobri que o MegaCli64 era o culpado. Nós o rodamos via Zabbix para monitorar a saúde das unidades, mas quando a varredura do controlador, MegaCli iria parar de esperar em SSDs, dúzia de segundos mais para cada SSD vezes 4 quase dois minutos. Isso eliminaria todos os E / Ss a zero e dispararia o iowait e a carga.

A solução foi encontrar a versão MegaCli que não causou o problema. Nós baixamos a versão do site da IBM.