Странное рекуррентное чрезмерное ожидание ввода-вывода
Я хорошо знаю, что ожидание ввода-вывода обсуждалось на этом сайте несколько раз, но все остальные темы, по-видимому, охватывают постоянную задержку ввода-вывода, в то время как проблема ввода-вывода, которую нам необходимо решить на нашем сервере, возникает нерегулярно (кратко) интервалы, но всегда присутствуют с огромными пиками до 20 тыс. мс ожидания и временем обслуживания 2 секунды. Используется диск /dev/sdb (Seagate Barracuda, подробности см. Ниже).
Типичный вывод iostat -x иногда будет выглядеть следующим образом, что является крайним примером, но ни в коем случае не редким:
iostat (Oct 6, 2013)
tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
16.00 0.00 156.00 9.75 21.89 288.12 36.00 57.60
5.50 0.00 44.00 8.00 48.79 2194.18 181.82 100.00
2.00 0.00 16.00 8.00 46.49 3397.00 500.00 100.00
4.50 0.00 40.00 8.89 43.73 5581.78 222.22 100.00
14.50 0.00 148.00 10.21 13.76 5909.24 68.97 100.00
1.50 0.00 12.00 8.00 8.57 7150.67 666.67 100.00
0.50 0.00 4.00 8.00 6.31 10168.00 2000.00 100.00
2.00 0.00 16.00 8.00 5.27 11001.00 500.00 100.00
0.50 0.00 4.00 8.00 2.96 17080.00 2000.00 100.00
34.00 0.00 1324.00 9.88 1.32 137.84 4.45 59.60
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22.00 44.00 204.00 11.27 0.01 0.27 0.27 0.60
Позвольте мне предоставить вам дополнительную информацию об оборудовании. Это коробка Dell 1950 III с Debian в качестве ОС, где uname -a сообщает следующее:
Linux xx 2.6.32-5-amd64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64 GNU/Linux
Машина представляет собой выделенный сервер, на котором размещена онлайн-игра без каких-либо баз данных или тяжелых приложений ввода-вывода. Основное приложение потребляет около 0,8 из 8 ГБ ОЗУ, а средняя загрузка ЦП относительно невелика. Сама игра, однако, довольно чувствительно реагирует на задержку ввода / вывода, и поэтому наши игроки испытывают огромную задержку в игре, которую мы хотели бы устранить как можно скорее.
iostat:
avg-cpu: %user %nice %system %iowait %steal %idle
1.77 0.01 1.05 1.59 0.00 95.58
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sdb 13.16 25.42 135.12 504701011 2682640656
sda 1.52 0.74 20.63 14644533 409684488
Время работы:
19:26:26 up 229 days, 17:26, 4 users, load average: 0.36, 0.37, 0.32
Контроллер жесткого диска:
01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
Жесткие диски:
Array 1, RAID-1, 2x Seagate Cheetah 15K.5 73 GB SAS
Array 2, RAID-1, 2x Seagate ST3500620SS Barracuda ES.2 500GB 16MB 7200RPM SAS
Информация о разделе от df:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 480191156 30715200 425083668 7% /home
/dev/sda2 7692908 437436 6864692 6% /
/dev/sda5 15377820 1398916 13197748 10% /usr
/dev/sda6 39159724 19158340 18012140 52% /var
Еще несколько выборок данных, сгенерированных с помощью iostat -dx sdb 1 (11 октября 2013 г.)
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 15.00 0.00 70.00 0.00 656.00 9.37 4.50 1.83 4.80 33.60
sdb 0.00 0.00 0.00 2.00 0.00 16.00 8.00 12.00 836.00 500.00 100.00
sdb 0.00 0.00 0.00 3.00 0.00 32.00 10.67 9.96 1990.67 333.33 100.00
sdb 0.00 0.00 0.00 4.00 0.00 40.00 10.00 6.96 3075.00 250.00 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.00 0.00 0.00 100.00
sdb 0.00 0.00 0.00 2.00 0.00 16.00 8.00 2.62 4648.00 500.00 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 100.00
sdb 0.00 0.00 0.00 1.00 0.00 16.00 16.00 1.69 7024.00 1000.00 100.00
sdb 0.00 74.00 0.00 124.00 0.00 1584.00 12.77 1.09 67.94 6.94 86.00
Диаграммы характеристик, созданные с помощью rrdtool, можно найти здесь:
сюжет iostat 1, интервал 24 мин: http://imageshack.us/a/img600/2373/yqm3.png
сюжет iostat 2, интервал 120 минут: http://imageshack.us/a/img407/3197/griw.png
Поскольку у нас довольно большой кэш - 5,5 ГБ, мы подумали, что было бы неплохо проверить, не вызваны ли скачки ожидания ввода-вывода событиями пропуска кэша. Поэтому мы выполнили синхронизацию, а затем очистили кэш и буферы:
echo 3 > /proc/sys/vm/drop_caches
и непосредственно после этого время ожидания ввода-вывода и времени обслуживания практически прошло через крышу, и все на машине ощущалось как медленное движение. В течение следующих нескольких часов латентность восстановилась, и все было как прежде - небольшие и средние лаги в коротких, непредсказуемых интервалах.
Теперь мой вопрос: кто-нибудь знает, что может вызвать это раздражающее поведение? Это первый признак смерти дискового массива или контроллера рейда, или что-то, что можно легко исправить перезагрузкой? (Однако на данный момент мы очень неохотно делаем это, потому что боимся, что диски могут не вернуться снова.)
Любая помощь очень ценится.
Заранее спасибо, Крис.
Отредактировано, чтобы добавить: мы видим, что один или два процесса переходят в состояние 'D' вверху, один из которых, кажется, довольно часто kjournald. Однако, если я не ошибаюсь, это не указывает на процессы, вызывающие задержку, а скорее на те, которые влияют на это - поправьте меня, если я ошибаюсь. Помогает ли нам информация о непрерывно спящих процессах в решении проблемы?
@ Энди Шинн запросил данные Smartctl, вот они:
smartctl -a -d megaraid,2 /dev/sdb выходы:
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST3500620SS Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:13 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
Current Drive Temperature: 20 C
Drive Trip Temperature: 68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 1236631092
Blocks received from initiator = 1097862364
Blocks read from cache and sent to initiator = 1383620256
Number of read and write commands whose size <= segment size = 531295338
Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 36556.93
number of minutes until next internal SMART test = 32
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 509271032 47 0 509271079 509271079 20981.423 0
write: 0 0 0 0 0 5022.039 0
verify: 1870931090 196 0 1870931286 1870931286 100558.708 0
Non-medium error count: 0
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 36538 - [- - -]
# 2 Background short Completed 16 36514 - [- - -]
# 3 Background short Completed 16 36490 - [- - -]
# 4 Background short Completed 16 36466 - [- - -]
# 5 Background short Completed 16 36442 - [- - -]
# 6 Background long Completed 16 36420 - [- - -]
# 7 Background short Completed 16 36394 - [- - -]
# 8 Background short Completed 16 36370 - [- - -]
# 9 Background long Completed 16 36364 - [- - -]
#10 Background short Completed 16 36361 - [- - -]
#11 Background long Completed 16 2 - [- - -]
#12 Background short Completed 16 0 - [- - -]
Long (extended) Self Test duration: 6798 seconds [113.3 minutes]
smartctl -a -d megaraid,3 /dev/sdb выходы:
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST3500620SS Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:26 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
Current Drive Temperature: 19 C
Drive Trip Temperature: 68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 288745640
Blocks received from initiator = 1097848399
Blocks read from cache and sent to initiator = 1304149705
Number of read and write commands whose size <= segment size = 527414694
Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 36596.83
number of minutes until next internal SMART test = 28
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 610862490 44 0 610862534 610862534 20470.133 0
write: 0 0 0 0 0 5022.480 0
verify: 2861227413 203 0 2861227616 2861227616 100872.443 0
Non-medium error count: 1
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 36580 - [- - -]
# 2 Background short Completed 16 36556 - [- - -]
# 3 Background short Completed 16 36532 - [- - -]
# 4 Background short Completed 16 36508 - [- - -]
# 5 Background short Completed 16 36484 - [- - -]
# 6 Background long Completed 16 36462 - [- - -]
# 7 Background short Completed 16 36436 - [- - -]
# 8 Background short Completed 16 36412 - [- - -]
# 9 Background long Completed 16 36404 - [- - -]
#10 Background short Completed 16 36401 - [- - -]
#11 Background long Completed 16 2 - [- - -]
#12 Background short Completed 16 0 - [- - -]
Long (extended) Self Test duration: 6798 seconds [113.3 minutes]
3 ответа
(Я предполагаю, что ваши диски напрямую подключены к серверу, а не через NFS, например.)
Что важно, так это то, что ваш svctm (в iostat выход) очень высокий, что указывает на аппаратную проблему с RAID или дисками. Svctm для обычных дисков должно быть около 4 (мс). Может быть меньше, но не слишком высоко.
К несчастью, smartctl вывод не информативен в вашем случае. Исправлены ошибки, но это может быть нормально. Длинный тест, похоже, завершен, но это снова не дает результатов. ST3500620SS кажется хорошим старым диском типа сервер /raid, который должен быстро реагировать на ошибки чтения (в отличие от настольных / не raid дисков), так что это может быть более сложной аппаратной проблемой, чем просто поврежденные сектора. Попробуйте найти что-то необычное (например, высокий уровень ошибок) в статистике RAID: http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS
Мое предложение - замена дисков должна быть следующим шагом.
Обновление:
Svctm является более важным фактором, так как высокий коэффициент полезного использования является просто следствием ненормально высокого svctm.
Я видел подобную проблему, когда настольные диски были установлены в Promise RAID. Настольные диски, предназначенные для исправления ошибок чтения с помощью многих длительных повторных попыток, что приводит к задержке (эти ошибки чтения могут быть вызваны некоторыми другими факторами, такими как вибрация, которая намного сильнее в серверной комнате, чем на рабочем столе). В отличие от этого, диски, предназначенные для использования в RAID, просто быстро сообщают о любых ошибках в RAID-контроллер, который может исправить их с помощью избыточности RAID. Кроме того, серверные диски могут быть разработаны таким образом, чтобы они были более механически устойчивы к постоянной сильной вибрации. Существует распространенный миф о том, что серверные диски такие же, как настольные, просто дороже, что не так, на самом деле они разные.
Q: Ах, что я хотел спросить: если это аппаратная проблема, не думаете ли вы, что проблема должна быть постоянно видимой и не исчезать в течение некоторого времени? У вас есть какое-нибудь объяснение этому эффекту?
A:
- Проблема может быть всегда, но она становится заметной только при высокой нагрузке.
- Уровни вибрации могут быть разными в разное время суток (в зависимости, например, от того, что делают близлежащие серверы). Если ваша проблема связана с вибрацией дисков, она может исчезнуть и снова появиться. Я видел похожее поведение, когда у меня была проблема с дисками на рабочем столе. (Конечно, ваши диски являются серверными и рекомендованы для RAID, так что это не совсем та же проблема. Но это может быть похоже.)
У нас была аналогичная проблема, и это оказался неисправный диск SAS в массиве RAID5, обслуживаемом картой Cisco UCSC-RAID12GP-4G . Вот как мы решили проблему.
- Выясните, какой диск видит Linux, у которого зависли операции ввода-вывода. Мы использовали эту команду:
watch -n .1 "tail /sys/block/{nvme,sda}*/stat | awk '{print \$9}'"
У NVMe почти всегда были нулевые операции ввода-вывода в полете. Однако третий элемент, представляющий/dev/sdaпоказывал довольно постоянное, редко меняющееся (только постоянно увеличивающееся) значение для полета, поэтому мы знали, что это проблема с диском, экспортируемым контроллером megaraid.
- Запустите smartctl на каждом диске системы:
smartctl --scan | cut -f1 -d'#' | while read a; do echo ======= $a ; smartctl -a $a; done 2>&1|less
Мы нашли такой вариант:
======= /dev/bus/1 -d megaraid,36
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-7.86.6.1.el9uek.x86_64-TEST+] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: HGST
Product: HUH721010AL4200
Revision: A21D
Compliance: SPC-4
User Capacity: 10,000,831,348,736 bytes [10.0 TB]
Logical block size: 4096 bytes
LU is fully provisioned
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Logical Unit id: 0x5000cca266873ed8
Serial number: 7JJDBTEG
Device type: disk
Transport protocol: SAS (SPL-3)
Local Time is: Sat Sep 30 15:52:50 2023 PDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Health Status: FIRMWARE IMPENDING FAILURE DATA ERROR RATE TOO HIGH [asc=5d, ascq=62]
Итак, мы записали серийный номер диска (7JJDBTEG), вошли в консоль MegaRAID с помощью MSM и пометили диск как автономный. Сразу же начали выполняться операции ввода-вывода, и система восстановилась без перезагрузки:
МСМ также показал ошибки на диске:
У меня была очень похожая проблема. IBM ServeRaid M5110 (ребрендинг LSI 9265-8i) и CentOS 6.x
Первым VD был RAID0 из 4 дисков Hitachi под маркой IBM.
Затем мы купили твердотельные накопители Samsung PM853T, установили их еще на 4 накопителя и создали еще один RAID0. Когда мы переключали нашу рабочую нагрузку с жестких дисков на твердотельные накопители, каждые 1 час ввода-вывода просто взлетали до небес, и все операции останавливались. Загрузка будет расти от ~2 до более 80. Через пару десятков секунд все успокоится и приложения продолжат работать.
Такая ситуация никогда не происходила на тарелках.
Итак, моим первым впечатлением была какая-то несовместимость между LSI и Samsung. Через пару дней, а также много царапин и отладки, я обнаружил, что виновником является MegaCli64. Мы запускаем его через Zabbix для мониторинга работоспособности накопителей, но при сканировании контроллера MegaCli останавливает ожидание на SSD, десяток секунд плюс для каждого SSD раз в 4 почти две минуты. Это приведет к сбросу всех операций ввода-вывода в ноль, а также к ускорению загрузки и загрузки.
Решением было найти версию MegaCli, которая не вызывала проблемы. Мы скачали версию с сайта IBM.