Процент попадания в кэш, базовая метрика в вашем инструментарии (FVP, часть 10)

Эта статья часть цикла "Evaluating an acceleration platform". В статье “Acceleration layer architecture and I/O request” из этой серии я пояснил, почему некоторые тесты не применимы при тестировании производительности в инфраструктуре, оснащенной такими платформами ускорения как FVP.

Ускорение чтений
При ускорении чтений одна из ключевых точек - последующие повторные чтения. Для ускорения скорости чтения данные должны быть расположены на флеш-устройстве. Это может достигаться путем хранения данных непосредственно на флеш-устройстве или посредством "фиктивных" записей. Фиктивная запись возникает в том случае, когда запрошенные данные недоступны на флеш-устройстве. Данные извлекаются из датастора, передаются приложению и одновременно копируются на флеш-устройство.

После того, как данные сохранены на флеш-устройство, следующие операции ввода-вывода, обращающиеся к этим данным, могут быть обработаны флеш-устройством. На случай, если вы не были в курсе, операции "Чтение после записи" (Read After Write - RAW) являются частыми операциями на уровне приложений.

Когда запрошенные данные располагаются на флеш-устройстве, это является попаданием в кэш, что формирует показатель попадания в кэш, являющийся очень важной метрикой при тестировании или поиске проблем с производительностью. Иными словами, попадание в кэш напрямую связано с задержками. После добавления нового уровня вы можете читать и писать на различные устройства, имеющие собственные показатели задержек: задержки флеш-устройства, задержки датастора. Вам нужно определить, какое устройство обслуживает запрос ввода-вывода.

Я полагаю, что предоставление этой информации является критичным, когда вы работаете с платформой ускорения промышленного уровня. Показатель Flash Read Cache ПО VMware vSphere предоставляет эту информацию через команды esxcli (подробности в замечательном посте Дункана), FVP демонстрирует эту информацию на графиках производительности.

Проверка теории
Давайте взглянем на графики производительности. В этом тесте я использовал приложение, которое предоставляло видеосервис. В первом тесте приложение извлекало видео по запросу пользователя. Так как видео было новым контентом для этого сервера, то оно считывалось из датастора. Это приводило к нулевому попаданию в кэш.

При просмотре показателей задержек вы можете увидеть, что эффективная задержка близка к задержке датастора. Значение эффективной латентности показывает задержку на уровне виртуальной машины.

Когда другой пользователь снова запрашивает видео, то данные выгружаются с флеш-устройства, так как FVP произвел фиктивную запись и скопировал данные при обработке предыдущего запроса приложения. Попадание в кэш теперь равно 100%.

Интересен тот факт, что показатель эффективной задержки теперь ближе к задержке флеш-устройства, чем к задержке датастора. Больше не имеет значения насколько загружен датастор при обработке ввода-вывода. Приложение работает с малыми задержками и стабильной предсказуемой производительностью.

Работа DRS
Производительность, которую предоставляет локальный флеш-ресурс, позволяет минимизировать накладные расходы. Не задействуется сеть хранения данных, отсутствует дополнительная нагрузка, разделяющаяся на контроллеры хранения или группы жестких дисков. Ближе к 2014 году мобильность виртуальных машин прочно укоренилась в повседневных процедурах современного датацентра, но мы почему-то продолжаем жить в 2013 году. FVP полностью поддерживает мобильность виртуальных машин, предоставляя бесшовный пул флеш-ресурсов. Ввод-вывод может быть обработан с локального или сетевого флеш-устройства.

Ключевой особенностью ПО FVP является то, что оно предоставляет данные по запросу, избегая непроизводительной деградации флеша и избыточных накладных расходов. Когда приложение запрашивает данные, FVP обслуживает запрос из флеш-устройства, локального или удаленного. Кроме того, FVP стремится сохранить флеш как можно ближе к приложению и копирует данные на локальное флеш-устройство с удаленного, тем самым гарантируя, что повторные операции чтения будут обработаны из ближайшего к приложению флеш-устройства. За дополнительной информацией вы можете обратиться к статье "Работа FVP с удаленным флеш-устройством (FVP, часть 4)".

Виртуальная машина мигрирует на другой хост и в 09:45 повторно запрашивает тот же видеофайл.

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

Эффективная задержка не равна локальному флешу или задержке датастора, по факту, она чуть больше сетевой задержки.
Для наглядности я выбрал настраиваемый график и включил метрики локального и сетевого чтения.

На этом графике видно, что сетевое флеш-устройство обрабатывает ввод-вывод. Это флеш-устройство хоста, на котором раньше работала виртуальная машина.

Видео воспроизводилось 2 минуты, а на предыдущем хосте - 5-6 минут. Пользователь снова проигрывает видеофайл, но уже то же время, что и в первых двух тестах.

Снова показатель попадания в кэш равен 100%, показывая что ввод-вывод обрабатывается из флеш-устройства. Но из какого флеш-устройства? Так как FVP копирует данные на локальное флеш-устройство, то первые 3 минуты видеофайла снова обрабатываются локальным флешем. Удаленный флеш неактивен первые 3 минуты, но после того, как воспроизводимое видео переходит эту отметку, FVP снова продолжает извлекать данные из удаленного флеш-устройства.

Как это отражается на задержках?

Тест начался в 09:59; эффективная задержка была близка к задержкам локального флеш-устройства, но после трех минут задержка приблизилась к задержкам сетевого флеш-устройства.

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

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