☰

Проблема

tag-icon • tag-icon encryption luks
Проблема

Проблема

Недавно я установил Ubuntu 16.04 LTS (ядро 4.8.0-52) на Lenovo T460p с i7-6820HQ, 32 ГБ ОЗУ и 512 ГБ SSD Micron 1100. Я установил флажок полного шифрования диска во время установки и использовал схему разбиения по умолчанию. В целом, производительность отличная.

Однако, со временем мои сборки стали выполняться примерно в два раза дольше. Кроме того, во время частей сборки, которые записывают большие файлы, любая (не связанная со сборкой) задача, требующая дискового ввода-вывода, в конечном итоге долго ждет. Это включает в себя запуск новых программ, загрузку страниц в Firefox и т. д. В Firefox, например, я могу перемещаться по пользовательскому интерфейсу, переключать вкладки, и все в порядке. Но если я перехожу по ссылке, весь пользовательский интерфейс блокируется, пока все не успокоится.

Итак, подводя итог, можно сказать, что через некоторое время сборка внезапно становится более продолжительной, а в определенные моменты сборки компьютер становится практически непригодным для использования.

Что я могу сделать, чтобы попытаться диагностировать или решить эту проблему?

Информация об устранении неполадок

  • Не перезагружайте часто, так что система часто работает несколько дней, прежде чем я сталкиваюсь с этой проблемой. Как только я сталкиваюсь с ней, я немного пытаюсь понять, в чем проблема, затем перезагружаюсь, чтобы продолжить работу.

  • Единственное, что решает проблему, — это перезагрузка машины. Я пробовал выходить из всех приложений, выходить из системы и входить снова, а также удалять кэш буфера (теория о том, что по мере использования памяти синхронизация диска происходила чаще), но помогает только перезагрузка.

  • В качестве долгосрочной перспективы я попробовал решениеэтот ответно никаких изменений в поведении не произошло.

  • Запуск iotopпоказывает, dmcrypt_writeчто поток использует 99% ввода-вывода всякий раз, когда я сталкиваюсь с проблемами. Когда янетстолкнувшись с этой проблемой, я также вижу dmcrypt_writeвсплывающее окно с относительно высоким IO %, но оно не остается там надолго.

  • Если я бегаю, dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; syncкогда все работает нормально, то dmcrypt_writeна секунду или две я подпрыгиваю наверх, но это далеко не та продолжительность, которая была во время одной из моих сборок.

  • Полная сборка генерирует около 1,4 ГБ данных. Это проект Java с несколькими модулями. Поэтому создается множество маленьких файлов плюс несколько больших JAR-файлов, которые объединяют все эти маленькие файлы.

  • Всегда достаточно свободной памяти, а раздел подкачки не используется.

  • У меня есть коллеги с похожими компьютерами (T460p), также работающими под управлением Ubuntu, которые не испытывают этой проблемы. Они, они все, похоже, имеютдругойОднако марка/модель SSD.

Обновлять

Проблема только что возникла снова, поэтому я провел еще несколько тестов на основе ответа на этот вопрос.

  • Файловая система по-прежнему не смонтирована с этой discardопцией, поэтому я вместо этого запустил ее, fstrimпредположив, что это будет похоже на включение этой discardопции.
  • Я не засек достаточно времени, когда проблема впервые возникла, но после запуска fstrimскорость сборки, похоже, вернулась к норме...нопосле завершения сборки dmcrypt_writeпоток включается и делает систему непригодной для использования в течение некоторого времени. В целом общее время сборки и время, необходимое для того, чтобы система стала пригодной к использованию, похоже, примерно такое же, как и раньше.
  • Я изменил /proc/sys/vm/dirty_ratioна 2 и /proc/sys/vm/dirty_background_ratioна 1 и запустил несколько сборок. Сборки заняли больше времени, чем обычно, — примерно столько же, сколько и в прошлый раз, когда я столкнулся с этой проблемой, но система, похоже, не так сильно зависала. Изменение обратно на 20 и 10 вернуло поведение, описанное выше.
  • При чистой загрузке я попробовал установить /proc/sys/vm/dirty_ratioзначение 2 и /proc/sys/vm/dirty_background_ratio1, и время было сопоставимо с 20 и 10.

решение1

У меня была похожая проблема на Debian 10+11, когда при выполнении больших операций записи на диск LUKS вся моя система на некоторое время зависала, затем снова отвечала, а затем снова зависала...

Мне не пришлось перезагружать компьютер — просто подождал, пока операция записи будет завершена.

Как написал ScumCoder, исправление доступно. Начиная с версии ядра 5.9 исправление интегрировано в ядро.

Следующая команда исправила это для меня:

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

Я извлек свое имя диска "nvme0n1p3_crypt" с помощью командыdmsetup table

Я черпал вдохновение изhttps://wiki.archlinux.org/title/Dm-crypt/Specialties#Отключение_очереди_работ_для_повышения_производительности_твердотельного_диска_(SSD)

После исправления мои письменные операции стали намного быстрее.

решение2

У меня точно такая же проблема, как у вас, и быстрое исследование показало этот пост:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption

Сотрудник CloudFlare провел довольно много исследований исходного кода Linux и пришел к выводу, что виновником является текущая dmcryptреализация. Он решил проблему, по сути, переписав соответствующую часть ядра.

Итак, насколько мне известно, единственными двумя способами избавиться от замедлений являются (1) компиляция его версии ядра или (2) перезагрузка время от времени (как вы сказали). Я выбрал последнее.

решение3

Не знаю конкретно о LUKS, но для решения общих проблем ввода-вывода на SSD убедитесь, что для монтирования вашей файловой системы включена функция discard, например, grep discard /proc/mounts. Также можно попробовать (как root) «echo 1 >> /proc/sys/vm/dirty_background_ratio; echo 2 >> /proc/sys/vm/dirty_ratio». Это заставит систему инициировать ввод-вывод раньше, когда накопится меньше данных для записи.

Связанный контент