How to become an author
Search
Write a publication
Pull to refresh

Comments 22

Простите за глупый вопрос: а как сейчас дела с TRIM обстоят в RAID0 и 1?
Я что-то слышал про Intel RST 11.5, но на практике-то как?
Total votes 2: ↑2 and ↓0+2
Спасибо за вопрос, TRIM в накопителях Intel 710 поддерживается, для ответа про поддержку Intel RST 11.5 надо немного больше времени
Total votes 3: ↑3 and ↓0+3
Когда ж вы научитесь не мегабайты а иопсы мерить, а? Вы сами-то из этих цифр что-то понимаете?
Total votes 4: ↑1 and ↓3-2
iops'ы в общем случае тоже никого не волнуют. Что лучше — система, которая выдаёт 2к IOPS при latency в 1мс или система, которая выдаёт 20к IOPS при latency в 300мс?
Total votes 5: ↑5 and ↓0+5
ты меня честно говоря поставил в тупик ) у меня левел по стореджам сильно ниже конечно, но вот уж кто точно бесполезен в обзоре SSD — это мегабайты/сек. Мне в моей работе с высоконагруженными SQL серверами и хостами на Hyper-V всегда хватало тестирования по иопсам чтобы спланировать нагрузку.

так что же лучше? и что почитать про латенси?
This comment wasn’t rated yet0
Понимаете, тут есть две стороны планирования: планирование СХД с точки зрения поставщика (того, кто смотрит на итоговую загрузку на хост) и с точки зрения потребителя (приложения), которого волнует только то, «насколько оно тормозить будет».

Правило большого пальца — latency на СХД не должна превышать 20мс для (70-90)% запросов. Если превышает, то сколько бы IOPS не показывала система, она не даёт адекватной скорости большинству приложений.
Total votes 3: ↑3 and ↓0+3
Ну умом я это понимаю, но откуда это правило? Есть гайдлайны, бестпрактисы от вендоров?
И как разумнее всего ее оптимизировать, от чего она зависит?
This comment wasn’t rated yet0
Нет никаких гайдлайнов. В этом-то и проблема. Половина вендоров вообще ни сном ни духом. Когда я адаптек спросил, в каком режиме их контроллер даст наименьшую latency, то мне вообще ответили ахинею про 50к IOPS на контроллер и скорость работы.

… Как оптимизировать latency? Я бы много дал за хороший ответ на этот вопрос. Пока что ограничиваюсь эмпирическим анализом — пробую варианты, какой даёт меньше latency, тот и использую.
Total votes 1: ↑1 and ↓0+1
А как понять что приложение тормозит? Ну то есть есть у меня виртуальная машина, в которой я допустим запускаю некое приложение, которое при старте активно использует диск. Я же не знаю насколько быстро оно должно работать? Ну то есть я конечно могу увидеть, что очередь запросов к диску вырастает, то есть запросы не успевают обрабатываться. Глупо оптимизировать СХД или наращивать мощности до тех пор, пока очередь не перестанет возникать — нужен же некоторый компромисс между стоимостью и откликом.

Ну то есть например гугл говорит, что если веб-страница отдается меньше чем за две секунды — это очень хорошо, а секунда — вообще супер. То есть на этом этапе можно прекращать оптимизации и жить спокойно, зная что у тебя все хорошо. А вот как понять что СХД медленнее, чем «рекомендуется» — не ясно.
Total votes 2: ↑1 and ↓10
В отношении конкретных приложений — специфично для приложения (т.е. это программист должен сказать «если мы не успели за это время сделать вот это — значит тормозим). Общее же правило — смотреть на latency запроса. Как только запрос болтается в очереди и не исполняется (или исполняется долго) — это повод считать данный запрос „лагающим“ (интутитивно, правда?). Более менее разумной цифрой является 20мс (хотя это неким образом произвол, например, можно для себя установить лимит в 5мс или в 500).

То есть следует различать „быстро работает“ и „не справляется“. Первое — субъективно и определяется потребителем. Второе — объективно и означает, что входящих данных в приложение больше, чем возможности по записи (пример — периодическое скидывание базы типа redis, если оно не управляется за время между периодами — значит, дисковая подсистема не соответствует запросам редиса — либо поднимать время, либо ускорять СХД).
Total votes 1: ↑1 and ↓0+1
latensy это обратная величина от IOPS. То есть количество операций ввода-вывода обратно пропорционально величине задержки.
Total votes 1: ↑1 and ↓0+1
количество операций ввода-вывода в единицу времени
Total votes 1: ↑1 and ↓0+1
Не совсем так. Поскольку запросы могут приходить в параллель, итоговая производительность (не планируемая!) определяется как iops=1/latency*queue_depth. В принципе, в условиях «неограниченно большой очереди» (что правда для большинства СХД) можно было бы говорить о том, что недобор по latency компенсируется глубиной очереди. Однако, в реальной жизни, когда мы говорим про субъективное «тормозит или нет», некоторые операции являются зависимыми (т.е. следующая операция будет выполнена после успешного выполнения текущей), таким образом для этих операций «торможение» определяется именно latency, причём довольно драматично. Например, 10мс при очереди в 30 даёт нам 3к IOPS, а 5 мс при глубине очереди в 15 — те же 3к IOPS. При этом для конкретного приложения рост производительности будет (в худшем случае) двухкратным (например, если у нас хитрая БД, которая все транзакцию выполняет за один IO и ждёт подтверждения перед выполнением следующей). В реальной жизни всё зависит от параллелизма операций со стороны приложений и как часто они используют барьеры.
Total votes 2: ↑2 and ↓0+2
И время доступа тоже покажите. Пока что это не обзор, а огрызок.
Total votes 6: ↑4 and ↓2+2
Количество IOPS которое выдает зависит от размера блока, мы указываем на графике размер блока и потоковую производительность при операциях с этим блоком. Действительно, можно было указать размер блока и IOPS, но графики при этом не сильно изменятся. Пожелание насчет показать время доступа тоже — учтем.
Total votes 4: ↑3 and ↓1+2
Вы в курсе, что iometer (точнее, dynamo) безбожно врёт под линуксом? Используйте fio, там куда более разумные показатели раз, два, оно может писать лог latency, что куда интереснее, чем попугаи в секунду.
Total votes 1: ↑1 and ↓0+1
Спасибо, обязательно сравним с fio под linux. В данных тестах использовался Iometer, под Windows.
Total votes 1: ↑1 and ↓0+1
Так что вы сравнивать будете? Мб/с? Да у меня на любой супермикровской коробке минимум 2-3Гб/с raw read.

Где реальные-то цифры производительности?
Total votes 2: ↑2 and ↓0+2
«Т. к. ресурс записи 600-1500ТБ достаточен для большинства приложений в серверах мы планируем использовать диски Intel SSD 710...»

это откуда такие цифры если не секрет? Одна MLC ячейка по 25нм технологии имеет ресурс перезаписей всего порядка нескольких тысяч раз. Типа перезапись 100 гигабайт 6000 раз это 600TБ? А ведь как правило весь диск полностью не перезаписывается, есть часть диска на котором лежит редко изменяемая информация, и часть диска на котором лежит часто изменяемая информация… При соотношении этих частей в пользу первой ресурс записи окажется катастрофически мал.
This comment wasn’t rated yet0
ох не верю я в эти чиселки, после того как три диска из предыдущей модели показали по 50 реаллоков после всего одного записаного терабайта (на все три, то есть по 330гиг на брата)
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr