15 октября 2009 г.

Utilization

Очень важной метрикой оценки производительности является коэффициент использования или утилизация (Utilization). Как и многие другие, этот термин имеет несколько значений и поэтому всегда должен использоваться с указанием контекста.

Utilization физического (диска, порта и т. д.) или логического устройства (RAID Group, LUN и т.п.) определяется как доля времени, в течение которого оно было занято выполнением какой-либо работы. Или, другими словами, утилизация за определенное время выборки (Sampling Interval) равна отношению суммарного периода занятости устройства (Busy Interval) к указанному интервалу времени.


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


Если замеры производятся с постоянной периодичностью, а время выборки кратно интервалу замеров, то Utilization можно рассчитать просто усреднением количества опросов состояния устройства с результатом “занято”.


Так, при расчете LUN Utilization во время замера проверяется наличие хотя бы одного запроса, стоящего в очереди на обслуживание к логическому тому. Не зависимо от текущей длины очереди, замер вернет либо 0% либо 100% занятости. Суммарная Utilization получается усреднением значений всех замеров за время выборки.
Таким образом, Utilization устройства показывает только наличие, а не величину нагрузки. Ее высокие значения сами по себе не могут быть поводом для обоснованных выводов о наличии или отсутствии проблемных мест. Посему, любые предположения о производительности устройств на основе Utilization обязательно должны подтверждаться другими метриками.


При оценке используемых объемов или значений некоторых метрик производительности, зачастую более удобно работать с результатами, нормированными по максимально возможным или доступным значениям. Для их описания часто тоже используется термин утилизация. Так, например, RAID Group Utilization равна отношению суммарного объема всех LUN, созданных на данной RAID Group к ее общему объему. Bandwidth Utilization канала равна отношению текущего показателя полосы пропускания к ее максимально возможному значению.


Оценка  утилизации устройств и основных метрик обычно является первым шагом при анализе производительности. Какие значения этой Utilization можно было бы считать заслуживающими внимания эксперта на начальных этапах обследования? Универсального совета, к сожалению, нет. На это, конечно, влияет большое количество факторов. Тем не менее, многие специалисты соглашаются с тем, что в качестве первого приближения можно считать значение 72%.
Поясню на примере зависимости Response Time от Throughput Utilization. На многих графиках, полученных экспериментальным путем, именно значение 72% является точкой перегиба. При больших значениях показатель Response Time становится очень высоким. Более того, он делается очень чувствительным и изменяется в очень широких пределах даже при незначительных изменениях нагрузки. Позднее (здесь и здесь) я еще раз вернусь к причинам такого поведения.


Конечно, было бы здорово иметь достаточно ресурсов для того, чтобы всегда оставаться в левой части графика, т. е. иметь гарантированно низкое Response Time. Но за все надо платить и в этом случае буквально, деньгами. При Utilization 50% половина имеющихся ресурсов просто бездельничает. Поэтому чаще всего стоит вопрос пусть не о самой лучшей, но приемлемой для продуктивной работы производительности по умеренной цене за используемые ресурсы. Диапазон от 62% до 76% называется зоной оптимальной нагрузки (Capacity Zone). Считается, что система, работающая в этом диапазоне Utilization, имеет наилучшие значения $/производительность.
Конечно, с учетом требований к масштабируемости или заранее известным пиковым нагрузкам, Capacity Zone может сместиться к более низким значениям.

Существует очень простая зависимость между средними значениями Utilization, Throughput и Service Time, которая называется теорема Литтла:


Эта формула широко применяется для оценки загруженности компонент дисковых подсистем. Например, можно легко рассчитать, что жесткий диск, обрабатывающий в среднем 40IOPS с Service Time 10ms нагружен всего на 40% (40IOPS*0,01sec).

7 комментариев:

  1. В одном из докуметов по системам хранения наткнулся на такие рекомендации:
    RG Busy% < 50%
    - Array Group utilization should be less than 50%.
    - Reserve capacity is required for sparing.
    Может быть здесь под утилизацией RG подразумевается суммарная утилизация всех шпинделей с точки зрения их занятости по запросам, а не по объему LU?
    Bastik.

    ОтветитьУдалить
  2. Раз тема посвящена утилизации, то мне кажется можно добавить такой параметр, как Cache Utilization. В большинстве случаев параметр абсолютно бесполезный, но все же, хотелось бы услышать мнение эксперта по этому вопросу.
    Bastik.

    ОтветитьУдалить
  3. Ссылка на документ: https://tuf.hds.com/wiki/pub/Main/ReduceWritePending/37021_WhitePaper_GT_CC.pdf Это по поводу утилизации raid групп, страница 12.

    ОтветитьУдалить
  4. В приведенном контексте RG Busy%, конечно, считается не по объему. Чтобы как-то комментировать рекомендацию <50% нужно искать глоссарий и читать как этот термин определила HDS. Фантазии о том, что теоретически это может означать - пустое занятие.

    Cache Utilization можно считать как по нагрузке, так и по объему. Опять же надо смотреть точное определение термина. Из своего опыта анализа производительности EMC Symmetrix и Clariion могу полностью согласиться, что этот параметр не сильно полезный.

    ОтветитьУдалить
  5. Василий, прошу понять меня правильно :) Я не оспариваю значение метрик, которые вы нам любезно разъясняете. Просто хочу показать, что некоторые из них могут трактоваться по-разному, в зависимости от производителей систем хранения, чтобы люди менее сведущие в этих вопросах не наступали на грабли при анализе производительности. Тем болле что упоминания о EMC в данном посте не было.
    Bastik.

    ОтветитьУдалить
  6. Алексей, это же блог, а не учебник ;) Ко всей представленной здесь информации изначально надо относиться скептически... :)

    Я с вами на все 200% согласен! Термины могут трактоваться по разному в зависимости от нескольких десятков разных факторов. http://hengooru.blogspot.com/2009/10/blog-post_11.html

    Мой подход следующий. В ранних постах я определил, что понимаю под тем или иным термином, а далее их просто использую. В данном конкретном примере, к описанию утилизации можно относиться как к широко распространенному (но не единственному) способу дефиниции.
    К EMC эти определения имеют достаточно опосредованное отношение. Честно могу признаться, что в плане терминологического бардака эта компания не является исключением из правил и во многих документах с логотипом "where information lives" одни и теже слова используются в совершенно противоположных смыслах... ;)

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.