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

Короткое содержание

• Что проверяли и как: использование Phoronix Test Suite на чистой установке Ubuntu Natty 64-bit с файловой системой ext4.
• Основные правки: noatime,nodiratime; discard; tmpfs для /tmp; смена IO scheduler через /etc/rc.local.
• Результат: заметный прирост в многопоточных операциях и больших последовательных чтениях/записях, ухудшение в простых файловых вызовах (например, Dbench/Samba).

Важно: всегда создавайте резервную копию /etc/fstab и тестируйте изменения на ненагруженной машине или в VM перед применением в продакшене.

Быстрые ссылки

• Пробежки тестов (Benchmarks)
• Рекомендованные настройки (Prominent Tweaks)
• Результаты тестов (Benchmarking Results)
• Итог и рекомендации (Summary)

Методология тестирования

Мы использовали Phoronix Test Suite (PTS) — свободный набор тестов с репозиторием для Ubuntu, что избавляет от необходимости компилировать тесты вручную. Тестовая платформа была собрана сразу после чистой установки Ubuntu Natty 64-bit с ext4 по умолчанию. Это важно: конфигурация «из коробки» ext4 служит отправной точкой.

Кратко о тестовом железе (локализация единиц):

• AMD Phenom II четырёхъядерный @ 3,2 ГГц
• Материнская плата MSI 760GM E51
• 3,5 ГБ ОЗУ
• Встроенная графика AMD Radeon 3000 с 512 МБ
• Диск: SSD OCZ Onyx 64 ГБ (приблизительно 117 долларов США на Amazon.com на момент проведения теста)

Методика: для каждого теста запускались сценарии «до изменений» и «после изменений» с перезагрузкой между состояниями. Мы фиксировали относительные изменения производительности (в процентах) и анализировали, какие типы нагрузок выигрывают, а какие — теряют.

Почему именно эти правки: кратко о мотивации

• noatime,nodiratime — сокращают количество записей метаданных при чтении файлов, что уменьшает общее число записей на SSD и может увеличить срок службы и скорость.
• discard — включение TRIM позволяет SSD освобождать блоки, что улучшает производительность в долгосрочной перспективе.
• tmpfs для /tmp — перемещает временные файлы в ОЗУ, снижая запись на диск для краткоживущих данных.
• Смена IO scheduler — SSD не имеют тех же ограничений вращающихся дисков, поэтому планировщики, рассчитанные на HDD (cfq), не всегда оптимальны.

Рекомендуемые настройки (шаг за шагом)

Перед началом создайте резервную копию fstab:

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

Если что-то пошло не так, можно вернуть резервную копию командой sudo cp /etc/fstab.bak /etc/fstab из live-среды или после загрузки в безопасном режиме.

1) Отключение записи времени доступа

Добавьте параметры noatime,nodiratime к записям в /etc/fstab для разделов на SSD. Это уменьшит число ненужных записей при чтении файлов.

Пример строки в fstab:

UUID=xxxx-xxxx / ext4 defaults,noatime,nodiratime,errors=remount-ro 0 1

Пояснение: noatime отключает обновление атрибута времени доступа для файлов, nodiratime делает то же для каталогов. Разделяйте параметры запятой, без пробелов.

2) Включение TRIM

TRIM помогает SSD управлять удалёнными блоками, уменьшая деградацию производительности со временем. Для автоматического TRIM при монтировании добавьте опцию discard в соответствующую строку fstab:

UUID=xxxx-xxxx / ext4 defaults,discard,noatime,nodiratime 0 1

Требование: ядро Linux версии ≥ 2.6.33. Дистрибутивы Maverick и Natty уже покрывают это; для Lucid может потребоваться бэкпорт.

Важно: некоторые специалисты рекомендуют использовать плановые fstrim из cron вместо монтируемого discard для избежания накладных расходов в рантайме. Оба подхода рабочие — см. раздел «Альтернативные подходы».

3) Перенос /tmp в tmpfs

Чтобы снизить запись короткоживущих файлов на SSD, можно монтировать /tmp в ОЗУ:

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

Это безопасно для большинства систем: /tmp очищается после перезагрузки, а права mode=1777 сохраняют ожидаемое поведение: все могут писать, файлы принадлежат владельцам и автоматически удаляются при перезагрузке.

4) Смена IO scheduler и постоянное применение

Планировщик ввода-вывода по умолчанию cfq хорош для HDD, но для SSD часто лучше deadline или noop.

Как посмотреть доступные планировщики (замените sdX на букву вашего диска, например sda):

cat /sys/block/sdX/queue/scheduler

Вы увидите что-то вроде: [noop] deadline cfq — выбранный будет в квадратных скобках. Если доступен deadline, рекомендуется он (дополнительная опция ниже). Если нет, noop — безопасный выбор.

Чтобы применить настройку после каждой загрузки, отредактируйте /etc/rc.local и добавьте строки перед exit 0:

Если deadline доступен:

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

Если используете noop:

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

Не забудьте заменить sdX на правильную букву диска.

После внесения всех изменений выполните перезагрузку.

sudo reboot

Если при загрузке возникают проблемы, откатите изменения по порядку: сначала /etc/rc.local, затем /etc/fstab, загружаясь с LiveCD/LiveUSB при необходимости.

Результаты бенчмарков и интерпретация

Мы запускали набор дисковых тестов PTS. Для каждого теста показано состояние «до» и «после» оптимизаций (с перезагрузкой между состояниями). Ниже — краткое описание измерений и интерпретация.

Большие файловые операции

• Компрессия и запись 2 ГБ случайных данных: наблюдался прирост примерно 40% после оптимизаций — SSD лучше справляется с большими последовательными операциями при отключённом atime и включённом discard.
• IOzone (запись 8 ГБ): почти 50% прироста.
• Чтение 8 ГБ: результаты почти не изменились, что указывает на то, что чтение последовательных данных уже было оптимальным для данного контроллера SSD.
• AIO-Stress (2 ГБ, запись асинхронно, размер записи 64 КБ): почти 200% улучшение — здесь многопоточная и асинхронная нагрузка выиграла сильнее всего.

Небольшие файловые операции

• SQLite (создание базы и вставка 12500 записей): неожиданное снижение производительности ~10% — вероятно из-за перекрытия записей группы и особенностей синхронизации данных.
• Apache Benchmark (произвольные чтения маленьких файлов): ~25% прироста — полезно для веб-серверов.
• PostMark (25 000 транзакций, 500 конкурентных, файлы 5–512 КБ): ~16% прироста.
• FS-Mark (1000 файлов общего объёма 1 МБ): ~45% улучшения для малых файлов в наших условиях.

Доступ к файловой системе и многопользовательские нагрузки

• Dbench (симуляция клиентских вызовов, как в Samba): производительность vanilla ext4 упала примерно на 75% после внесённых правок — это серьёзный регресс для сценариев с большим количеством простых системных вызовов.
• По мере роста числа клиентов (48 → 128) разница сокращается: с 128 клиентами производительность стала почти одинаковой. Это значит, что наши правки хуже для лёгких, однотипных вызовов, типичных для Samba при небольшом числе клиентов.

Другие тесты

• Тест, зависящий от ядровой AIO-библиотеки: ~20% улучшения.
• Многопоточное чтение 64 МБ: ~200% улучшения.
• Многопоточная запись 64 МБ с 32 потоками: ~75% улучшения.
• Compile Bench (симуляция сборки ядра): значительное улучшение при первоначальном создании дерева (~40%).
• Распаковка ядра: небольшое изменение.

Резюме по результатам: наибольший выигрыш — в многопоточных операциях и больших последовательных операциях; наибольшие потери — в простых файловых вызовах, важных для некоторых типов серверных нагрузок.

Когда эти настройки не подойдут (контрпримеры)

• Samba/данные для сетевых шар: если ваша нагрузка — множество коротких синхронных системных вызовов от небольшого числа клиентов, отключение atime и использование discard/tmpfs/планировщика deadline может ухудшить производительность.
• Базы данных с интенсивными синхронными fsync: некоторые настройки могут снизить пропускную способность транзакций; тестируйте на реальных рабочих нагрузках.
• Нестандартные SSD-контроллеры: старые контроллеры или специфичные прошивки могут по-разному реагировать на discard или другой IO scheduler.

Альтернативные подходы

• Вместо discard при монтировании используйте плановый fstrim через cron или systemd.timer, чтобы уменьшить накладные расходы в рантайме: это часто рекомендованная практика для серверов.

Пример systemd unit (псевдо):

# Запуск fstrim еженедельно (пример)
sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer

• Для критичных баз данных рассмотрите настройку mount и опции atime, а также профилирование fsync и writeback.
• Используйте LVM snapshot/backup перед крупными правками.

Короткие эвристики и ментальные модели

• Если нагрузка — многопоточные записи/чтения больших файлов → оптимизации обычно выигрывают.
• Если нагрузка — множество простых файловых операций/системных вызовов от небольшого числа клиентов (Samba, NFS) → ретестируйте; возможны регрессы.
• Используйте VM или тестовую среду как «песочницу» перед продакшеном.

Чек-листы по ролям

Администратор сервера:

• Сделать бэкап /etc/fstab
• Запланировать окно тестирования/отката
• Проверить журнал ядра (dmesg) после перезагрузки

Разработчик/QA:

• Запустить набор тестов производительности приложений
• Проверить корректность работы базы данных и задержки транзакций

Обычный пользователь:

• Сделать резервную копию данных
• Применять изменения постепенно и проверять повседневные сценарии

Сниппеты и часто используемые команды (cheat sheet)

Посмотреть текущий планировщик:

cat /sys/block/sdX/queue/scheduler

Установить планировщик вручную (временно):

echo noop | sudo tee /sys/block/sdX/queue/scheduler

Выполнить fstrim вручную для всего корня:

sudo fstrim -v /

Вернуть резервную копию fstab (если нужно):

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

План отката и отладка

1. Если система не загружается после правок fstab — загрузитесь с LiveUSB и откатите /etc/fstab к резервной копии.
2. Если проблемы связаны с rc.local (например, неправильный синтаксис) — загрузитесь в recovery mode и удалите добавленные строки.
3. Для специфических регрессов (Samba, база данных) поочерёдно отключайте опции: tmpfs, discard, смену планировщика, noatime — и повторяйте тесты.

Матрица совместимости и рекомендации по миграции

• Дистрибутивы Ubuntu ≥ 10.10 (Maverick, Natty) — TRIM/discard поддерживается. Для старых версий проверьте ядро или используйте backports.
• ext4 — хорошо работает с этими правками; для Btrfs и XFS методы могут отличаться.
• Виртуальные машины: tmpfs и планировщики внутри гостя не всегда дают ожидаемый эффект, если гипервизор абстрагирует устройство.

Безопасность и приватность

• tmpfs хранит данные в ОЗУ: это хорошо для конфиденциальности (данные не попадают на диск), но данные исчезают при перезагрузке. Убедитесь, что вам подходит такое поведение для /tmp.
• TRIM может раскрывать некоторую информацию о использовании блоков SSD при частичном снятии образа диска в форензике; для высокобезопасных сред это нужно учитывать.

Решение: как принять решение для вашей системы (мертвая простая диаграмма)

flowchart TD
  A[Цель: увеличить производительность SSD?] --> B{Тип нагрузки}
  B -->|Многопоточные/большие файлы| C[Применить noatime, discard, tmpfs, deadline]
  B -->|Много мелких системных вызовов 'Samba'| D[Тщательное тестирование; возможно оставить cfq]
  B -->|БД с интенсивными fsync| E[Тестировать fsync; рассмотреть fstrim вместо discard]
  C --> F[Запустить тесты, наблюдать]
  D --> F
  E --> F
  F --> G{Профит?}
  G -->|Да| H[Внедрить в продакшен]
  G -->|Нет| I[Откатить изменения]

Примеры сценариев и когда ожидать эффекта

• Веб-хостинг статики и стриминг видео: выигрыш частый и заметный — большие последовательные чтения и многопоточные запросы ускоряются.
• Мail/SMTP с большим числом транзакций малого размера: зависит от характера транзакций; PostMark показал умеренный выигрыш.
• Файловые шаринги (Samba): потенциальный регресс — тестируйте на реальных клиентах.

Итог и рекомендации

• Оптимизации с fstab и сменой планировщика дают заметный прирост в многопоточных операциях и при работе с большими файлами.
• Есть риск регресса для лёгких одиночных системных вызовов, поэтому прежде чем внедрять на сервере, протестируйте рабочую нагрузку.
• Рассмотрите использование планового fstrim как альтернативу монтируемому discard для снижения накладных расходов.

Короткое руководство действий для большинства домашних/офисных машин:

1. Сделайте бэкап /etc/fstab.
2. Добавьте noatime,nodiratime и discard (или планируйте fstrim).
3. Добавьте tmpfs для /tmp.
4. Установите deadline или noop в /etc/rc.local.
5. Перезагрузитесь и запустите серию тестов (или используйте повседневные сценарии).
6. Откатите при регрессе или тонко настройте опции.

Если у вас есть свои результаты тестов или другие полезные приёмы — поделитесь в комментариях или на форумах: реальные данные разных конфигураций помогают составить надёжную картину.

Критерии приёмки

• Система успешно загружается после правок.
• Целевое приложение демонстрирует либо улучшение производительности, либо несущественное изменение.
• Нет роста ошибок ввода-вывода в логах (dmesg, /var/log/syslog).