Как настроить свой SSD в Ubuntu для лучшей производительности
Существует множество советов по настройке SSD в Linux и множество отдельных отчетов о том, что работает, а что нет. Мы провели собственные тесты с несколькими конкретными настройками, чтобы показать вам реальную разницу.
Ориентиры
Для тестирования нашего диска мы использовали тестовый набор Phoronix. Он бесплатный и имеет репозиторий для Ubuntu, так что вам не нужно компилировать его с нуля для запуска быстрых тестов. Мы протестировали нашу систему сразу после новой установки Ubuntu Natty 64-bit, используя параметры по умолчанию для файловой системы ext4.
Наши системные характеристики были следующими:
- Четырехъядерный процессор AMD Phenom II с частотой 3,2 ГГц
- MSI 760GM E51 материнская плата
- 3,5 ГБ ОЗУ
- AMD Radeon 3000 интегрированная с 512 МБ оперативной памяти
- Ubuntu Natty
И, конечно же, SSD, на котором мы тестировали, был OCZ Onyx емкостью 64 ГБ ($ 117 на Amazon.com на момент написания).
Видные твики
Есть довольно много изменений, которые люди рекомендуют при переходе на SSD. После фильтрации некоторых старых вещей мы сделали небольшой список настроек, которые дистрибутивы Linux не включили в качестве настроек по умолчанию для твердотельных накопителей. Три из них включают редактирование вашего файла fstab, поэтому сделайте резервную копию, прежде чем продолжить с помощью следующей команды:
sudo cp / etc / fstab /etc/fstab.bak
Если что-то пойдет не так, вы всегда можете удалить новый файл fstab и заменить его резервной копией. Если вы не знаете, что это такое, или вы хотите узнать, как это работает, взгляните на HTG Explains: что такое Linux fstab и как он работает?
Отказаться от времени доступа
Вы можете помочь увеличить срок службы вашего SSD, уменьшив объем записи операционной системы на диск. Если вам нужно знать, когда к каждому файлу или каталогу обращались в последний раз, вы можете добавить эти две опции в ваш файл / etc / fstab:
noatime, nodiratime
Добавьте их вместе с другими параметрами и убедитесь, что все они разделены запятыми и без пробелов.
Включение TRIM
Вы можете включить TRIM, чтобы помочь управлять производительностью диска в долгосрочной перспективе. Добавьте следующую опцию в ваш файл fstab:
отбрасывать
Это хорошо работает для файловых систем ext4, даже на стандартных жестких дисках. У вас должна быть версия ядра не ниже 2.6.33 или выше; Вы защищены, если вы используете Maverick или Natty, или у Lucid включены backports. Хотя это не улучшит начальный бенчмаркинг, оно должно сделать систему более эффективной в долгосрочной перспективе, и поэтому она попала в наш список.
Tmpfs
Системный кеш хранится в / tmp. Мы можем указать fstab монтировать его в ОЗУ как временную файловую систему, чтобы ваша система меньше касалась жесткого диска. Добавьте следующую строку в конец вашего файла / etc / fstab в новой строке:
tmpfs / tmp tmpfs по умолчанию, 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» добавьте эти две строки, если вы используете крайний срок:
срок выполнения эха> / 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. Здесь производительность vanilla ext4 снижена на 75%, что является серьезным препятствием для внесенных нами изменений.
Вы можете видеть, что с ростом количества клиентов увеличивается несоответствие производительности..
С 48 клиентами разрыв между ними несколько сократился, но наши изменения все еще демонстрируют очень очевидную потерю производительности.
С 128 клиентами производительность практически одинакова. Вы можете рассуждать, что наши настройки могут быть не идеальными для домашнего использования в такого рода операциях, но будут обеспечивать сопоставимую производительность при значительном увеличении количества клиентов..
Этот тест зависит от библиотеки доступа ядра AIO. у нас здесь 20% улучшение.
Здесь мы имеем многопоточное случайное чтение размером 64 МБ, и здесь производительность увеличивается на 200%! Вот это да!
При записи 64 МБ данных с 32 потоками производительность все равно увеличивается на 75%.
Compile Bench имитирует влияние возраста на файловую систему, представленную манипулированием деревьями ядра (создание, компиляция, исправление и т. Д.). Здесь вы можете увидеть значительную выгоду от первоначального создания смоделированного ядра, около 40%.
Этот тест просто измеряет, сколько времени занимает извлечение ядра Linux. Не слишком много увеличения производительности здесь.
Резюме
Корректировки, которые мы внесли в готовую конфигурацию Ubuntu ext4, оказали большое влияние. Наибольший прирост производительности был достигнут в сферах многопоточных операций записи и чтения, чтения небольших файлов и чтения и записи больших смежных файлов. Фактически, единственное реальное место, которое мы увидели, это снижение производительности - простые вызовы файловой системы, что пользователи Samba должны остерегаться. В целом, это кажется довольно существенным увеличением производительности для таких вещей, как размещение веб-страниц и просмотр / потоковая передача больших видео.
Имейте в виду, что это было специально с Ubuntu Natty 64-bit. Если ваша система или SSD отличаются, ваш пробег может отличаться. В целом, похоже, что настройки планировщика fstab и IO, которые мы внесли, имеют большое значение для повышения производительности, так что, вероятно, стоит попробовать свою собственную установку.
У вас есть свои тесты и вы хотите поделиться своими результатами? Есть еще один твик, о котором мы не знаем? Звучит в комментариях!