Я хорошо знаю, что ожидание ввода-вывода обсуждалось несколько раз на этом сайте, но все остальные темы, похоже, охватывают постоянный Задержка ввода-вывода, в то время как проблема ввода-вывода, которую нам необходимо решить на нашем сервере, возникает с нерегулярными (короткими) интервалами, но постоянно присутствует с массивными всплесками до 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/photo/my-images/600/yqm3.png/
iostat plot 2, интервал 120 мин: http://imageshack.us/photo/my-images/407/griw.png/
Поскольку у нас довольно большой кэш размером 5,5 ГБ, мы подумали, что было бы неплохо проверить, могут ли всплески ожидания ввода-вывода быть вызваны событиями промаха кеша. Поэтому мы выполнили синхронизацию, а затем очистили кеш и буферы:
echo 3 > /proc/sys/vm/drop_caches
и сразу после этого время ожидания ввода-вывода и обслуживания фактически зашкаливало, и все на машине казалось медленным. В течение следующих нескольких часов латентность восстановилась, и все было как прежде - небольшие и средние лаги в короткие, непредсказуемые интервалы.
Теперь мой вопрос: кто-нибудь знает, что может вызвать это раздражающее поведение? Это первое указание на то, что дисковый массив или контроллер рейда умирают, или что-то, что можно легко исправить перезагрузкой? (Однако в настоящий момент мы очень неохотно делаем это, потому что боимся, что диски могут не восстановиться снова.)
Любая помощь приветствуется.
Заранее спасибо, Крис.
Отредактировано для добавления: мы действительно видим, что один или два процесса переходят в состояние «D» вверху, один из которых довольно часто кажется kjournald. Однако, если я не ошибаюсь, это не указывает на процессы вызывая задержка, а скорее те затронутый по нему - поправьте меня, если я ошибаюсь. Помогает ли нам информация о непрерывно спящих процессах решить проблему?
@Andy Shinn запросил данные 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]
(Я предполагаю, что ваши диски напрямую подключены к серверу, а не, например, через NFS.)
Важно то, что ваш svctm (в iostat вывод) является чрезвычайно высокий, что указывает на аппаратную проблему с RAID или дисками. Svctm для обычных дисков должно быть около 4 (мс). Может быть меньше, но не выше.
К сожалению, smartctl вывод не информативен в вашем случае. В нем исправлены ошибки, но это может быть нормально. Долгий тест похоже, завершено нормально, но это снова безрезультатно. ST3500620SS кажется старым добрым диском серверного / рейдового типа, который должен быстро реагировать на ошибки чтения (в отличие от настольных / нерейдных дисков), поэтому это может быть более сложной аппаратной проблемой, чем просто поврежденные сектора. Попробуйте найти что-то необычное (например, высокий процент ошибок) в статистике RAID: http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS
Я предлагаю заменить диски следующим шагом.
Обновить:
Svctm более важный фактор, так как высокий util% просто следствие из svctm быть ненормально высоким.
Я видел похожую проблему, когда рабочий стол диски были установлены в Обещание RAID. Настольные диски, предназначенные для исправления ошибок чтения с помощью многих длительных повторных попыток, что способствует задержке (эти ошибки чтения могут быть вызваны каким-то другим фактором, например вибрация, что намного сильнее в серверной, чем в настольной). В отличие от этого диски, предназначенные для использования в RAID, просто быстро сообщают обо всех ошибках RAID-контроллеру, который может исправить их с помощью резервирования RAID. Кроме того, серверные диски могут быть спроектированы так, чтобы они были более механически устойчивы к постоянной сильной вибрации. Существует распространенный миф о том, что серверные диски такие же, как и настольные, только дороже, что неверно, они являются на самом деле разные.
В: Ах, что я хотел спросить: если это проблема с оборудованием, не кажется ли вам, что проблема должна быть постоянно видимой и не исчезать в течение некоторого времени? У вас есть какое-нибудь объяснение этому эффекту?
А:
У меня была очень похожая проблема. IBM ServeRaid M5110 (переименованный LSI 9265-8i) и CentOS 6.x
Первым виртуальным диском был RAID0 из 4 дисков Hitachi под брендом IBM.
Затем мы купили твердотельные накопители Samsung PM853T, установили их еще на 4 диска и создали еще один RAID0. Когда мы переключали нашу рабочую нагрузку с пластин на твердотельные накопители, каждый час ввода-вывода резко увеличивался, и все операции останавливались. Нагрузка пошла бы от обычных ~ 2 до более 80. Через пару десятков секунд все успокаивалось, и приложения продолжали работать.
На тарелках такой ситуации никогда не было.
Итак, первое впечатление - какая-то несовместимость LSI и Samsung. Через пару дней, много ломаясь в голове и отлаживая, я обнаружил, что виновником был MegaCli64. Мы запускаем его через Zabbix для мониторинга состояния дисков, но при сканировании контроллера MegaCli останавливал ожидание на SSD, десятки секунд плюс для каждого SSD, умноженного на 4 почти две минуты. В результате все операции ввода-вывода упадут до нуля, а время ожидания и загрузка резко возрастут.
Решением было найти версию MegaCli, которая не вызывала проблемы. Скачали версию с сайта IBM.