La E / S en mi software RAID6 a menudo se congela durante unos 30 segundos, después de lo cual todo vuelve a la normalidad.
Una vez finalizado el congelamiento, esto se coloca en 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)
Busqué en Google el error y alguien sugirió intentar usar 1.5Gbps en lugar de 3.0Gbps. Usando lsiutilcambié la velocidad del enlace:
# 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
Eso no ayudó.
Intenté cambiar el 'Retraso de E / S de dispositivo perdido' a 32. Eso tampoco ayudó.
Intenté cambiar / sys / class / scsi_device / * / device / timeout de 30 a 100 y luego a 3. Todo falló.
$ 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
El problema ocurre extremadamente raramente si solo hay operaciones de lectura o escritura: puedo leer o escribir 1 TB sin ningún problema. El problema parece surgir cuando hay dos operaciones de lectura y escritura. En una incursión6 eso ocurre si escribe un archivo más pequeño que el tamaño de la franja y no tiene la franja en caché ya (en cuyo caso la franja debe leerse para calcular la nueva suma de verificación).
El sistema no es una máquina virtual.
¿Qué está causando el problema? ¿Cómo me deshago de los 30 segundos de congelación?
Editar: pruebas adicionales
He encontrado un buen conjunto de pruebas que parece provocar el problema. Contiene archivos que son más pequeños que el tamaño de la banda, lo que obliga a recalcular la paridad, lo que obliga a muchas lecturas combinadas con las escrituras.
Debo admitir que no pensé que el planificador de colas tendría ningún efecto sobre este problema. Estaba equivocado. Está claro que deadlinees mucho peor que los demás. Sin embargo, ninguno de ellos resuelve el problema.
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
Cambiar el programador a noophace que el problema surja después de 100-120 segundos.
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
Cambiar el programador a deadlinehace que el problema surja después de 20-30 segundos.
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
Cambiar el programador a cfqhace que el problema surja después de 120-300 segundos.
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Edit2
Dado que el planificador tiene un efecto, estoy pensando si el problema es causado por demasiadas solicitudes en un período de tiempo. ¿Puedo de alguna manera limitar el número de solicitudes enviadas por segundo?