Почему IOPS – это не важно

Долгое время основной метрикой производительности дисковой подсистемы были IOPS. Первые промышленные системы хранения, с которыми работал автор, обеспечивали порядка 20 тысяч IOPS. Годы спустя автор приобрел широкие знания в области измерения производительности хранилищ данных (став IOMeter гиком) и регулярно демонстрировал потрясающие значения IOPS для различных систем хранения.



Спустя 18 месяцев работы в компании, занимающейся высокопроизводительными системами хранения данных, автор понял, что IOPS – это не важно.

Кому нужны все эти IOPS?

На сегодня сложно найти на корпоративном рынке системы хранения данных, которые не предоставляют минимум 100К IOPS. Некоторые вендоры сообщают о миллионах или десятках миллионов IOPS.

Пользователям нужны это значения? Правда? Нет!

Типичному пользователю на Enteprise рынке, использующему обычный набор корпоративных приложений и сервисов, физических и облачных серверов в пике обычнно нужно около 30-40 тысяч IOPS (за исключением, возможно, специфически нагруженных баз данных). InfoboxCloud может обеспечить необходимую производительность дисковой подсистемы (~63000 iops в тесте SQLIO с размером блока 4кб), подходящую более чем 99% пользователей.

Как измерить IOPS? Что о Latency?

При тестировании систем хранения, стандартная практика — использование промышленных бенчмарков, таких как fio, SQLIO, IOMeter, vdbench для понимания, сколько IOPS система может выдать в различных IO профилях.

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

Почему так? Потому что большинство профилей в бенчмарках основаны на маленьких (4кб, 8кб IOPS) в то время, как средний размер блока в процессе работы пользователей обычно составляет от 32 до 64кб. Менее 5% пользователей используют блоки менее 10KB. Менее 15% пользователей используют блоки менее 20KB.

Даже в едином приложении (например в базе данных) будут использоваться различные варианты IO–нагрузки для различных компонентов движка (файлы данных, логи, индексы).

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

Можно ли говорить о задержках (latency) как об объективном показателе производительности систем хранения данных? Нет :)

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

Хорошо, если IOPS и задержки — не очень хороший способ измерения производительности дисковой подсистемы, как же быть?

Запускайте приложение с вашими данными, а не бенчмарк!


Есть только один реальный способ понять, насколько быстро будет работать ваше приложение с конкретной дисковой подсистемой — запустить его и поработать с ним!

Если вы тестируете систему бенчмарком — единственное приложение, для которого будут ценны результаты — этот бенчмарк!

Идеальный случай, когда для тестирования вы размещаете свое промышленное приложение с промышленными данными. Если вы не можете этого сделать — скопируйте приложение или тестовое окружение и попробуйте сэмулировать выполнение задач, которые будут выполняться на промышленном сервере. Измерьте, как приложение будет обрабатывать реальные данные и реальные нагрузки!

Измеряйте метрики приложения, а не подсистемы хранения!

Какая польза от измерений IOPS и задержек все-таки? После получения этих данных они будут возможно будут полезны только администратору системы хранения.

Ваших пользователей и руководителя не интересуют IOPS и задержки. Им нужно, чтобы сервисы и приложения решали их задачи.

Ценные метрики совсем другие:
  • Как долго выполняется ежедневная задача в приложении?
  • Как быстро ваша система бизнес-аналитики может сделать данные доступными для принимающих решения?
  • Как часто вы можете обновлять тестовые сервера и сервера разработки из производственной базы данных?
  • Много ли времени займет развертывание виртуальных серверов, которые нужны ежедневно?
  • Как много пользователей вы можете обслуживать без заботы о проблемах производительности?
  • Как быстро будет перестроен OLAP куб? Можете ли вы его перестраивать каждый день, а не каждую неделю?

Чтобы тратить время на тестирование правильно, измеряйте то, что реально важно!

Тестирование облачных серверов в вашем окружении с вашими приложениями — единственный способ объективно оценить их для вашей задачи. Не доверяйте техническим спецификациям или заявлениям вендоров: тестируйте реальную систему в вашем окружении с вашими данными.

Если вы хотите попробовать облако InfoboxCloud для ваших реальных задач — напишите нам! И после мы будем рады услышать от вас, как облако работает с вашими реальными системами и данными и работать с вами, чтобы сделать ваших пользователей довольными, а бизнес — успешным!

Спасибо компании Pure Storage за замечательную статью!

0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.