I / O cho phần mềm RAID6 của tôi thường đóng băng trong khoảng 30 giây sau đó mọi thứ trở lại bình thường.
Sau khi đóng băng xong, điều này được đưa vào 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)
Tôi đã xử lý lỗi và ai đó đề nghị thử sử dụng 1.5Gbps thay vì 3.0Gbps. Sử dụng lsiutil
tôi đã thay đổi tốc độ liên kết:
# 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
Điều đó không giúp được gì.
Tôi đã thử thay đổi 'Thiếu thiết bị trễ I / O' thành 32. Điều đó cũng không giúp được gì.
Tôi đã thử thay đổi / sys / class / scsi_device / * / device / timeout từ 30 đến 100 và sau đó đến 3. Tất cả đều thất bại.
$ 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
Vấn đề xảy ra cực kỳ hiếm khi chỉ có các thao tác đọc hoặc ghi: Tôi có thể đọc hoặc viết 1 TB mà không gặp vấn đề gì. Vấn đề dường như phát sinh khi có cả hoạt động đọc và ghi. Trên raid6 xảy ra nếu bạn viết một tệp nhỏ hơn kích thước sọc và bạn chưa có bộ đệm được lưu trong bộ đệm (trong trường hợp đó, dải phải được đọc để tính toán tổng kiểm tra mới).
Hệ thống không phải là một máy ảo.
Cái gì là nguyên nhân của vấn đề? Làm thế nào để tôi thoát khỏi 30 giây đóng băng?
Chỉnh sửa: kiểm tra bổ sung
Tôi đã tìm thấy một bộ thử nghiệm tốt mà dường như gây ra vấn đề. Nó chứa các tệp nhỏ hơn kích thước sọc do đó buộc tính toán lại tính chẵn lẻ, do đó buộc phải đọc rất nhiều kết hợp với ghi.
Tôi phải thừa nhận rằng tôi đã không nghĩ rằng bộ lập lịch xếp hàng sẽ có bất kỳ ảnh hưởng nào đến vấn đề này. Tôi đã sai. Rõ ràng deadline
là tồi tệ hơn nhiều so với những người khác. Không ai trong số họ giải quyết vấn đề, mặc dù.
# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]
Thay đổi lịch trình để noop
gây ra sự cố phát sinh sau 100-120 giây.
parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler
Thay đổi lịch trình để deadline
gây ra vấn đề phát sinh sau 20-30 giây.
parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler
Thay đổi lịch trình để cfq
gây ra sự cố phát sinh sau 120-300 giây.
parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler
Chỉnh sửa2
Vì bộ lập lịch có ảnh hưởng nên tôi nghĩ nếu sự cố xảy ra do quá nhiều yêu cầu trong khung thời gian. Tôi có thể bằng cách nào đó điều tiết số lượng yêu cầu được gửi mỗi giây không?