Как настроить ваш SSD в Ubuntu для лучшей производительности

2024 Автор: Geoffrey Carr | [email protected]. Последнее изменение: 2024-01-31 12:52

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

Ориентиры

Чтобы сравнить наш диск, мы использовали тестовый комплект Phoronix. Это бесплатно и имеет репозиторий для Ubuntu, поэтому вам не нужно компилировать с нуля, чтобы выполнять быстрые тесты. Мы протестировали нашу систему сразу после новой установки 64-битной версии Ubuntu Natty с использованием параметров по умолчанию для файловой системы ext4.

Наши системные спецификации были следующими:

AMD Phenom II четырехъядерный процессор 3,2 ГГц
Материнская плата MSI 760GM E51
ОЗУ 3,5 ГБ
AMD Radeon 3000 интегрирована с 512 Мб оперативной памяти
Ubuntu Natty

И, конечно же, SSD, который мы использовали для тестирования, - это 64-гигабайтный OCZ Onyx ($ 117 на Amazon.com на момент написания).

Выдающиеся твики

Есть немало изменений, которые люди рекомендуют при обновлении до SSD. После фильтрации некоторых из старых материалов мы сделали короткий список настроек, которые дистрибутивы Linux не включали в качестве значений по умолчанию для SSD. Три из них включают в себя редактирование файла fstab, так что прежде чем продолжить, выполните следующую команду:


sudo cp /etc/fstab /etc/fstab.bak

Если что-то пойдет не так, вы всегда можете удалить новый файл fstab и заменить его копией своей резервной копии. Если вы не знаете, что это такое или вы хотите разобраться, как это работает, взгляните на HTG. Объясняет: что такое fstab Linux и как он работает?

Время доступа

Вы можете помочь увеличить срок службы вашего SSD, уменьшив объем записи ОС на диск. Если вам нужно знать, когда последний файл или каталог был последним, вы можете добавить эти два параметра в файл / etc / fstab:


noatime,nodiratime

Добавьте их вместе с другими параметрами и убедитесь, что все они разделены запятыми и пробелами.

Включение TRIM

Вы можете включить TRIM, чтобы помочь управлять производительностью диска в долгосрочной перспективе. Добавьте следующий файл в файл fstab:


discard

Это хорошо работает для файловых систем ext4, даже на стандартных жестких дисках. У вас должна быть версия ядра не менее 2.6.33 или новее; вы охвачены, если используете Maverick или Natty, или имеете backports, включенные на Lucid. Хотя это не улучшает первоначальный бенчмаркинг, он должен сделать систему более эффективной в долгосрочной перспективе, и поэтому она сделала наш список.

Tmpfs

Системный кеш хранится в / tmp. Мы можем сказать fstab, чтобы установить это в ОЗУ как временную файловую систему, чтобы ваша система меньше касалась жесткого диска. Добавьте следующую строку в конец файла / etc / fstab в новой строке:


tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

Сохраните файл fstab, чтобы зафиксировать эти изменения.

Переключение IO Schedulers

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

Во-первых, укажите, какие опции у вас есть в следующей команде, заменив «X» буквой вашего корневого диска:


cat /sys/block/sdX/queue/scheduler

Моя установка находится на sda. Вы должны увидеть несколько разных вариантов.

Если у вас есть крайний срок, вы должны использовать это, так как это дает вам дополнительную настройку вниз по линии. Если нет, вы можете без проблем использовать noop. Нам нужно сказать ОС, чтобы использовать эти параметры после каждой загрузки, поэтому нам нужно будет отредактировать файл rc.local.

Мы будем использовать nano, так как нам удобнее использовать командную строку, но вы можете использовать любой другой текстовый редактор, который вам нравится (gedit, vim и т. Д.).


sudo nano /etc/rc.local

Над линией «выход 0» добавьте эти две строки, если вы используете крайний срок:


echo deadline > /sys/block/sdX/queue/scheduler
echo 1 > /sys/block/sdX/queue/iosched/fifo_batch

Если вы используете noop, добавьте эту строку:


echo noop > /sys/block/sdX/queue/scheduler

Еще раз замените «X» соответствующей буквой диска для вашей установки. Посмотрите все, чтобы убедиться, что он выглядит хорошо.

Затем нажмите CTRL + O, чтобы сохранить, затем CTRL + X, чтобы выйти.

Запустить снова

Чтобы все эти изменения вступили в силу, вам необходимо перезапустить. После этого вы должны быть настроены. Если что-то пойдет не так, и вы не можете загрузиться, вы можете систематически отменить каждый из вышеперечисленных шагов, пока не сможете снова загрузиться. Вы можете даже использовать LiveCD или LiveUSB для восстановления, если хотите.

Ваши изменения fstab будут проходить через всю жизнь вашей установки, даже несмотря на обновления, но ваше изменение rc.local должно быть восстановлено после каждого обновления (между версиями).

Результаты бенчмаркинга

Для выполнения тестов мы выполнили набор тестов на диск. Верхнее изображение каждого теста перед настройкой конфигурации ext4, а нижнее изображение - после настроек и перезагрузки. Вы увидите краткое объяснение того, что тестирует, а также интерпретирует результаты.

Операции с большими файлами

Этот тест сжимает 2 ГБ файл со случайными данными и записывает его на диск. Щупы SSD здесь показывают примерно на 40%.

IOzone имитирует производительность файловой системы, в этом случае записывая 8-гигабайтный файл. Опять же, почти на 50% больше.

Здесь читается 8-гигабайтный файл. Результаты почти такие же, как без регулировки ext4.

AIO-Stress асинхронно тестирует ввод и вывод, используя тестовый файл 2 ГБ и размер записи в 64 КБ. Здесь почти 200% -ное увеличение производительности по сравнению с vanilla ext4!

Маленькие операции

Создана база данных SQLite, и PTS добавляет к ней 12 500 записей. Усилия SSD здесь фактически замедляли производительность примерно на 10%.

Тест Apache Benchmark проверяет случайные чтения небольших файлов. После оптимизации нашего SSD было достигнуто около 25% прироста производительности.

PostMark имитирует 25 000 транзакций файлов, 500 одновременно в любой момент времени, с размером файлов от 5 до 512 КБ. Это очень хорошо имитирует веб-серверы и почтовые серверы, и мы видим увеличение производительности на 16% после настройки.

FS-Mark просматривает 1000 файлов с общим размером 1 МБ и измеряет, сколько из них может быть полностью записано и прочитано за заданный промежуток времени. Наши настройки видят увеличение, опять же, с меньшими размерами файлов. Увеличение на 45% с помощью настроек ext4.

Доступ к файловой системе

Тесты тестовой файловой системы Dbench тестируются клиентами, что-то вроде того, как Samba делает что-то. Здесь производительность ванильного ext4 снижается на 75%, что является серьезным изменением в сделанных нами изменениях.

Вы можете видеть, что по мере роста числа клиентов расхождение в производительности увеличивается.

У 48 клиентов разрыв между ними несколько заторможен, но по нашим хитростям все еще очень очевидная потеря производительности.

С 128 клиентами производительность почти такая же. Вы можете рассуждать о том, что наши настройки не могут быть идеальными для домашнего использования в этом виде операций, но будут обеспечивать сопоставимую производительность, когда количество клиентов значительно увеличится.

Этот тест зависит от библиотеки доступа AIO от ядра. у нас есть улучшение на 20%.

Здесь мы имеем многопоточное случайное считывание 64 МБ, и здесь производительность на 200% выше! Вот Это Да!

При записи 64 МБ данных с 32 потоками мы по-прежнему увеличиваем производительность на 75%.

Compile Bench имитирует влияние возраста на файловую систему, представленную манипулированием деревьями ядра (создание, компиляция, исправление и т. Д.). Здесь вы можете увидеть значительное преимущество за счет первоначального создания моделируемого ядра, около 40%.

Эти тесты просто определяют, сколько времени требуется для извлечения ядра Linux. Не слишком большое увеличение производительности здесь.

Резюме

Корректировки, которые мы внесли в конфигурацию Ubuntu из готовой конфигурации ext4, оказали большое влияние. Наибольший прирост производительности был в области многопоточных операций записи и чтения, чтения небольших файлов и больших непрерывных операций чтения и записи файлов. Фактически, единственным реальным местом, где мы видели успех в производительности, были простые вызовы файловой системы, за которыми должны следить пользователи Samba. В целом, похоже, это довольно значительное увеличение производительности для таких вещей, как хостинг веб-страниц и просмотр / потоковое видео.

Имейте в виду, что это было специально для Ubuntu Natty 64-бит. Если ваша система или SSD различны, ваш пробег может отличаться. В целом, похоже, что корректировки планировщика fstab и IO, которые мы сделали, имеют большой путь к повышению производительности, поэтому, вероятно, стоит попробовать на собственной установке.

У вас есть собственные критерии и вы хотите поделиться своими результатами? Иметь другую настройку, о которой мы не знаем? Звучит в комментариях!