Ich habe ein System (CentOS 7.8) mit darauf installiertem K8S.
Nach einigen Tagen normalen Betriebs (Systemlast ca. 30 % und Festplattenaktivität ca. 60 IOPS, nicht gesättigt) geht das System in einen instabilen Zustand über, in dem nichts mehr auf die Festplatte geschrieben wird. Wie aus einem ersichtlich ist iostat -x 5, friert avgqu-sz ein und es werden keine Lese-/Schreibvorgänge mehr akzeptiert.
Die Frage ist, wo ich als nächstes suchen sollte, um die Grundursache zu ermitteln.
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 169,00 0,00 0,00 0,00 0,00 100,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 186,00 0,00 0,00 0,00 0,00 100,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 7,00 0,00 0,00 0,00 0,00 100,00
avg-cpu: %user %nice %system %iowait %steal %idle
11,36 0,00 1,71 86,94 0,00 0,00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 169,00 0,00 0,00 0,00 0,00 100,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 186,00 0,00 0,00 0,00 0,00 100,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 7,00 0,00 0,00 0,00 0,00 100,00
avg-cpu: %user %nice %system %iowait %steal %idle
11,41 0,00 1,58 87,01 0,00 0,00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 169,00 0,00 0,00 0,00 0,00 100,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 186,00 0,00 0,00 0,00 0,00 100,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 7,00 0,00 0,00 0,00 0,00 100,00
Die letzten Protokollzeilen aus /var/log/messages vor einem erzwungenen Systemreset waren:
kernel: ACPI Error: SMBus/IPMI/GenericSerialBus write requires Buffer of length 66, found length 32 (20130517/exfield-389)
kernel: ACPI Error: Method parse/execution failed [\_SB_.PMI0._PMM] (Node ffff99c2ba2513c0), AE_AML_BUFFER_LIMIT (20130517/psparse-536)
kernel: ACPI Exception: AE_AML_BUFFER_LIMIT, Evaluating _PMM (20130517/power_meter-339)
obwohl es laut diesem RedHat-Thread kein Problem sein solltehttps://access.redhat.com/discussions/3871951
LE 1: Gelegentlich kommt es bei mir zu ähnlichen Einfrierungen über kurze Zeiträume (weniger als eine Minute) und dann erholt es sich. In der dmesg-Ausgabe steht:
[Lu aug 17 21:04:07 2020] hpsa 0000:06:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-1(+0) SSDSmartPathCap+ En+ Exp=1
[Lu aug 17 21:04:15 2020] hpsa 0000:06:00.0: device is ready.
[Lu aug 17 21:04:15 2020] hpsa 0000:06:00.0: scsi 0:1:0:0: reset logical completed successfully Direct-Access HP LOGICAL VOLUME RAID-1(+0) SSDSmartPathCap+ En+ Exp=1
LE 2: Es gelang, eine Dmesg-Ausgabe zu speichern, wenn die Festplatte nicht mehr wiederhergestellt werden kann und ein Reset erforderlich ist.
[Lu aug 24 13:00:18 2020] hpsa 0000:06:00.0: scsi 0:1:0:0: resetting logical Direct-Access HP LOGICAL VOLUME RAID-1(+0) SSDSmartPathCap+ En+ Exp=1
[Lu aug 24 13:03:20 2020] INFO: task scsi_eh_0:332 blocked for more than 120 seconds.
[Lu aug 24 13:03:20 2020] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Lu aug 24 13:03:20 2020] scsi_eh_0 D ffff8c603fc9acc0 0 332 2 0x00000000
[Lu aug 24 13:03:20 2020] Call Trace:
Daher startet hpsa dieses Verfahren zum Zurücksetzen des logischen Festplattenzugriffs, das nie abgeschlossen wird.
Antwort1
Das letzte Mal, als ich ein solches Symptom für das Anhalten/Pausieren der Festplatten-E/A gesehen habe, lag es an einem Festplattenproblem. Der Festplattencontroller darauf hatte wahrscheinlich angefangen zu versagen, aber die Platten waren in Ordnung.
Ich würde überprüfen, ob Sie über ein gutes Backup verfügen und da es sich um ein RAID-System handelt, überprüfen Sie, ob der SCSI-Controller auf dem neuesten Stand ist, da er die Festplatte bisher nicht als fehlerhaft gekennzeichnet hat.