Низкая скорость ssd linux

Низкая скорость SSD

Всем привет. Не могу понять, почему мой SSD диск, который стоит в ноуте и подключен через SATAII, имеет низкую скорость. Например:

Делал /sbin/fstrim —all, немного на небольшое время помогает.

Тест dd для /dev/sda2 (/home):

Возможно, сам SSD не отдаёт данные быстрее.

Где низкая? Сколько по паспорту? По USB низкая. Без UASP, наверно.

Читать-писать нули, или пустой диск — это тупо. Контроллер может честно выдавать любые данные на максимальной скорости при чтении с trim’нутого диска. А нули, и даже повторяющиеся последовательности контроллер может сжимать.

Ну открой википедию хотя бы..

All SATA data cables meeting the SATA spec are rated for 3.0 Gbit/s and handle modern mechanical drives without any loss of sustained and burst data transfer performance. However, high-performance flash-based drives can exceed the SATA 3 Gbit/s transfer rate; this is addressed with the SATA 6 Gbit/s interoperability standard.

Там в идеальных тепличных условиях 300МБ, у тебя 200, что не так?

Про сата2 уже сказали, добавлю, что асинхронная запись 5 гигов с помощью дд может показать абсолютно что угодно.

Скажи спасибо, что вообще рабоатет.

Не знал, что такие дешёвые SSD вообще существуют

dd if=/dev/zero of=./largefile bs=5M count=1024

Не очень хорошая идея. Есть сжимающие ssd контроллеры.

Ээээ. а ты в курсе, что даже с хорошим контроллером, скорость SSD зависит от объема? Там RAID0 из нескольких флэшек. Твои данные абсолютно нормальны, низкой скорости просто не вижу. С учетом ультра дешевого диска — радуйся, что работает.

Источник

Возможно ли каким-либо образом повысить скорость чтения\записи SSD в Linux?

Здравствуйте. Имеется домашний многофункциональный WiFi-роутер на основе следующего железа:

На SSD установлен Debian 7.5.0 Wheezy. Здесь заявлено о том, что скорость чтения составляет

270 Mb/s, однако, результаты вывода команды:

Возможно ли каким-либо образом увеличить скорость чтения\записи или такая скорость предельно возможная для такого железа?

240 метров в секунду — это далекие результаты от 270?

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

Валяющиеся в инете графики, полученные на основании данных iometer демонстрируют 270 МБ/с, но при queue depth > 2. А при queue depth = 1, что-то около 235 МБ/с.

а на файлах какая скорость?

У вас нормальная скорость, как правило цифры из спецификаций несколько отличаются от реальных.

Возможно ли каким-либо образом увеличить скорость чтения\записи

для этого существует raid0

Попробовал замерить так:

Скорость чтения какая-то совсем уж нереальная (не уверен, что сей метод правильный). Если первую команду повторить следом ещё раз, то скорость уже будет ниже. От 150 Mb/s до 212 Mb/s. Если какое-то время подождать и снова выполнить первую команду, то вновь будет 236-251 Mb/s.

ктож dd скорость-то мерит

Возможно имеет значение указание специальных параметров для SSD (вынос /tmp в tmpfs, особые опции монтирования, загрузки, ну, и всё, что полагаетсся для SSD) Вот что показывает у меня:

# hdparm -tT /dev/sda && hdparm —direct -tT /dev/sda

/dev/sda: Timing cached reads: 44101 MB in 1.99 seconds = 22160.80 MB/sec Timing buffered disk reads: 2106 MB in 3.00 seconds = 702.03 MB/sec

/dev/sda: Timing O_DIRECT cached reads: 1410 MB in 2.00 seconds = 704.68 MB/sec Timing O_DIRECT disk reads: 2106 MB in 3.00 seconds = 701.86 MB/sec

Мне одному кажется, что где-то в районе 4-го поста тебе подсказали что, возможно, может помочь?

Возможно ли каким-либо образом увеличить скорость чтения\записи

такая скорость предельно возможная для такого железа?

Скорость чтения какая-то совсем уж нереальная (не уверен, что сей метод правильный).

Смотря что измерять, если дисковый кэш, то реальная. Если скорость чтения диска, то перед dd нужно сборсить дисковый кэш:

Источник

Ещё один блог сисадмина

воскресенье, 6 сентября 2020 г.

Оптимизация Linux при использовании SSD

Изменение планировщика ввода-вывода

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

Изменить планировщик диска sda можно при помощи следующей команды:
Для того, чтобы выбранный планировщик диска применялся при загрузке системы, можно поставить пакет sysfsutils:
Оптимизация Linux при использовании SSD
И прописать планировщик в файл /etc/sysfs.conf:
Другой способ сделать изменения постоянными — создать файл /etc/udev/rules.d/60-ssd.rules со следующими правилами udev:
Это правило для всех не вращающихся дисков с именем sd* будет устанавливать планировщик deadline.

Размер страницы

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

Например, по данным SMART размер логического сектора диска равен 512 байтам, а размер страницы равен 4096 байт:
Убедиться в том, что ядро операционной системы Linux знает о размере физического сектора, можно следующим образом:

Увеличение резерва страниц

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

Часть общего объёма страниц диска закладывается в резерв. Напрмер, SSD объёмом 480 Гигабайт может иметь реальный объём 512 Гигабайт, а разница используется как раз для равномерного использования ресурса всех страниц.

Кроме того, в файловой системе может иметься свободное место, не занятое никакими данными. Это свободное место на SSD можно приобщить к резерву. Для этого операционная система может сообщать диску о неиспользуемых ею страницах при помощи ATA-команды TRIM. Для этого SSD должен поддерживать операцию TRIM, а файловая система должна поддерживать опцию монитрования discard.

Проверить наличие поддержки TRIM в SSD можно при помощи утилиты hdparm:
Вторая строчка означает, что секторы, над которыми произведена команда TRIM, при попытке чтения будут возвращать нули. Другим возможным режимом может быть «Deterministic read after TRIM», когда при чтении возвращаются не нули, а какая-то другая всегда одинаковая последовательность данных.

Если на странице руководства man mount среди опций интересующей файловой системы имеется опция discard, то файловую систему можно перемонтировать с поддержкой этой опции.

Сначала посмотрим, с какими опциями смонтирована файловая система:
Перемонтируем файловую систему, добавив к списку опций remount и discard:
Убеждаемся, что новая опция добавилась к текущему списку:
Чтобы отключить опцию discard, можно повторить процедуру перемонтирования, указав вместо опции discard опцию nodiscard.

Чтобы при перезагрузке операционная система монтировала файловую систему с опцией discard, нужно добавить её к списку опций монитрования в файле /etc/fstab. Например, строчка монтирования может выглядеть следующим образом:
Чтобы сообщить диску о неиспользуемых секторах, которые были освобождены до включения опции discard, или при отключенной опции discard, можно воспользоваться командой fstrim:
Кроме увеличения ресурса диска, использование TRIM и discard может приводить к увеличению скорости операций записи и чтения. Т.к. у контроллера есть в распоряжении много очищенных блоков, ему не придётся тратить время на их очистку для записи новых данных. При этом операция очистки блока может выполняться в фоновом режиме, когда SSD не занят выполнением операций чтения или записи.

Источник

Оптимизация Ubuntu (и прочих Linux-ов) под SSD

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

Первое, с чего стоит начать — это выбор файловой системы. Если система на десктопе — то особо вопросов не возникает — брать журналируемую 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 прослужит вам верой и правдой, и с каждым стартом будет радовать хорошей скоростью.

Источник