Я работаю над несколькими виртуальными машинами Linux, разделы которых смонтированы на NetApp NAS. Этот NAS периодически испытывает очень высокий iowait, что приводит к переключению дисков виртуальной машины в режим только для чтения, сбоям или повреждению.
На КБ VMware в качестве паллиативного лечения предлагается увеличить значение тайм-аута:
echo 180 > /sys/block/sda/device/timeout
Какие могут быть негативные последствия установки очень большого тайм-аута (1800 и более)? На мой взгляд, риск состоит в том, что отложенные записи накапливаются и заполняют буфер записи ввода-вывода, что приводит к сбою системы. Следовательно, это решение может быть хуже, чем проблема.
Большинство записей, кэшируемых в грязном кэше страниц ОС, являются уже выполняется асинхронно. Другими словами, они часто не имеют ничего общего с таймаутом устройства.
Однако чтение и синхронизированная запись требуют немедленного внимания со стороны базового блочного устройства, и именно по этой причине ваша файловая система переключается в режим только для чтения (она не может записывать свой журнал на диск).
Увеличение времени ожидания ввода-вывода не должно иметь негативных последствий, но это не серебряная пуля. Например, база данных может перейти в режим только для чтения, даже если соответствующая файловая система остается в режиме чтения-записи.
Обратите внимание, что тайм-аут SCSI по умолчанию уже составляет 30 секунд. С компьютерной точки зрения это уже довольно давно :-P.
Запросы ввода-вывода (например, асинхронная запись) ограничены /sys/class/block/$DEV/nr_requests, и /sys/class/block/$DEV/max_sectors_kb. В старом блочном слое с одной очередью общее использование памяти называется 2*nr_requests*max_sectors_kb. Коэффициент 2 объясняется тем, что операции чтения и записи учитываются отдельно. Хотя вам также необходимо учитывать запросы в аппаратной очереди, см., Например, cat /sys/class/block/sda/device/queue_depth. Обычно ожидается, что максимальная глубина очереди оборудования не превышает половины nr_requests.
1) Написано, что если вашим запросам ввода-вывода требуется слишком много места, вы получите ошибки нехватки памяти. Так что вы можете взглянуть на приведенные выше значения в вашей конкретной системе. Обычно это не проблема. nr_requests по умолчанию 128. Значение по умолчанию max_sectors_kb зависит от версии вашего ядра.
Если вы используете новый уровень блоков с несколькими очередями (blk-mq), чтения и записи не учитываются отдельно. Таким образом, часть уравнения "умножение на два" исчезает, и nr-requests вместо этого по умолчанию 256. Я не уверен, как аппаратная очередь (или очереди) обрабатывается в blk-mq.
Когда очередь запросов заполнена, асинхронные записи могут накапливаться в кэше страниц, пока не достигнут «грязный предел». Исторически грязный предел по умолчанию описывается как 20% ОЗУ, хотя точное определение в настоящее время немного сложнее.
Когда вы достигнете грязного лимита, вам просто нужно подождать. У ядра нет другого жесткого тайм-аута после тайм-аута SCSI. В этом смысле общих документов по этой теме, включая базу знаний VMware, вполне достаточно. Хотя вам следует поискать конкретную документацию, относящуюся к вашему NAS :-P. Разные модели NAS были разработаны для обеспечения разного времени наихудшего случая.
2) Тем не менее, если процесс ждал ввода-вывода диска более 120 секунд, ядро выдаст предупреждение о "зависшей задаче". (Вероятно. Это обычное значение по умолчанию. За исключением моей версии Fedora Linux, где ядро, похоже, было построено без CONFIG_DETECT_HUNG_TEST. Fedora здесь выглядит странно).
Сообщение о зависании задачи не является аварийным завершением работы и не устанавливает флаг "испорченный" ядром.
После 10 предупреждений о зависании задач sys.kernel.hung_task_warnings to), ядро перестает их печатать. Думая об этом, на мой взгляд, вам также следует увеличить sysctl sys.kernel.hung_task_timeout_secs чтобы он превышал время ожидания SCSI, например 480 секунд.
3) Отдельные приложения могут иметь собственные таймауты. Вы, вероятно, предпочтете видеть тайм-аут приложения, а не возвращать ядро ошибку ввода-вывода! Ошибки ввода-вывода файловой системы обычно считаются фатальными. Сама файловая система может перемонтировать только для чтения после ошибки ввода-вывода, в зависимости от конфигурации. Ошибки ввода-вывода в устройствах подкачки или отображаемых в память файлах отправляют сигнал SIGBUS затронутому процессу, который обычно завершает процесс.
4) При использовании systemd, службы, для которых настроен сторожевой таймер, могут быть принудительно перезапущены. В текущих версиях systemd, вы можете увидеть, например, таймаут 3 минуты, если вы бежите systemctl show -p WatchdogUSec systemd-udevd. Это было увеличено четыре года назад по другой причине; похоже, это просто совпадение, что это соответствует предложенному VMware таймауту SCSI :-). Эти перезапуски могут вызвать тревожный шум журнала. systemd убивает процесс с помощью SIGABRT, с идеей получить дамп ядра, чтобы показать, где процесс застрял. Однако такие вещи, как udev и даже journald, должны быть вполне счастливы, если будут перезапущены в настоящее время.
Основная проблема заключается в том, чтобы убедиться, что вы не настроили слишком короткий сторожевой таймер перезагрузки пользовательского пространства, например RuntimeWatchdogSec= в /etc/systemd-system.conf. Даже если вы не используете своп, можно было бы systemd блокироваться дисковым вводом-выводом из-за выделения памяти, которое входит в "прямое восстановление" ядра.