Вопрос или проблема
У меня есть проблема: зашифрованные тома на вращающихся дисках ведут себя странно при длительных последовательных операциях (например, запись нескольких ТБ на свежесформатированную файловую систему EXT4). Произведенный объем значительно колеблется выше и ниже устойчивой пропускной способности базового устройства, и это повторяется на протяжении всей передачи.
Комбинация LVM + LUKS (в отличие от просто LUKS) усугубляет эту проблему, и в этой ситуации пропускная способность превышает устойчивую пропускную способность диска (в 2-3 раза), а затем падает до 0. Это происходит постоянно.
Я нашел статью CloudFlare, где они говорят о очередности ввода-вывода в комбинации SSD и dm-crypt. Насколько я понимаю, работающие очереди dm-crypt вызывают ухудшение производительности с SSD, так как работающие очереди должны гарантировать, что асинхронное шифрование/дешифрование не изменяет результирующий порядок ввода-вывода, и это не имеет значения для SSD, поскольку SSD не заботится о порядке ввода-вывода, а работающие очереди только добавляют дополнительную нагрузку без необходимости. Однако на вращающемся диске измененный порядок может потенциально преобразовать последовательный ввод-вывод в полупроизвольный, и это плохо для вращающегося диска, так как большее количество перемещений не способствует производительности (или работе диска).
Тем не менее, я попробовал этот обходной путь в обоих приведенных случаях:
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh <NAME>
Этот обходной путь устранил постоянные колебания пропускной способности, и устойчивое последовательное выполнение даже увеличилось на вращающихся дисках…
Я провел более контролируемую запись нескольких ТБ на EXT4 -> LUKS -> HDD, и результат показал, что включенные рабочие очереди приводят к колебаниям пропускной способности, а отключение рабочих очередей вызывает увеличение последовательной пропускной способности примерно на 10%, причём пропускная способность становится постоянной, и это ожидаемый максимум для данного диска. В основном отключение этих рабочих очередей заставляет диск вести себя так, как если бы он работал без dm-crypt/LUKS.
Поскольку это должно иметь противоположный эффект, как это вообще может работать? Случайный ввод-вывод (= больше перемещений) увеличивает последовательную производительность на вращающемся диске? Это воспроизводимо на двух разных системах (Ubuntu, Debian), с различной конфигурацией LUKS или LUKS@LVM и разными вращающимися дисками.
Отключение рабочих очередей для вращающихся дисков, похоже, работает очень хорошо, даже слишком хорошо, но это не должно работать вообще! Что я упускаю? Есть ли более подходящее решение проблемы с колебаниями пропускной способности (без отключения рабочих очередей dm-crypt)?
Ответ или решение
Проблема, с которой вы столкнулись, действительно весьма досадна и требует внимательного анализа взаимодействия различных технологий. Давайте разберем ситуацию более подробно, чтобы понять причины скачков пропускной способности и возможные способы их устранения.
Причины скачков производительности
-
Свойства жестких дисков: В отличие от SSD, жесткие диски имеют механическую часть, и их производительность сильно зависит от последовательного чтения и записи данных. При случайном доступе производительность может существенно упасть из-за времени, затрачиваемого на перемещение головки привода.
-
Рабочие очереди dm-crypt: Как вы правильно заметили, dm-crypt использует рабочие очереди для обеспечения порядка операций ввода-вывода. Это может увеличить задержки для операций записи на жесткие диски, поскольку операции могут переставляться, что приводит к более частым перемещениям головок и большим затратам времени.
Анализ вашего workaround’а
Вы обнаружили, что отключение рабочих очередей значительно улучшает стабильность и производительность операций записи на жесткие диски. Это, безусловно, может показаться необычным, поскольку традиционно ожидается, что использование рабочих очередей должно улучшать производительность. Однако в вашем случае это может быть связано с особенностями работы алгоритма шифрования и физических характеристик жесткого диска.
Почему это может работать
-
Потеря производительности от механического перемещения: Отключение рабочих очередей может уменьшить количество перемещений головки диска, так как операции записи выполняются в том же порядке, в котором они поступают. Это приводит к уменьшению случайных операций и обеспечивает более высокую общую устойчивую пропускную способность.
-
Упрощение процесса: Без дополнительных накладных расходов на управление рабочими очередями диск может быстрее выполнять заданные операции, что, как вы заметили, приводит к более предсказуемой производительности.
Рекомендации по улучшению
-
Использование других файловых систем: Рассмотрите возможность использования других файловых систем, таких как XFS или Btrfs, которые могут лучше справляться с большими объемами данных и иметь более высокую производительность на жестких дисках.
-
Оптимизация параметров dm-crypt: Если вы не хотите отключать рабочие очереди, вы можете поэкспериментировать с другими параметрами (например,
--cipher,--hashи другими), которые могут снизить нагрузку на систему. -
Мониторинг состояния диска: Проведите мониторинг состояния диска (например, с помощью smartctl), чтобы убедиться, что нет аппаратных проблем, которые могут вызывать скачки производительности.
-
Тестирование на разных системах или конфигурациях: Поскольку вы столкнулись с этой проблемой на разных системах, полезно протестировать конфигурации с другими версиями ядер, LVM и LUKS, чтобы увидеть, есть ли различия в поведении.
-
Обновление программного обеспечения: Убедитесь, что у вас установлено последние обновления для системного программного обеспечения, поскольку каждое обновление может содержать важные улучшения, касающиеся производительности.
Заключение
Ваши наблюдения имеют под собой основания, особенно в контексте специфики работы с механическими дисками. Отключение рабочих очередей действительно может оказаться оптимальным в определенных сценариях с использованием LUKS и LVM на жестких дисках. Очень важно продолжать экспериментировать с различными конфигурациями и параметрами, чтобы найти оптимальные настройки для вашего конкретного случая.