A E / S do meu software RAID6 geralmente congela por cerca de 30 segundos, após os quais tudo está de volta ao normal.
Após o término do congelamento, isso é colocado no syslog:
Mar 14 18:43:57 server kernel: [35649.816060] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 68 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.149020] mptbase: ioc0: LogInfo(0x31140000): Originator={PL}, Code={IO Executed}, SubCode(0x0000) cb_idx mptscsih_io_done
Mar 14 18:43:58 server kernel: [35651.151962] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8807b02dfe80)
Mar 14 18:43:58 server kernel: [35651.151967] mptscsih: ioc0: attempting task abort! (sc=ffff88002a7f30c0)
Mar 14 18:43:58 server kernel: [35651.151972] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 6c 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.151981] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff88002a7f30c0)
Mar 14 18:43:58 server kernel: [35651.151984] mptscsih: ioc0: attempting task abort! (sc=ffff8804120e5ec0)
Mar 14 18:43:58 server kernel: [35651.151988] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 70 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.151996] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8804120e5ec0)
Mar 14 18:43:58 server kernel: [35651.151999] mptscsih: ioc0: attempting task abort! (sc=ffff880154afb280)
Mar 14 18:43:58 server kernel: [35651.152020] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 74 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.152029] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880154afb280)
Eu pesquisei o erro e alguém sugeriu tentar usar 1.5Gbps em vez de 3.0Gbps. Usando lsiutil alterei a velocidade do link:
# lsiutil -p 1 -i
Firmware Settings
-----------------
SAS WWID: 500605b002c0f680
Multi-pathing: Disabled
SATA Native Command Queuing: Enabled
SATA Write Caching: Enabled
SATA Maximum Queue Depth: 32
Device Missing Report Delay: 0 seconds
Device Missing I/O Delay: 0 seconds
Phy Parameters for Phynum: 0 1 2 3 4 5 6 7
Link Enabled: Yes Yes Yes Yes Yes Yes Yes Yes
Link Min Rate: 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5
Link Max Rate: 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5
SSP Initiator Enabled: Yes Yes Yes Yes Yes Yes Yes Yes
SSP Target Enabled: No No No No No No No No
Port Configuration: Auto Auto Auto Auto Auto Auto Auto Auto
Target IDs per enclosure: 1
Persistent mapping: Enabled
Physical mapping type: None
Target ID 0 reserved for boot: No
Starting slot (direct attach): 0
Target IDs (physical mapping): 8
Interrupt Coalescing: Enabled, timeout is 16 us, depth is 4
Isso não ajudou.
Eu tentei alterar o 'Device Missing I / O Delay' para 32. Isso também não ajudou.
Eu tentei alterar / sys / class / scsi_device / * / device / timeout de 30 para 100 e depois para 3. Tudo falhou.
$ uname -a
Linux server 3.2.0-0.bpo.1-amd64 #1 SMP Sat Feb 11 08:41:32 UTC 2012 x86_64 GNU/Linux
$ grep LSISAS1068E /var/log/messages
Mar 13 15:47:44 server kernel: [ 21.082363] scsi5 : ioc0: LSISAS1068E B3, FwRev=01210000h, Ports=1, MaxQ=483, IRQ=45
$ modinfo mptscsih
filename: /lib/modules/3.2.0-0.bpo.1-amd64/kernel/drivers/message/fusion/mptscsih.ko
version: 3.04.20
license: GPL
description: Fusion MPT SCSI Host driver
author: LSI Corporation
srcversion: 85D42A00FEBA3C95555E3AF
depends: scsi_mod,mptbase
intree: Y
vermagic: 3.2.0-0.bpo.1-amd64 SMP mod_unload modversions
$ cat /sys/block/sdae/device/model
ST3000DM001-9YN1
$ cat /sys/block/sdae/device/rev
CC4C
O problema acontece muito raramente se houver apenas operações de leitura ou gravação: posso ler ou escrever 1 TB sem problemas. O problema parece surgir quando existem ambas operações de leitura e gravação. Em um raid6 isso acontece se você escrever um arquivo menor que o tamanho da distribuição e você não tiver o stripe em cache já (nesse caso, a distribuição deve ser lida para computar nova soma de verificação).
O sistema não é uma máquina virtual.
O que está causando o problema? Como me livrar dos 30 segundos de congelamento?
Editar: teste adicional
Encontrei um bom conjunto de testes que parece provocar o problema. Ele contém arquivos menores que o tamanho da faixa, forçando a recomputação de paridade, forçando muitas leituras combinadas com as gravações.
Devo admitir que não achei que o agendador de filas tivesse algum efeito sobre esse problema. Eu estava errado. É claro que deadline é muito pior que os outros. Nenhum deles resolve o problema, no entanto.
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
Alterar o agendador para noop faz com que o problema surja depois de 100-120 segundos.
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
Alterar o agendador para deadline faz com que o problema apareça após 20 a 30 segundos.
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
Alterar o agendador para cfq faz com que o problema apareça após 120 a 300 segundos.
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Edit2
Como o agendador tem um efeito, estou pensando se o problema é causado por muitas solicitações em um período de tempo. Posso de alguma forma limitar o número de pedidos enviados por segundo?
Eu resolvi o problema comprando um cartão SAS2008. Ainda reclama um pouco no log, mas nunca bloqueia a E / S do disco. Também testei que suporta unidades SATA de 4 TB, enquanto o LSI-SAS1068E suporta apenas 2 TB.
Como retornarei o LSI-SAS1068E ao vendedor, não poderei experimentar outras sugestões. Por isso, fecho a questão aqui.
O As Notas de Lançamento do Driver MPTSCSIH do LSI parecem interessantes.
Major Changes For Version 2.06.75.00-1
Release Date: 12/10/2007
General Changes
Functionality
• Task Aborts for commands to a Volume are returned as FAILED and not sent to FW.
Qual versão é o seu driver? ( modinfo mptscsih )
Use este link para Seagate Informações de firmware sobre sua unidade Barracuda 3 TB. Você precisa digitar o número de série para obter detalhes.
Atualização: tente smartctl -i /dev/sdaa no teste que acabei de testar em SCSI e SATA e obtive o número de série dessa maneira.
Você já tentou alterar seus agendadores de E / S?
mccoy:/sys/block/sdb/queue # cat scheduler
noop anticipatory deadline [cfq]
mccoy:/sys/block/sdb/queue # echo noop > scheduler
mccoy:/sys/block/sdb/queue # cat scheduler
[noop] anticipatory deadline cfq
O padrão é CFQ normalmente para a maioria dos sistemas "atualmente".
Para comparar os agendadores de E / S, faça o seguinte:
Teste de leitura:
# echo 3 > /proc/sys/vm/drop_caches
Isso fará com que você esteja testando o disco e não as páginas da RAM armazenadas em cache. Isso eliminará o cache.
Teste de gravação:
Copie seus arquivos várias vezes simultaneamente. Quando as gravações estiverem concluídas, emita um sync
Se você estiver testando ambos, convém drop_caches e chamar sync quando a cópia estiver concluída. Além do agendador, há ajustes para cada agendador. Mas, um teste rápido seria mudar o agendador e tentar novamente. Se você tiver um bom controlador, noop descarregará o "Agendamento de I / O" para ele e não executará nenhum agendamento de dados no nível do sistema operacional.
De qualquer forma, vale a pena tentar e só é necessário um echo para defini-lo de volta.
Tags drivers timeout scsi linux-kernel