На тематических форумах периодически задают вопросы о технических особенностях SSD. Я решил скомпилировать имеющуюся у меня информацию, благо команда в которой я работаю проводила тестирование на предмет использования SSD на серверах.
Итак, SSD это хранилище с настоящим random доступом к данным. Здесь нет никаких движущихся головок, так что latency чтения не зависит от физического расположения страниц данных. Для HDD используется специальная техника называемая IO Scheduling предназначенная для оптимизации движения головки диска. Для SSD порядок чтения страниц неважен.Кроме того при повышении количества потоков одновременно считывающих данные общая пропускная способность SSD растет при постоянной latency. В тестах, где потоки последовательно читают страницы по 4 KiB, пропускная способность достигает своего пика при ~100 потоках после чего начинает медленно падать.
Latency операции на чтение равняется приблизительно 135us + 5us*NumOfBlocks где NumOfBlocks количество считываемых 4 KiB страниц. Чем больше размер считываемого файла тем выше пропускная скорость. Так для больших файлов скорость составляет 600-650 MiB/s. Технология SLC показывает скорость чтения на несколько процентов выше чем MLC.
Суммируя два вышеназванных факта, можно сказать, что SSD идеальны для приложений с большим количеством random-access операций чтения. Таких как современные базы данных.
Скорость записи варьируется и зависит от Сборщика мусора. Это связано с тем, что перед тем как перезаписать страницу она должна быть очищена. Но в связи с физическими ограничениями технологии NAND очистить можно только лишь большими блоками, обычно 256 KiB. Предположим, что нам надо перезаписать одну лишь страницу. Для этого контроллер производит следующие действия:
- Прочитать данные со всех активных страниц блока
- Очистить весь блок (256 KiB)
- Записать данные активных страниц, включая новые данные для перезаписываемой страницы
Эта операция (известная как write amplification) замедляет процесс записи в случае если диск долгое время не форматировался.
Для свежеотформатированного привода скорость записи составляет ~480 MiB/s для SLC, ~280 MiB/s для Intel MLC, ~260 MiB/s для Samsung MLC. При эффективности сборщика мусора в 50% (то есть 50% блоков требуется очистить перед записью) скорость записи SLC снижается до ~130 MiB/s (то есть в 3.5 раза).
Надежность. Ошибки происходят при записи страницы и при ее чтении. Если контроллер не может записать страницу (например выработан ресурс ячеек) - то страница маркируется как испорченная. При ошибках чтения сложнее. Так современные SSD используют коррекцию ошибок основанная на кодировке Соломона-Рида и контроллер может восстановить до 6 ошибочных бит на каждые 256 байт. Подобное корректирование ошибок происходит прозрачно для приложения. При большем количестве непрочитанных бит - страница маркируется как испорченный. Тесты для Micron MLC показали, что отказ чтения страницы составляет ~6.8e-15 что примерно соответствует показателю HDD.
Износ. У HDD ресурс определяется количеством часов работы. Это связано с тем что самым слабым звеном являются движущиеся части (подшипники, считывающая головка). Для современных HDD это число является порядка миллиона часов. Для SSD износ определяется тем сколько раз можно записать в ячейку. Ресурс ячейки сильно зависит от технологии Multi-level cell vs Single-level cell.
Ожидаемое количество циклов записи следующее для технологий:
SLC - 100,000
Intel MLC - 5,000
Samsung MLC - 1,500
Данные цифры предоставлены мне нашими "железячниками", в то же время wikipedia говорит что у MLC ресурс равен 10,000. Так что цифры требуют подтверждения.
При нагрузке записи в 100 MiB/s на привод размером в 480GiB ожидаемое время жизни
SLC - 15 лет
Intel MLC - 9 месяцев
Samsung MLC - 3 месяца
Это ожидаемое время. После как ресурс ячеек выработается - диск продолжет работать, но количество ошибок чтения/записи возрастет.
PS Если у вас имеются дополнения/уточнения - буду рад добавить их в статью.
-
Ухты, круто.
Можно пару вопросов?
При эффективности сборщика мусора в 50% скорость записи SLC снижается до ~130 MB/s (то есть в 3.5 раза).
Она снижается - когда? После выработки ожидаемого времени жизни?
отказ чтения блока на современных SSD составляет ~ 6.8e-15
Это в каких единицах?
-
-
Это в каких единицах?
Видимо, это вероятность отказа p. Измеряется в долях единицы: 0 ≤ p ≤ 1. Если умножить на 100, получим проценты.
-
Это в каких единицах?
Быть может это вероятность события?
Автор, у Вас в статье упомянут такой момент, ожидаемое время жизни диска (хотя корректно ли SSD называть "диском"?) при нагрузке записи в 100 МБ/с. Это при постоянно нагрузке на одну ячейку?
ЕщЁ мне я читал в сети, что после износа ячейки возможность писать в неЁ пропадает, но возможность читать нет. Судя по Вашей статье, чтение по истечению кол-ва циклов записи тоже будет страдать, я правильно понимаю?
-
Она снижается - когда? После выработки ожидаемого времени жизни?
когда эффективность сборщика мусора равна 50%. Я добавил разъяснение.
Это в каких единицах?
Это вероятность события того, что блок не прочитается.
Это при постоянно нагрузке на одну ячейку?
Это нагрузка на весь привод (в 480G).
Судя по Вашей статье, чтение по истечению кол-ва циклов записи тоже будет страдать, я правильно понимаю?
Судя по заявлениям производителей error rate и для чтения и для записи будет расти по истечении времени жизни привода.
-
Собирал инфу по ssd перед покупкой, могу добавить инфы.
1. Количество циклов перезаписи зависит от техпроцесса, 10k это вроде для MLC 40 нм, сейчас уже делают 34 нм, там 5k, но и плотность выше, то есть формально разницы нет. Однако в реальности износ повышается частой перезаписью мелких файлов, у которых размер меньше блока перезаписи (в данный момент 256-512 kb), поэтому уменьшение техпроцесса не такое уж и благо. Интел хотели решить эту проблему, но о результатах мне не известно
2. Сборщик мусора TRIM должен функционировать на уровне файловой системы и должнна быть поддержка ядра, это доступно в данный момент для windows 7 и linux (btrfs начиная с 2.6.32 и ext4 начиная с 2.6.33), в остальных случаях придется использовать костыли в виде скриптов с форума OCZ
3. Нагрузка записи это не всегда в скорости надо считать.. Вам просто надо посчитать емкость диска и число циклов перезаписи и получите время при заданной норме записи в день/месяц/год. Например в домашней системе ssd 80 gb проживет лет 10. Потому что я прикинул сколько в сутки я могу записывать на диск данных. А скорость может быть любая. Прикиньте на глаз погрешность от мелких файлов и неравномерный износ. Интел обещают примерно 80% эффективность выравнивания износа. После износа ячейки получите read only без всяких ошибок. Хотя для БД именно из-за интенсивной и постоянной записи годятся только SLC
-
Раз уж мы об этом заговорили - можно я спрошу, да?
Дома сервер, на сервере - FreeBSD, transmission-daemon, httpd, php, mySQL. Собственно, там лежит и на наго качается кино, помимо этого - каталог имеющегося кино с веб-мордой.
Так вот, вопрос.
Если я беру флэшку. И ставлю на нее фряху. И монтирую /var/log в память.
Сколько проживет флэшка?
-
-
Присоединяюсь к вопросу. И сколько, если логи оставить на месте?
-
Флэшка или SSD?
-
-
Флэшка, просто флэшка.
Меня жаба давит, большая и зеленая, SSD покупать за те деньги что щас за них просят.
-
-
Ну ты б ещё 512 гигов заказал у своей жабы. 60 гб - более чем достаточно.
А на флэшку мне кажется нет смысла ставиться потому что там один чип обычно и тупой контроллер. Просто не будет выигрыша в скорости.
-
-
Да, но дело не в скорости, а в том, что не шумит.
Потому что 4 винта по 2 Тб, на которых хранится вся фигня - WD Green, которые не шумят. Ну в смысле, не сильно. Да и замедляются к тому же, когда не используются.
Вентилятор на процессоре – едва шелестит, блок питания тоже тихий.
И получается, что самый источник шума – это системный винт.
Можно, конечно, заменить его на такой же винт, но новый - но хочется же кардинально проблему решить.
-
-
Ну фиг знает, я бы лучше на нормальные блины поставился, чем на всякое гамно. Тем более я сомневаюсь, что фря с флэшками дружит...
-
-
А почему нет-то… Не все равно, с чего грузится?
В общем, я думаю, что стоит попробовать, а потом рассказать, как дело было :-)
-
-
В общем, я думаю, что стоит попробовать, а потом рассказать, как дело было :-)
Вот все бы так! (=
|
|
|
Последние посты
|
|
Последние комментарии
|
|
Изменения
|
|
Черновики (все)
|
|
Избранное (всё)
|
|
|