Уменьшите повторную попытку сбойного блока / времена ожидания в Ubuntu

Я раньше не пользовался этим настраиваемым устройством, но вы, вероятно, захотите настроить eh_timeout (тайм-аут обработки ошибок) для данного диска:

[root@localhost device]# cat /sys/block/sda/device/eh_timeout
10
[root@localhost device]# 

Выше показано sda, установленное на 10 секунд. Из базы знаний Red Hat:

В некоторых конфигурациях хранилища (например, в конфигурациях с многие LUNы), код обработки ошибок SCSI может тратить большое количество время выдачи таких команд, как TEST UNIT READY на хранение без ответа. устройства. В SCSI был добавлен новый параметр sysfs, eh_timeout. объект устройства, который позволяет настроить значение таймаута для Команды TEST UNIT READY и REQUEST SENSE, используемые ошибкой SCSI код обработки. Это уменьшает количество времени, затрачиваемого на проверку этих не реагирующие устройства. Значение по умолчанию eh_timeout - 10 секунд, которое было значением таймаута, использовавшимся до добавления этой функциональности.

Отслеживайте / sys / block / / stat для интересующих вас устройств. и сравните 10-й параметр (io_ticks).

например, ticks = io_ticks - prev_ticks / seconds_deltatime / 10

Это процент доступного времени, которое диск провел в ожидании io диска.

Конечно, стоило бы проверить значение, близкое к 100%, иначе проявите себя по-настоящему умно, сравните его со средним значением для всех ваших дисков и выберите любой диск (а) выше среднего.

См. документацию по статистике блочного уровня .

Иначе используйте что-нибудь вроде Мунина и изобразите его. Вы можете заставить Munin предупреждать, если оно превышает пороговое значение, например, 90% или то, что показывает ваш график, является хорошей цифрой для предупреждения.

, например, посмотрите эти два графика Мунина, показывающие, что / dev / sdi требует внимания. В этом примере, если / dev / sdi является частью массива, из-за этого пострадает весь массив.

Если вы посмотрите на недельный график, вы увидите, что / dev / sdc тоже может работать медленно.

Я должен добавить, что / dev / sdi выше не сломан, это просто медленный диск (на самом деле зеленый диск, который кто-то добавил к массиву sata-дисков корпоративного уровня), который замедлил работу массива. Фактически неисправный диск будет торчать, как больной палец.

В общем, я бы, вероятно, пошел со сценарием, если бы у меня было время, но Мунин, если бы мне просто нужно было быстрое решение и подключение к серверу было легким.