We / wy do mojego oprogramowania RAID6 często zawiesza się na około 30 sekund, po czym wszystko wraca do normy.
Po zakończeniu zamrażania jest ono umieszczane w 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)
Znalazłem błąd i ktoś zasugerował użycie 1,5 Gb / s zamiast 3,0 Gb / s. Za pomocą lsiutilzmieniłem prędkość łącza:
# 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
To nie pomogło.
Próbowałem zmienić „Device Missing I / O Delay” na 32. To też nie pomogło.
Próbowałem zmienić limit czasu / sys / class / scsi_device / * / device / timeout z 30 na 100, a następnie na 3. Wszystko nie powiodło się.
$ 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
Problem występuje niezwykle rzadko, jeśli są tylko operacje odczytu lub zapisu: bez problemu mogę odczytać lub zapisać 1 TB. Problem wydaje się pojawiać, gdy istnieją zarówno operacje odczytu, jak i zapisu. Na raid6 dzieje się tak, jeśli napiszesz plik mniejszy niż rozmiar paska, a pasek nie jest już buforowany (w takim przypadku pasek należy odczytać, aby obliczyć nową sumę kontrolną).
System nie jest maszyną wirtualną.
Co powoduje problem? Jak pozbyć się 30 sekund zamrażania?
Edycja: dodatkowe testy
Znalazłem ładny zestaw testowy, który wydaje się wywoływać problem. Zawiera pliki mniejsze niż rozmiar paska, co wymusza ponowne obliczenie parzystości, co wymusza wiele odczytów w połączeniu z zapisem.
Muszę przyznać, że nie sądziłem, że harmonogram kolejek miałby jakikolwiek wpływ na ten problem. Myliłem się. Oczywiste jest, że deadlinejest znacznie gorszy od innych. Jednak żadne z nich nie rozwiązało problemu.
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
Zmiana harmonogramu nooppowoduje, że problem pojawia się po 100-120 sekundach.
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
Zmiana harmonogramu deadlinepowoduje, że problem pojawia się po 20-30 sekundach.
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
Zmiana harmonogramu cfqpowoduje, że problem pojawia się po 120-300 sekundach.
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Edytuj2
Ponieważ harmonogram ma wpływ, zastanawiam się, czy przyczyną problemu jest zbyt wiele żądań w określonym przedziale czasowym. Czy mogę w jakiś sposób ograniczyć liczbę żądań wysyłanych na sekundę?