Есть много советов по настройке SSD в Linux и множество анекдотических отчетов о том, что работает, а что нет. Мы провели собственные тесты с несколькими конкретными настройками, чтобы показать вам реальную разницу.
Контрольные точки
Для тестирования нашего диска мы использовали Тестовый набор Фороникс . Он бесплатный и имеет репозиторий для Ubuntu, поэтому вам не нужно компилировать с нуля для выполнения быстрых тестов. Мы протестировали нашу систему сразу после новой установки Ubuntu Natty 64-bit, используя параметры по умолчанию для файловой системы ext4.
Наши системные характеристики были следующими:
- Четырехъядерный процессор AMD Phenom II с частотой 3,2 ГГц
- Материнская плата MSI 760GM E51
- 3,5 ГБ RAM
- AMD Radeon 3000 интегрированный с 512 МБ ОЗУ
- Ubuntu Natty
И, конечно же, SSD, который мы использовали для тестирования, был диском OCZ Onyx 64 ГБ ( 117 долларов на Amazon.com на момент написания).
Известные твики
Есть довольно много изменений, которые люди рекомендуют при переходе на SSD. Отфильтровав некоторые из старых вещей, мы составили короткий список настроек, которые дистрибутивы Linux не включили в качестве значений по умолчанию для SSD. Три из них связаны с редактированием файла fstab, поэтому сделайте резервную копию, прежде чем продолжить с помощью следующей команды:
sudo cp / etc / fstab /etc/fstab.bak
Если что-то пойдет не так, вы всегда можете удалить новый файл fstab и заменить его копией своей резервной копии. Если вы не знаете, что это такое, или хотите узнать, как это работает, взгляните на HTG объясняет: что такое Linux fstab и как он работает?
Избегая времени доступа
Вы можете увеличить срок службы SSD, уменьшив объем записи ОС на диск. Если вам нужно знать, когда в последний раз осуществлялся доступ к каждому файлу или каталогу, вы можете добавить эти две опции в свой файл / etc / fstab:
noatime, nodiratime
Добавьте их вместе с другими параметрами и убедитесь, что все они разделены запятыми и без пробелов.
Включение TRIM
Вы можете включить TRIM, чтобы управлять производительностью диска в долгосрочной перспективе. Добавьте в файл fstab следующую опцию:
отбросить
Это хорошо работает для файловых систем ext4, даже на стандартных жестких дисках. У вас должно быть ядро версии не ниже 2.6.33 или новее; вы защищены, если используете Maverick или Natty, или если в Lucid включены резервные порты. Хотя это конкретно не улучшает начальный бенчмаркинг, в долгосрочной перспективе это должно улучшить работу системы, и поэтому она попала в наш список.
Tmpfs
Системный кеш хранится в / tmp. Мы можем сказать fstab смонтировать это в ОЗУ как временную файловую систему, чтобы ваша система меньше касалась жесткого диска. Добавьте следующую строку в конец файла / etc / fstab с новой строки:
tmpfs / tmp tmpfs по умолчанию, noatime, mode = 1777 0 0
Сохраните файл fstab, чтобы зафиксировать эти изменения.
Переключение планировщиков ввода-вывода
Ваша система не записывает все изменения на диск сразу, и несколько запросов помещаются в очередь. Планировщик ввода-вывода по умолчанию - cfq - справляется с этим нормально, но мы можем изменить его на тот, который лучше работает для нашего оборудования.
Сначала укажите, какие параметры у вас есть, с помощью следующей команды, заменив «X» буквой корневого диска:
кошка / система / блок / SDX / очередь / планировщик
Моя установка на sda. Вы должны увидеть несколько разных вариантов.
Если у вас есть крайний срок, вы должны использовать его, так как это дает вам дополнительную настройку в дальнейшем. Если нет, вы сможете без проблем использовать noop. Нам нужно указать ОС использовать эти параметры после каждой загрузки, поэтому нам нужно будет отредактировать файл rc.local.
Мы будем использовать nano, так как нам удобна командная строка, но вы можете использовать любой другой текстовый редактор, который вам нравится (gedit, vim и т. Д.).
Внезапный / Etc / rc.ぉ или l
Над строкой «exit 0» добавьте эти две строки, если вы используете крайний срок:
эхо крайний срок> / sys / block / sdX / queue / scheduler
эхо 1> / системный / блок / SDX / очередь / iosched / fifo_batch
Если вы используете noop, добавьте эту строку:
echo noop> / sys / block / sdX / очередь / планировщик
Еще раз замените «X» на букву диска, соответствующую вашей установке. Просмотрите все, чтобы убедиться, что все хорошо.
Затем нажмите CTRL + O, чтобы сохранить, затем CTRL + X, чтобы выйти.
Перезапуск
Чтобы все эти изменения вступили в силу, необходимо перезапустить. После этого у вас должно быть все готово. Если что-то пойдет не так, и вы не можете загрузиться, вы можете систематически отменять каждый из вышеперечисленных шагов, пока не сможете снова загрузиться. Вы даже можете использовать LiveCD или LiveUSB для восстановления если ты хочешь.
Ваши изменения fstab будут действовать в течение всего срока вашей установки, даже несмотря на обновления, но ваше изменение rc.local необходимо будет повторно вводить после каждого обновления (между версиями).
Результаты сравнительного анализа
Для выполнения тестов мы запустили набор тестов для дисков. Верхнее изображение каждого теста - до настройки конфигурации ext4, а нижнее изображение - после настроек и перезагрузки. Вы увидите краткое объяснение того, что измеряет тест, а также интерпретацию результатов.
Операции с большими файлами
Этот тест сжимает файл размером 2 ГБ со случайными данными и записывает его на диск. Настройки SSD здесь показывают улучшение примерно на 40%.
IOzone имитирует производительность файловой системы, в данном случае записывая файл размером 8 ГБ. Опять же, увеличение почти на 50%.
Здесь читается файл размером 8ГБ. Результаты практически такие же, как и без настройки ext4.
AIO-Stress выполняет асинхронную проверку ввода и вывода, используя тестовый файл размером 2 ГБ и размер записи 64 КБ. Здесь производительность выросла почти на 200% по сравнению с ванильным ext4!
Небольшие файловые операции
Создается база данных SQLite, и PTS добавляет к ней 12500 записей. Настройки SSD здесь фактически снизили производительность примерно на 10%.
Тест Apache Benchmark проверяет случайное чтение небольших файлов. После оптимизации твердотельного накопителя производительность увеличилась примерно на 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 и планировщика ввода-вывода имеют большое значение для повышения производительности, так что, вероятно, стоит попробовать на своей установке.
У вас есть собственные тесты и вы хотите поделиться своими результатами? Есть еще одна настройка, о которой мы не знаем? Озвучивайте в комментариях!
