Ускорение ssd в ubuntu

Обновлено: 30.06.2024

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

Первое, с чего стоит начать — это выбор файловой системы. Если система на десктопе — то особо вопросов не возникает — брать журналируемую ext4 — у которой масса преимуществ перед остальными ФС. Да, будет больше циклов записи на носитель, но будет гарантия того, что в случае сбоя питания вы не потеряете данные. На ноутбуках, нетбуках — имеются батареи, и вероятность отключения из-за потери питания — практически нулевая (но, конечно, всякое бывает), в связи с чем журналирование, обычно рекомендуют отключать. Если это очень хочется сделать, то после установки системы грузимся с liveCD, и пишем в терминале

tune2fs -O ^has_journal /dev/sda1
e2fsck -f /dev/sda1

Другие способы не рекомендуются — потеряете поддержку TRIM. Также не стоит отключать журнал, добавляя параметр "writeback" в конфигурацию fstab — система не запустится из-за ошибки монтирования (если до этого был включен трим).

Следующее, что нужно учесть — файл подкачки. Под моим никсом (сейчас — убунту 11.04) обычно пишется код, смотрятся фильмы в HD и активно серфится интернет. За это время файл подкачки не понадобился ни разу, максимальное потребление ОЗУ было 1Гб, из 2х доступных в нетбуке.
Если Ваш сценарий использования системы подобен моему, или у Вас не десктоп — файл подкачки не нужен. Иначе стоит его перенести на HDD. Если журналирование еще можно оставить, ввиду его относительной безобидности, то своп-раздел — однозначно зло, сжирающее как ограниченные циклы перезаписи, так и недешевые гигабайты, количеством которых современные SSD пока не могут похвастаться.

Ну вот, система поставлена — можно заниматься оптимизацией! Самый первый шаг — включение TRIM — главная технология, которая должна продлить жизнь и распределить нагрузку SSD.
Делается очень просто — открываем fstab (например так)

gksudo gedit /etc/fstab

ищем строчки
«UUID=[NUMS-AND-LETTERS] / ext4 errors=remount-ro 0 1»
и заменяем на
«UUID=[NUMS-AND-LETTERS] / ext4 disсard,errors=remount-ro 0 1»

Обычно по умолчанию трим отключен, но выкладываю способ проверить — заходим под рут и выполняем команды

1. dd if=/dev/urandom of=tempfile count=10 bs=512k oflag=direct //запись 5Мб рандомных данных

2. hdparm --fibmap tempfile //Ищем любой стартовый LBA адрес у файла

3. hdparm --read-sector [ADDRESS] /dev/sdX //Читаем данные со стартового LBA адреса файла, замените [ADDRESS] на свой Starting LBA address из вывода предыдущей команды

4. rm tempfile //Теперь удалим временный файл и синхронизируем ФС:
5. sync

Повторяем пункт 3 — и смотрим на вывод консоли. Если выведутся нули — то трим работает. Если вы исправили fstab, перезагрузились, но трим не активировался — ищите ошибки в неверном отключении журналирования.

Далее стоит вспомнить о том, что наш никс очень любит вести разнообразные логи. И либо перенести их на HDD, либо держать в ОЗУ до перезагрузки системы. Я считаю, что если у Вас дома не сервер — то оптимален второй вариант, и реализуется он добавлением в fstab следующих строчек
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/spool/postfix tmpfs defaults 0 0

По умолчанию, после каждого открытия файла — система оставляет отметку времени последнего открытия — лишние операции записи. Отучить просто — добавить в fstab перед параметрами
disсard,errors=remount-ro 0
еще парочку опций —
relatime,nodiratime Первая разрешает записывать только время изменения (порой необходимо для стабильной работы некоторых программ), вторая — отменяет запись времени доступа к директориям. В принципе, вместо relatime можно поставить и noatime, который вообще ничего не будет обновлять.

После этого стоит настроить отложенную запись — ядро будет копить данные, ожидающие записи на диск, и записывать их либо при острой необходимости, либо по истечении таймаута. Я ставлю таймаут на 60 секунд, кто-то — на 150.
Для этого открываем /etc/sysctl.conf и добавляем параметры
vm.laptop_mode = 5 // Включение режима
vm.dirty_writeback_centisecs = 6000 время в сСк. Т.е. 100ед = 1секунда

И, напоследок, отключаем I/O планировщик, который был когда-то нужен для лучшего позиционирования головок HDD. Для этого заходит в конфиг граба /etc/default/grub
и в строчку
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash» вставляем параметр elevator=noop
По пути можно убрать ненужный и малоинформатиынй сплэш-скрин, сократив время старта системы еще на секунду, просто убрав quiet splash.

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

Любая операционная система, основанная на ядре Linux, выгодно отличается от всех остальных по скорости работы. Это делает ее стандартом де факто для различного рода устройств, которые не блещут своей производительностью.

Но не смотря на это большинство пользователей хотят получить еще большую производительность от своих компьютеров.

Операционная система Ubuntu и любая другая ОС Linux, позволяет это сделать, так как некоторые параметры, выставленные по умолчанию, имеют не совсем оптимальные значения. Это стремления разработчиков к универсальности и работе на любом типе компьютерного "железа" в ущерб производительности.

Немного теории

Не для кого не секрет, что для большинства современных компьютеров самым слабым звеном является дисковая подсистема. За последние несколько лет технологии "увеличили" производительность практически всех компонентов компьютера, но этот технологический прорыв не коснулся жестких дисков. Если в этой области прогресс в сторону скорости и есть, то на общем фоне выглядит практически не заметно. Именно поэтому с оптимизации работы дисковой подсистемы и следует начать оптимизацию и "тюннинг" операционной системы Ubuntu.

По большей части современный файловые системы Ext3 и Ext4 обладают хорошим быстродействием и их более тонкая настройка не требуется. Более пристальное внимание следует уделить работе оперативной памяти и дисковой подсистемы в целом.

Любая операционная система Linux, в том числе и Ubuntu, устроена так, что практически одновременно использует для хранения каких-то временных данных, оперативную память и файл подкачки - swap. Этот файл подкачки размещается на жестком диске и нужен для разгрузки ОЗУ при ее заполнении. Благодаря ему, у пользователя появляется возможность запускать тяжеловесные приложения с небольшим объемом оперативной памяти, где часть информации хранится на жестком диске. Как говорится: "медленно, но верно". Это точно также как в бизнесе, кто захочет платить лишние деньги за не полностью используемые производственные ресурсы или при заказе рекламы в Екатеринбурге, заказчик не будет переплачивать лишние деньги за избыточную рекламу, полный эффект которой останется не востребованным.

Почему данные хранятся ". практически одновременно. " в swap и ОЗУ?

Потому что Ubuntu устроенна так, что при заполнении оперативной памяти на 40%, происходит ее высвобождение в файл подкачки. Если взять за "стандартный компьютер" - компьютер с 2 Гб оперативной памяти (большинство современных нетбуков обладают даже меньшим объемом памяти - 1Гб), то можно подсчитать, что 40% от всей памяти - это 819,2 Мб (1024Мб * 2 * 0,4 = 819,2 Мб). Интернет-браузер Google Chrome, к примеру, в среднем потребляет порядка 200-300 Мб ОЗУ. Остальные браузеры потребляют примерно столько же. Но очень редко можно встретить пользователя, который бы не пользовался, наверное, главной возможностью современных ОС - многозадачностью и не запускал бы несколько приложений одновременно.

Когда заполнение оперативной памяти достигает указанного порога, операционная система высвобождает ее в файл на жестком диске, то есть позволяет "вступить" в работу одному из самых медленных устройств в компьютере.

Из этого следует, что параметры работы оперативной памяти, которые выставлены в Ubuntu по умолчанию, не совсем подходят для повседневной работы.

Хотелось бы заметить, что никто не утверждает, что swap-файл не нужен в операционной системе и от его использования можно вообще отказаться. Просто его роль в работе операционной системы можно немного принизить.

Эта статья призывает к более оптимальной утилизации имеющейся ОЗУ, так как по умолчанию в ОС держится большое количество ОЗУ просто не используемой, тем самым "тормозя" операционную систему.

Ускоряем работы Ubuntu с дисковой подсистемой

Вся работа по ускорению Ubuntu для удобства разбита не несколько частей:

/etc/sysctl.conf

В самом низу этого файла есть параметр vm.swappiness, который как раз и отвечает за распределение оперативной памяти. По умолчанию он имеет значение 60, показывая, что в любом случае должно оставаться 60% свободной оперативной памяти. Для рабочих станций рекомендуется изменить это значение на 10. Должно получится так:

Если этого параметра нет, то необходимо его добавить в самом конце открытого конфигурационного файла!

Если Вы обладатель компьютера с SSD-накопителем, то для Вас будет актуален параметр:

Если у Вас компьютер с "простым" жестким диском, то наибольшую отзывчивость можно получить при установке параметра:

Чтобы воспользоваться демоном preload в Ubuntu, необходимо его установить:

Дальнейшей дополнительной настройки preload не требует.

Дополнительная информация

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

Для пользователей, которые не готовы работать с командной строкой и конфигурационными файлами, есть решение в виде графической утилиты для тонкой настройки операционной системы Ubuntu - Ailurus, которая "умеет" это делать.

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

Учет трафика сетевого интерфейса в Linux с помощью vnstat
Подключение КПК с Windows Mobile к Linux Ubuntu
Неправильно закрываются терминальные сессии после закрытия приложения
Starus Partition Recovery - программа восстановления данных
Русские теги mp3-файлов в Linux
Компонента V7Plus.dll не найдена
Как установить шрифты MacOS в Ubuntu?

Кстати, Вы забыли упомянуть, что работа демона preload будет заметна,если у использующего,будет большой объем, физического размера оперативной памяти.

P.S. К тому же, сразу прирост производительности, используемый сие демон, не почувствует!

vfs_cache_pressure=1000 это ошибка? У этого параметра значения от 1 до 100 допустимы, и по умолчанию как раз 100 в ubuntu. Чем меньше значение, тем больше кэшируется.

myr4ik07: Пожалуйста, источники в студию …

О чем Вы? Статья написана с использованием большой кучи блогов и сайтов, которые копипастят контент откуда непоподя

myr4ik07: Кстати, Вы забыли упомянуть, что работа демона preload будет заметна,если у использующего,будет большой объем, физического размера оперативной памяти.
P.S. К тому же, сразу прирост производительности, используемый сие демон, не почувствует!

Спасибо, за уточнение. Добавлю.

Андрей: vfs_cache_pressure=1000 это ошибка? У этого параметра значения от 1 до 100 допустимы, и по умолчанию как раз 100 в ubuntu. Чем меньше значение, тем больше кэшируется.

Вроде как у него нет ограничения.

selius: Ubuntu 10.04, сделал по инструкции – не знаю есть ли хоть какой прирост производительности (или это скорее самовнушение) – уже как больше суток, полет нормальный! Хуже точно не стало =) За статью – спасибо!

Смотря как работаете с ОС. Если У Вас большое количество ОЗУ изначально, то, возможно, ее заполнение и не доходило до отметки разгрузки в файл подкачке.

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

Я рушил проблему проещ, но дороже. Полностью отключил swap, убрал раздел подкачки и нарачтил оперативку до 8 Гб. теперь никаких лагов из-за сброса подкачки на диск

Делала по описанию, но в моем случае особого прироста не заметила, а вот apt-get install zram, вродь как полезнее оказался. Если кто захочет поэкспериментировать, то swappiness придется вернуть взад на 60, или не меньше 40, иначе фокус не получится.

tune2fs -O ^has_journal /dev/sda1
e2fsck -f /dev/sda1

gksudo gedit /etc/fstab

ищем строчки
«UUID=[NUMS-AND-LETTERS] / ext4 errors=remount-ro 0 1»
и заменяем на
«UUID=[NUMS-AND-LETTERS] / ext4 disсard,errors=remount-ro 0 1»

Обычно по умолчанию трим отключен, но выкладываю способ проверить — заходим под рут и выполняем команды

1. dd if=/dev/urandom of=tempfile count=10 bs=512k oflag=direct //запись 5Мб рандомных данных

2. hdparm --fibmap tempfile //Ищем любой стартовый LBA адрес у файла

4. rm tempfile //Теперь удалим временный файл и синхронизируем ФС:
5. sync

Иногда я берусь за различные задачи по настройке серверов. Некоторое время назад ко мне обратился владелец небольшой хостинговой компании, с интересной проблемой. Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM.

Однако проведённое им тестирование показало, что дисковая система KVM прилично отставала от показателей, которые у него были под Hyper-V. Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows (бесплатная версия Microsoft Hyper-V Server не устраивала из-за своих ограничений).

0. Диспозиция

Для тестирования использовался SSD Samsung 970 Pro 1TB. Заказчик проверял результаты работы в CrystalDiskMark, поэтому далее в статье все графики из него.

Windows 10 LTSC	Hyper-V 2 CPU	KVM 2 CPU

Следовало в первую очередь улучшить производительность случайного ввода/вывода. Именно этот тип нагрузки характерен для виртуальных машин, в особенности тех из них, в которых используются различные БД.

В Ubuntu (16.04 LTS и 18.04) до сих пор используется qemu версии 2.11. Поэтому некоторые плюшки самых последних qemu в этой статье не рассмотрены.

Мы решили что нам нужно избежать привязывания железа к виртуальной машине, так как это осложняет переносимость виртуальных машин, поэтому варианты с прокидыванием SSD/физических дисков/разделов в виртуалки были признанны нежелательными.

Внимательный читатель может заметить, что использовались разные по размеру области для тестирования от 100МБ до 4ГБ. Дело в том, что размер области очень влияет на время выполнения теста: чем больше область, тем длиннее шёл тест.

Однако, так как каждый раз виртуальная машина запускалась заново, кеш Windows сбрасывался и не оказывал влияние на результаты. Результаты для области 100МБ и 4ГБ отличались в пределах погрешности, но время было в 40 раз больше.

Тестирований за время настройки было проведено огромное количество, чтобы задача не затянулась на месяцы, основная часть испытаний была проведена с областями размером 100МБ-1ГБ. И только решающие испытания были проведены с областями 4ГБ.

1. Используем LVM-тома, а не файлы для хранения дисков виртуальных машин.

Логика такая. Файл с виртуальным диском хранится в файловой системе Linux, внутри самого файла находится NTFS. Каждая файловая система потребляет ресурсы при дисковых операциях. Поэтому чем меньше глубина матрёшки, тем быстрее ввод/вывод.

Если же говорить о файлах qcow2, то их название расшифровывается как «Qemu Copy-On-Write» и, фактически, внутри них есть своя таблица трансляции, которая отвечает за то какие блоки заняты, какие нет и где что находится.

Слой LVM потребляет значительно меньше процессорных ресурсов, чем файловая система. Одна из причин этого то, что блоки в нём значительно больше, чем типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.

А ведь даже для SSD случайный ввод/вывод значительно медленнее, чем последовательный. Поэтому при создании Volume Group мы укажем очень большую величину extent: 256MB.

Read ahead на логическом томе стоит отключить, так как он расходует IO без выигрыша, так как теперь никто не занимается дефрагментацией дисков в Windows на SSD.

LVM довольно удобно использовать для хостинга виртуальных машин. LVM-тома легко переносимы между физическими дисками, есть снимки (snapshot), изменение размера в режиме онлайн. Тем более, что virt-manager (libvirt) умеет из коробки создавать логические тома под диски виртуальных машин из Volume group (группы томов).

Привлекательной выглядит также возможность создать thin volumes («тонкие» тома), но если учесть, что тонкий том — это дополнительный слой абстракции, то, очевидно, что он будет ухудшать производительность IO. К тому же в libvirt нет элегантного пути автоматического создания дисков для виртуальных машин в «тонком» пуле.

1.1. Thin volume как диск и/или настройки логических томов для снимков

Если вы хотите использовать thin pool, в котором будете создавать тонкие тома, то имеет смысл установить размер чанка у пула в 4МБ, что значительно больше размера по-умолчанию в 64КБ.
Что повлечёт более быструю работу этого слоя абстракции.

Механизм снимков в LVM работает практически на том же самом коде, что и тонкие тома, поэтому для увеличения скорости снимков (snapshot) настройки будут теми же самыми.

Опция -Zn отключает перезапись чанка нулями при выделении, что повышает скорость работы.

Настройки для lvm.conf или подобного файла (например lvmlocal.conf):

Вы можете сами определить оптимальный размер чанка выполнив тестирование следующей командой, подобрав величину --blocksize :

Посмотреть текущий размер чанка можно командой:

2. Увеличение количества логических процессоров, выделяемых на каждую виртуальную машину KVM, улучшает дисковую производительность

10 CPU	8 CPU	4 CPU

Понятно, что вряд ли кто будет выделять на виртуалку 10 процессоров, но было интересно посмотреть на крайний случай.

Из чего можно сделать вывод, что хорошо иметь по одному логическому процессору на каждую задачу, активно использующую IO.

3. Используем огромные страницы оперативной памяти (hugepages), чтобы избежать снижения производительности из-за фрагментации RAM

Этот пакет может пригодиться, когда нам понадобится различная информация о hugepages в процессе эксплуатации.

В данном случае было выделено 64ГБ памяти для всех виртуальных машин в виде hugepages. В вашем случае может быть меньше/больше.

Применяем эти настройки для GRUB, чтобы при следующей загрузке системы они стали активны:

Редактируем конфиг виртуальной машины:

4. Добавляем в каждую виртуальную машину выделенный поток для обслуживания IO

Нужно добавить то, что выделено жирным. Используем virsh , как и в предыдущем пункте.

4.1. Для ускорения случайной записи используем кеширование writeback

Для ускорения случайной записи на диск, но с увеличением риска потери данных, можно использовать cache=writeback в предыдущем пункте. Можно использовать только если есть большая уверенность в качестве и резервировании питания и при наличии бэкапов.

5. Настройки дисковой подсистемы в В Virt Manager

Disk bus: VirtIO
Storage format: raw
Cache mode: writeback
IO mode: threads

5.1. Настройка дисковой подсистемы через конфигурационный файл

Qemu 2.11 (который сейчас используется в Ubuntu) поддерживает два типа дисковых виртуальных устройств: virtio-blk и virtio-scsi. Когда в Virt Manager указывается Disk bus: VirtIO — это означает использование устройства virtio-blk.

Во всех случаях по скорости лучше virtio-blk, несмотря на то что в тестируемой версии qemu он ещё не поддерживал TRIM в отличии от virtio-scsi (с версии 5.x уже поддерживает).

С точки зрения скорости дискового IO virtio-scsi имеет смысл использовать лишь в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине.

6. В процессе инсталляции Windows устанавливаем драйвер VirtIO

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

7. Результаты после применения всех твиков

На самом деле твик 4.1 не был применён, так как я не был уверен в надёжности питания у клиента.

Hyper-V 2 CPU	KVM 2 CPU	KVM 4 CPU

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

KVM из коробки 2 CPU	KVM после твиков 2 CPU

Мы видим, что удалось существенно ускорить работу дисковой подсистемы в qemu (kvm) при одном и том же числе ядер. Запись была ускорена в среднем на 58%, а чтение на 25%.

Основные элементы успеха: использование LVM-томов вместо файлов qcow2, отдельный поток ввода/вывода и hugepages.

Замеченные ошибки направляйте в личку. Повышаю за это карму.

P.S. vhost-user-blk и vhost-user-nvme

В ходе экспериментов были также и скомпилированы Qemu 2.12 и 3-й версии. Тестировалась опция vhost-user-blk для диска.

В итоге она работала хуже, чем virtio-blk.

vhost-user-blk 4 CPU	virtio-blk 4 CPU

Для использования vhost-user-nvme нужно было патчить qemu, этот вариант усложнял автоматическое обновление серверов в продакшене, поэтому не был протестирован.

P.P.S. SPDK

Intel разработала этот фреймворк для достижения выдающихся показателей производительности у дисковых систем в виртуальных машинах, которые должны работать на её процессорах.

Чтобы заставить spdk хорошо работать идут на массу ухищрений — выделяют ему отдельные ядра, размещают ядра spdk и виртуальной машины в одном сокете. Загружают виртуальную машину в непрерывный кусок памяти. Если такие меры применять к обычному virtio-blk, то он тоже будет быстрее работать.

SPDK способен работать в 3-х режимах: vhost-user-scsi, vhost-user-blk и vhost-user-nvme. Второй режим доступен только в qemu от 2.12, который ещё не доступен в ubuntu. Режим vhost-user-nvme вообще мегаэкспериментальный — для него нужно патчить qemu. На текущий момент работает только эмуляция scsi и она медленная.

Есть ещё одно серьёзное ограничение для режима vhost-user-scsi — диск spdk не может быть загрузочным.

Make sure bootindex=2 Qemu option is given to vhost-user-scsi-pci device.

Рекорды ставятся, когда они с помощью своего драйвера разделяют SSD на несколько устройств и прокидывают их как vhost-user-nvme. Подход с прокидыванием железа нам не подходил.

Сложилось впечатление, что нормально использовать SPDK можно только с их реализацией логических дисков (которая совершенно отличается от стандартных lvm). Это такой самопальный велосипед со своими снимками и клонированием. Команды все отличаются от LVM.

Сложность в настройке SPDK, поддержке и переносимости виртуальных машин, а также привязанность к процессорам Intel отвернула от его использования.

Благодарности

За изображение спасибо TripletConcept. Его лучше смотреть в полном размере в отдельном окне.

За разрешение поделиться рабочими материалами — st_neon

Вы можете заказать виртуальную машину с SSD у RUVDS по купону ниже.

Замеченные ошибки направляйте в личку. Повышаю за это карму.

Читайте также: