Недостатки установки большого тайм-аута ввода / вывода?

Обратите внимание, что время ожидания SCSI по умолчанию уже составляет 30 секунд. Это уже довольно длительное время в компьютерном плане:

IO-запросы (например, асинхронные записи) ограничены /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 KB, вполне достаточно. Хотя вы должны искать конкретную документацию, которая относится к вашему NAS:-P. Различные винтажи NAS были спроектированы таким образом, чтобы обеспечить разные сроки наихудшего случая.

2) Тем не менее, если процесс ожидает дискового ввода-вывода в течение более 120 секунд, ядро ​​выведет предупреждение "зависшая задача". (Возможно. Это обычное значение по умолчанию. За исключением моей версии Fedora Linux, где ядро, похоже, было построено без CONFIG_DETECT_HUNG_TEST. Fedora выглядит здесь странно.)

Сообщение зависшей задачи не является сбоем и не устанавливает флаг "испорченного" ядра.

После 10 предупреждений о заданиях (или как вы sys.kernel.hung_task_warnings к) ядро ​​перестает их печатать. Думая об этом, по моему мнению, вы также должны увеличить sysctlsys.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 быть заблокированным дисковым вводом-выводом, выделением памяти, которое входит в ядро ​​"прямое восстановление".