Производительность Ubuntu плохая с настройкой cryptsetup / lvm

2519
freiksenet

В настоящее время у меня есть следующая настройка на моем ноутбуке - harddrive разделен на 3 части, первая - это / boot для моего ubuntu, третья - установка Windows, а одна посередине - зашифрованный раздел с lvm с 3 разделами. - / и / home с btfs и / swap. На тех у меня установлена ​​Ubuntu 10.10.

Я делаю шифрование с помощью cryptsetup / luks.

К сожалению, у меня очень низкая производительность в этой настройке - загрузка занимает почти 3 минуты, а после загрузки система «прогревается» до нормальной производительности в течение минуты или двух. Я подозреваю, что дисковый ввод-вывод является проблемой, поскольку такие вещи, как apt-get, иногда очень медленны при интенсивных операциях ввода-вывода («чтение базы данных»). Интересно, почему моя производительность ввода-вывода может быть медленной. У меня есть 3 идеи - либо lvm ведет себя плохо по сравнению с зашифрованным разделом luks, либо btrfs ведет себя плохо по какой-то причине, либо установка ubuntu по какой-то причине испорчена (в чем я сомневаюсь).

Интересно, возможно ли какое-либо из этих предложений, и если нет, то что еще может так сильно повлиять на производительность?

PS: До этой установки производительность была удовлетворительной с настройкой luks-on-lvm (3 раздела lvm, зашифрованных luks) и настройкой ext4 fs, так что это именно эта установка, а не ноутбук.

PPS: шифрование aes-xts-plain 512 бит.

1
Какое оборудование вы используете и какие опции шифрования вы выбрали? Мой 10.10 устанавливается на нетбук с использованием luks и ext4, загружается с нормальной скоростью, так что это, вероятно, связано с вашим оборудованием или выбором шифрования. Cry Havok 13 лет назад 1
Аппаратное обеспечение не должно быть релевантным, поскольку у меня были разные настройки на одном и том же оборудовании, и оно работало нормально freiksenet 13 лет назад 0
Это ваше предположение, но оно может быть неверным, поэтому я и спросил. Помните, что шифрование / дешифрование добавляет накладные расходы, так что оно работает нормально, незашифрованное ничего не значит. Cry Havok 13 лет назад 0
Он прекрасно работал в зашифрованном виде, но с другой настройкой - это был lvm, разделы которого были зашифрованы, а не зашифрованный раздел на lvm. Пост упоминает об этом. freiksenet 13 лет назад 0
Возможно, просто неудачная установка или в другой конфигурации она находится на плохой / более медленной части диска. wag2639 13 лет назад 0
Вы пробовали на http://askubuntu.com или http://unix.stackexchange.com? Toto 13 лет назад 0

2 ответа на вопрос

2
inf.ig.sh

Привет, я думаю, вы выбрали слишком сильное шифрование, которое вызывает проблемы с производительностью. 512 бит - это немного излишне, 256 должно быть достаточно, так как он все еще безопасен и, вероятно, будет на много лет вперед.

Хорошо, это звучит разумно. Я не думал, что шифрование может так сильно снизить производительность. Я попробую перешифровать все с меньшим битрейтом. freiksenet 13 лет назад 0
Если выбранная схема шифрования (или ваша настройка разбиения) плохо совпадает с исходной геометрией дисковода, вы можете увидеть снижение производительности (особенно для небольших случайных операций ввода-вывода, например apt), когда диск считывает 2 блока где-то ранее (в правильно выровненном настройка) это только читать один. Paul McMillan 13 лет назад 0
0
Mikko Rantalainen

Я предполагаю, что проблема в btrfs на LVM. У меня был плохой опыт работы с этой комбинацией (в основном, намного худшая задержка для отдельных запросов ввода-вывода, чем ожидалось). Общая производительность может быть хорошей, так что она зависит от вашей рабочей нагрузки. Если вам нужна низкая задержка для каждого запроса, я бы рекомендовал использовать EXT4 на LVM или btrfs на необработанных устройствах.

Возможно, проблема также была связана с тем, что ФП задал этот вопрос в 2010 году, до того, как AES-NI стала обычным явлением. duskwuff 6 лет назад 0
@ Duskwuff это правда, что вопрос довольно старый. Тем не менее, я использую LUKS, поскольку примерно в то же время я бы сказал, что по сравнению с производительностью вращающихся жестких дисков LUKS уже достаточно быстр. Mikko Rantalainen 6 лет назад 0

Похожие вопросы