Раньше у нас долгое время для кеширования random IO использовались intel 320 серии. Это было умеренно быстро, в принципе, позволяло сократить число шпинделей. При этом обеспечение высокой производительности на запись требовало, мягко говоря, неразумное количество SSD.
Наконец, в конце лета к нам приехал Intel 910. Сказать, что я глубоко впечатлён — не сказать ничего. Весь мой предыдущий скепсис относительно эффективности SSD на запись развеян.
Впрочем, обо всём по порядку.
Intel 910 — это карточка формата PCI-E, довольно солидных габаритов (под стать дискретным видеокартам). Впрочем, я не люблю unpack-посты, так что перейдём к самому главному — производительности.
Картинка для привлечения внимания
Цифры реальные, да, это сто тысяч IOPS'ов на произвольную запись. Подробности под катом.
Описание устройства
Но сначала мы поиграем в Alchemy Classic, в которой если перетащить один LSI поверх 4х Hitachi, то получится Intel.
Устройство представляет собой особым образом адаптированный LSI 2008, к каждому порту которого «подключено» по одному SSD устройству ёмкостью 100Гб. Фактически все подключения выполнены на самой плате, так что подключение видно только при анализе взаимоотношений устройств.
Примерная схема такая:
Заметим, LSI'ный контроллер перепилен очень сильно — у него нет своего биоса, он не умеет быть загрузочным. В lspci он выглядит так:
04:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
Subsystem: Intel Corporation Device 3700
Структура устройства (4 SSD'шки по 100Гб) подразумевает, что пользователь сам решит, как именно использовать устройство — raid0 или raid1 (для тонких ценителей — raid5, хотя с большой вероятностью это будет самая большая глупость, которую можно сделать с устройством подобного класса).
Обслуживается он драйвером mpt2sas.
К нему подключено 4 scsi устройства, которые объявляют себя hitachi:
sg_inq /dev/sdo Vendor identification: HITACHI Product identification: HUSSL4010ASS600
Никаких расширенных sata-команд они не поддерживают (так же как и большинство расширенных сервисных команд SAS) — только минимум необходимого для полноценной работы в качестве блочного устройства. Хотя, к счастью, поддерживает sg_format с опцией resize, что позволяет сделать полноценное резервирование для меньшего влияния housekeeping'а при активной записи.
Тестирование
Всего мы делали 5 разных тестов, позволяющие оценить характеристики устройства:
- тест на произвольное чтение
- тест на произвольную запись
- тест на смешанное параллельное чтение/запись (заметим, говорить про пропорции «чтения/записи» не приходится, т.к. каждый поток «молотил» отдельно друг от друга, конкурируя за ресурсы, как это чаще всего бывает в реальной жизни).
- тест на максимальную линейную производительность на чтение
- тест на максимальную линейную производительность на запись
Тесты на линейные чтение и запись
В общем случае, эти тесты мало кому интересны, для обеспечения «потока» HDD подходят куда лучше, т.к. у них выше ёмкость, ниже цена и весьма приличная линейная скорость. Простенький сервер с 8-10 SAS-дисками (или даже быстрыми SATA) в raid0 вполне способен забить десятигигабитный канал.
Но, всё-таки, вот показатели:
Линейное чтение
Для максимальных показателей мы выставили 2 потока по 256к на каждое устройство. Итоговая производительность: 1680МБ/с, без колебаний (девиация составила всего 40 мкс). Lantency при этом составила 1.2мс (для блока 256к это более чем хорошо).
Фактически, это означает, что в одиночку это устройство на чтение способно полностью «в потолок» забить канал 10Гбит/с и показывать более чем впечатляющие результаты на канале в 20Гбит/с. При этом оно будет показывать постоянную скорость работы вне зависимости от нагрузки. Заметим, сам Intel обещает до 2ГБ/с.
Линейная запись
Для получения самых высоких цифр по записи нам пришлось снизить глубину очереди — один поток на запись на каждое устройство. Остальные параметры были аналогичными (блок 256к)
Пиковая скорость (секундные отсчёты) составила 1800МБ/с, минимум — около 600МБ/с. Средняя скорость записи 100% составила 1228МБ/с. Внезапное снижение скорости записи — родовая травма SSD из-за работы housekeeping'а. В данном случае падение было до 600МБ/с (примерно в три раза), что лучше, чем в старых поколениях SSD, где деградация могла доходить до 10-15 раз. Intel обещает скорость порядка 1.6ГБ/с при линейной записи.
random IO
Разумеется, линейная производительность никого не интересует. Всем интересна производительность под тяжёлой нагрузкой. А что может быть самым тяжёлым для SSD? Запись на 100% объёма, мелкими блоками, во много потоков, без перерывов в течение нескольких часов. На 320ой серии это приводило к падению производительности с 2000 IOPS до 300.
Параметры теста: raid0 из 4х частей устройства, делается linux-raid (3.2), 64-бита. Каждая задача с режимом randread или randwrite, для смешанной нагрузки описываются 2 задачи.
Заметим, в отличие от многих утилит, которые соотносят число операций чтений и записи в фиксированном процентном соотношении, мы запускаем два независимых потока, один из которых всё время читает, другой всё время пишет (это позволяет полнее нагрузить оборудование — если у устройства проблемы с записью, оно всё ещё может продолжать обслуживать чтение). Остальные параметры: direct=1,buffered=0, режим io — libaio, блок 4к.
Random read
| iodepth | IOPS | avg.latency |
|---|---|---|
| 1 | 7681 | 0,127 |
| 2 | 14893 | 0,131 |
| 4 | 28203 | 0,139 |
| 8 | 53011 | 0,148 |
| 16 | 88700 | 0,178 |
| 32 | 98419 | 0,323 |
| 64 | 112378 | 0,568 |
| 128 | 148845 | 0,858 |
| 256 | 149196 | 1,714 |
| 512 | 148067 | 3,456 |
| 1024 | 148445 | 6,895 |
Заметно, что оптимальной нагрузкой является что-то порядка 16-32 операций одновременно. Очередь длинной в 1024 добавлена из спортивного интереса, разумеется, это не является адекватными показателями для product (но даже в этом случае latency получается на уровне довольно быстрого HDD).
Random write
| iodepth | IOPS | avg.latency |
|---|---|---|
| 1 | 14480 | 0,066 |
| 2 | 26930 | 0,072 |
| 4 | 47827 | 0,081 |
| 8 | 67451 | 0,116 |
| 16 | 85790 | 0,184 |
| 32 | 85692 | 0,371 |
| 64 | 89589 | 0,763 |
| 128 | 96076 | 1,330 |
| 256 | 102496 | 2,495 |
| 512 | 96658 | 5,294 |
| 1024 | 97243 | 10,52 |
Аналогично — оптимум находится в районе 16-32 одновременных операций, путём весьма значительного (10-кратного роста) latency можно «выжать» ещё 10к IOPS.
Интересно, что на малой нагрузке производительность на запись выше. Вот сравнение двух графиков — чтения и записи в одном масштабе (чтение — зелёным):
Смешанная нагрузка
Самый тяжёлый вид нагрузки, который можно считать заведомо превышающим любую практическую нагрузку в продакт-среде (включая OLAP).
Поскольку по этому графику реальную производительность не понять, то вот те же цифры в куммулятивном виде:
| iodepth | IOPS read | IOPS write | avg.latency |
|---|---|---|---|
| 1+1 | 6920 | 13015 | 0,141 |
| 2+2 | 11777 | 20110 | 0,166 |
| 4+4 | 21541 | 33392 | 0,18 |
| 8+8 | 36865 | 53522 | 0,21 |
| 16+16 | 44495 | 58457 | 0,35 |
| 32+32 | 49852 | 58918 | 0,63 |
| 64+64 | 55622 | 63001 | 1,14 |
Видно, что оптимальная нагрузка так же находится в районе от 8+8 (то есть 16) до 32. Таким образом, не смотря на очень высокие максимальные показатели, нужно говорить про максимум в ~80к IOPS при нормальной нагрузке.
Заметим, получившиеся цифры больше чем обещает intel. На сайте они заявляют, что эта модель способна на 35 kIOPS на запись, что примерно соответствует (на графике производительности) точке с iodepth около 6. Так же, возможно, эта цифра соответствует наихудшему случаю для housekeeping'а.
Единственным минусом этого устройства являются определённые проблемы с горячей заменой — PCI-E устройства требуют обесточивать сервер перед заменой.
Автор: amarao
