Cache Hit и производительность СХД

Когда дизайн дисковых систем делается под профиль нагрузки заказчика, может возникнуть необходимость учета такого параметра как Cache Hit. При переходе от системы с маленьким объемом кэша к системе с кэшем существенно большего размера можно ожидать роста этого показателя. Сам факт положительного влияния кэш-памяти на производительность дисковых систем несомненен. Что же касается количественного результата, то по этому поводу 100% понимания можно и не встретить: http://wikibon.org/wiki/v/Calculating_the_max_IOPS

В итоге, на такой вопрос:

«Если СХД работает под некоторой нагрузкой и дает сейчас 1000 IOPS без кэша, то сколько она будет давать IOPS при наличии кэш-памяти и 85% попадании в кэш?»

Можно получить такой неправильный ответ:

«При добавлении кэша количество IOPS станет равно 1000 IOPS с дисков (это 15%) и еще плюс (1000/15)*85=5667 IOPS (то есть 85% кэш-хит), что в сумме дает 6667 IOPS которое мы будем получать с дисковой системы когда добавим кэш.»

Ошибка состоит в том, что предполагается сохранение уровня нагрузки на диски, в то время, как нагрузка на диски станет меньше как раз за счет перехода части операций на уровень кэша. Тут можно услышать возражение, что

«6667 IOPS это новый максимум системы».

И это тоже неверно. Потому что максимальное количество IOPS которое можно получить работая напрямую с кэшем на порядки больше. Таким образом полученный ответ в 6667 IOPS вообще не релевантен.

В то же время, это важно в расчетах проектируемой СХД.

Я хочу здесь разобрать пример, который, надеюсь, поможет всем нам прийти к общему знаменателю.

Для начала, зададим точку отсчета. Откуда берутся IOPS-ы? Они приходят с сервера, где работает приложение, к которому подключены пользователи, выполняющие свои бизнес-задачи.

То есть, возвращаясь к примеру, это наше приложение отправляет на дисковую подсистему 1000 операций, или другими словами пользователи что-то там делают: пишут письма, выполняют проводки, отгрузки, выписывают счета, переводят деньги между счетами итп.

И вот, мы добавили кэш, и увеличился кэш-хит (в примере — до 85%). Что произошло? Стали писать в несколько раз больше писем, выписывать счетов, делать проводок итп? Достаточно очевидно, что нет. Небольшое количественное улучшение по IOPS можно ожидать, но оно будет не кардинальным.

Однако, влияние 85% попадания в кэш все же есть. Оно весьма ощутимо выражается в том, что время выполнения транзакций сократилось, письма стали ходить быстрее, то есть, время реакции системы стало объективно лучше. Таким образом, добавление кэша в этом случае привело к снижению времени отклика приложения. Вопрос теперь состоит в том, как количественно это измерить? Если мы остаемся в рамках одномерной производительности, то задача нерешаема. Ведь число пользовательских операций осталось на том же уровне. В данном случае имеет смысл говорить о связке IOPS и времени отклика, записываемой как IOPS@ms.

Тогда задача и решение будет выглядеть следующим образом:

«Пусть у нас было время отклика дисков 10 мс и выполнялось 1000 IOPS при нулевом попадании в кэш. То есть 1000 IOPS@10 мс. Мы проектируем систему, которая будет обеспечивать 85% операций из кэша. Какая будет произвоительность дисковой системы?»

Ответ:

«Число IOPS само по себе не вырастет, но время отклика улучшится. Улучшенное время отклика рассчитывается по формуле: (1000IOPS*15%*10мс+1000IOPS*85%*1мс)/1000IOPS=2.35 мс

Где 10 мс — время отклика дисков, а 1 мс — время отклика кэш-памяти. То есть, пользователи увидят улучшение времени отклика примерно в 4 раза.»

Строго говоря, снижение нагрузки на диски в 5-6 раз приведет к улучшению собственного времени отклика дисков, которое является однозначной функцией утилизации дисков, и мы можем учесть это в нашей формуле. Однако, это выходит за рамки данной статьи, и может быть освещено отдельно, если хотите.

Кроме того, профиль нагрузки почти всегда дается со смесью чтения и записи (например, чтение 70%, запись 30%) и поэтому ответ на вопрос можно немного модернизировать. Но так как выкладки там сложнее, и требуют более обстоятельных пояснений, то я могу это сделать в отдельном посте.

.

Ключевые метрики производиельности СХД

Главная мысль, которую я здесь доношу, состоит в том, что Cache Hit в реальном окружении сказывается в первую очередь на времени отклика, и лишь очень опосредованно может привести к росту числа IOPS.

Вторая мысль состоит в том, что производительность задается не одним, а несколькими параметрами. Если требуется определенное количество IOPS, то — нужно при этом, хотя бы указывать IOPS и желательное время отклика системы.

Тоже самое применимо и в обратную сторону — при проектировании СХД под определенное число IOPS необходимо указывать время отклика, которая СХД будет обеспечивать для отдельных операций.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s