Comments 22
Простите за глупый вопрос: а как сейчас дела с TRIM обстоят в RAID0 и 1?
Я что-то слышал про Intel RST 11.5, но на практике-то как?
Я что-то слышал про Intel RST 11.5, но на практике-то как?
Спасибо за вопрос, TRIM в накопителях Intel 710 поддерживается, для ответа про поддержку Intel RST 11.5 надо немного больше времени
Когда ж вы научитесь не мегабайты а иопсы мерить, а? Вы сами-то из этих цифр что-то понимаете?
iops'ы в общем случае тоже никого не волнуют. Что лучше — система, которая выдаёт 2к IOPS при latency в 1мс или система, которая выдаёт 20к IOPS при latency в 300мс?
ты меня честно говоря поставил в тупик ) у меня левел по стореджам сильно ниже конечно, но вот уж кто точно бесполезен в обзоре SSD — это мегабайты/сек. Мне в моей работе с высоконагруженными SQL серверами и хостами на Hyper-V всегда хватало тестирования по иопсам чтобы спланировать нагрузку.
так что же лучше? и что почитать про латенси?
так что же лучше? и что почитать про латенси?
Понимаете, тут есть две стороны планирования: планирование СХД с точки зрения поставщика (того, кто смотрит на итоговую загрузку на хост) и с точки зрения потребителя (приложения), которого волнует только то, «насколько оно тормозить будет».
Правило большого пальца — latency на СХД не должна превышать 20мс для (70-90)% запросов. Если превышает, то сколько бы IOPS не показывала система, она не даёт адекватной скорости большинству приложений.
Правило большого пальца — latency на СХД не должна превышать 20мс для (70-90)% запросов. Если превышает, то сколько бы IOPS не показывала система, она не даёт адекватной скорости большинству приложений.
Ну умом я это понимаю, но откуда это правило? Есть гайдлайны, бестпрактисы от вендоров?
И как разумнее всего ее оптимизировать, от чего она зависит?
И как разумнее всего ее оптимизировать, от чего она зависит?
Нет никаких гайдлайнов. В этом-то и проблема. Половина вендоров вообще ни сном ни духом. Когда я адаптек спросил, в каком режиме их контроллер даст наименьшую latency, то мне вообще ответили ахинею про 50к IOPS на контроллер и скорость работы.
… Как оптимизировать latency? Я бы много дал за хороший ответ на этот вопрос. Пока что ограничиваюсь эмпирическим анализом — пробую варианты, какой даёт меньше latency, тот и использую.
… Как оптимизировать latency? Я бы много дал за хороший ответ на этот вопрос. Пока что ограничиваюсь эмпирическим анализом — пробую варианты, какой даёт меньше latency, тот и использую.
А как понять что приложение тормозит? Ну то есть есть у меня виртуальная машина, в которой я допустим запускаю некое приложение, которое при старте активно использует диск. Я же не знаю насколько быстро оно должно работать? Ну то есть я конечно могу увидеть, что очередь запросов к диску вырастает, то есть запросы не успевают обрабатываться. Глупо оптимизировать СХД или наращивать мощности до тех пор, пока очередь не перестанет возникать — нужен же некоторый компромисс между стоимостью и откликом.
Ну то есть например гугл говорит, что если веб-страница отдается меньше чем за две секунды — это очень хорошо, а секунда — вообще супер. То есть на этом этапе можно прекращать оптимизации и жить спокойно, зная что у тебя все хорошо. А вот как понять что СХД медленнее, чем «рекомендуется» — не ясно.
Ну то есть например гугл говорит, что если веб-страница отдается меньше чем за две секунды — это очень хорошо, а секунда — вообще супер. То есть на этом этапе можно прекращать оптимизации и жить спокойно, зная что у тебя все хорошо. А вот как понять что СХД медленнее, чем «рекомендуется» — не ясно.
В отношении конкретных приложений — специфично для приложения (т.е. это программист должен сказать «если мы не успели за это время сделать вот это — значит тормозим). Общее же правило — смотреть на latency запроса. Как только запрос болтается в очереди и не исполняется (или исполняется долго) — это повод считать данный запрос „лагающим“ (интутитивно, правда?). Более менее разумной цифрой является 20мс (хотя это неким образом произвол, например, можно для себя установить лимит в 5мс или в 500).
То есть следует различать „быстро работает“ и „не справляется“. Первое — субъективно и определяется потребителем. Второе — объективно и означает, что входящих данных в приложение больше, чем возможности по записи (пример — периодическое скидывание базы типа redis, если оно не управляется за время между периодами — значит, дисковая подсистема не соответствует запросам редиса — либо поднимать время, либо ускорять СХД).
То есть следует различать „быстро работает“ и „не справляется“. Первое — субъективно и определяется потребителем. Второе — объективно и означает, что входящих данных в приложение больше, чем возможности по записи (пример — периодическое скидывание базы типа redis, если оно не управляется за время между периодами — значит, дисковая подсистема не соответствует запросам редиса — либо поднимать время, либо ускорять СХД).
latensy это обратная величина от IOPS. То есть количество операций ввода-вывода обратно пропорционально величине задержки.
количество операций ввода-вывода в единицу времени
Не совсем так. Поскольку запросы могут приходить в параллель, итоговая производительность (не планируемая!) определяется как iops=1/latency*queue_depth. В принципе, в условиях «неограниченно большой очереди» (что правда для большинства СХД) можно было бы говорить о том, что недобор по latency компенсируется глубиной очереди. Однако, в реальной жизни, когда мы говорим про субъективное «тормозит или нет», некоторые операции являются зависимыми (т.е. следующая операция будет выполнена после успешного выполнения текущей), таким образом для этих операций «торможение» определяется именно latency, причём довольно драматично. Например, 10мс при очереди в 30 даёт нам 3к IOPS, а 5 мс при глубине очереди в 15 — те же 3к IOPS. При этом для конкретного приложения рост производительности будет (в худшем случае) двухкратным (например, если у нас хитрая БД, которая все транзакцию выполняет за один IO и ждёт подтверждения перед выполнением следующей). В реальной жизни всё зависит от параллелизма операций со стороны приложений и как часто они используют барьеры.
Почему нет графика IOPS?
Количество IOPS которое выдает зависит от размера блока, мы указываем на графике размер блока и потоковую производительность при операциях с этим блоком. Действительно, можно было указать размер блока и IOPS, но графики при этом не сильно изменятся. Пожелание насчет показать время доступа тоже — учтем.
Вы в курсе, что iometer (точнее, dynamo) безбожно врёт под линуксом? Используйте fio, там куда более разумные показатели раз, два, оно может писать лог latency, что куда интереснее, чем попугаи в секунду.
«Т. к. ресурс записи 600-1500ТБ достаточен для большинства приложений в серверах мы планируем использовать диски Intel SSD 710...»
это откуда такие цифры если не секрет? Одна MLC ячейка по 25нм технологии имеет ресурс перезаписей всего порядка нескольких тысяч раз. Типа перезапись 100 гигабайт 6000 раз это 600TБ? А ведь как правило весь диск полностью не перезаписывается, есть часть диска на котором лежит редко изменяемая информация, и часть диска на котором лежит часто изменяемая информация… При соотношении этих частей в пользу первой ресурс записи окажется катастрофически мал.
это откуда такие цифры если не секрет? Одна MLC ячейка по 25нм технологии имеет ресурс перезаписей всего порядка нескольких тысяч раз. Типа перезапись 100 гигабайт 6000 раз это 600TБ? А ведь как правило весь диск полностью не перезаписывается, есть часть диска на котором лежит редко изменяемая информация, и часть диска на котором лежит часто изменяемая информация… При соотношении этих частей в пользу первой ресурс записи окажется катастрофически мал.
Данные по ресурсу записи — Intel SSD 710 — официальные, для дисков емкостью 100GB — это 600ТБ, для диска 400GB до 1500ТБ. Это новые диски с технлогией MLC NAND cм — www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-710-series.html
Sign up to leave a comment.
Сравнительный анализ производительности дисковых подсистем серверов с применением SSD. Часть II