Нравится мне книжка Кэри Миллсапа и Джеффа Хольта “Oracle оптимизация производительности”. В Oracle я не силен, зато подходы к анализу производительности там очень правильные и стиль изложения простой... Вот еще одна цитата:
“ Модернизация оборудования - последняя из возможностей, которую следует рассматривать при повышении производительности. Последнее место она занимает по вполне очевидным причинам:
• Дорогостоящая модернизация оборудования редко способна дать тот же эффект, что и недорогие мероприятия по исключению бесполезной нагрузки.
• Плохо спланированная модернизация оборудования может в действительности ухудшить производительность пользовательской операции, которую вы пытаетесь ускорить.
Многие руководители считают модернизацию беспроигрышным вложением, считая, что “Разве может быть слишком много процессоров (памяти, дисков и т. д.)?”. Расхожее мнение гласит, что даже если модернизация напрямую не решит имеющуюся проблему производительности, то как она сможет навредить? Ведь дополнительные мощности, так или иначе, будут использованы, разве нет? Увы, не всегда. Далеко не все осознают риск, связанный с принятием такого решения.
…
Более близкое знакомство с законом Амдала помогло мне понять, что любая модернизация может привести к снижению производительности какой-либо пользовательской операции вследствие возникновения конкуренции за ресурс, который не был модернизирован. Вопрос только в том, заметит ли кто-нибудь эти ухудшения”.
28 октября 2009 г.
21 октября 2009 г.
Базовые зависимости
Изменение характеристик потока ввода-вывода либо параметров HBA , каналов передачи и конфигурации дисковых массивов, влечет за собой плавное либо скачкообразное изменение всех описанных выше взаимозависимых метрик. Например, рост Throughput влечет за собой увеличение Bandwidth.
Более четко эта зависимость выражается следующей формулой:
Т. е. Throughput прямо пропорциональна Bandwidth и обратно пропорциональна размеру блока данных Request Size. Сразу оговорюсь, что в реальной жизни эта зависимость, конечно, не линейна и зависит еще от множества параметров. Здесь же я привожу эту упрощенную формулу с тем, чтобы было проще запомнить взаимное “направление” изменения параметров. При постоянной Throughput увеличение размера блока ведет к росту общего объема передаваемых данных, т. е. Bandwidth. И, наоборот, при постоянной Bandwidth, увеличение размера блоков приводит к возможности передавать данные меньшим количеством пакетов и, соответственно, снижению Throughput.
При постоянных характеристиках ввода-вывода увеличение количества пакетов приводит к росту общего объема передаваемых данных.
Как уже говорилось, Response Time зависит от Queue Length и Service Time.При увеличении нагрузки на дисковый массив, растет длина очереди, увеличивается общее количество запросов, требующих записи и чтения данных между кэшем и физическими накопителями в Back-end. Поэтому Response Time нелинейно зависит от Throughput.
Эта зависимость мало заметна при низких значениях пропускной способности, но имеет очень важное значение при высоких нагрузках.
Конечно, форма этой кривой будет сильно отличаться для различных моделей и конфигураций систем хранения. Некоторые дисковые массивы среднего уровня могут показать очень высокий уровень производительности при малых нагрузках, но на серьезных задачах заметно уступят своим более мощным High-end собратьям. Это еще раз доказывает, что ко многим опубликованным синтетическим тестам производительности дисковых массивов стоит относиться с осторожностью, понимая общие условия тестирования и специфику нагрузки.
Напомню, что для улучшения общей производительности системы хранения нам нужно стремиться к уменьшению Response Time. Как этого можно достичь хотя бы в теории? Например, можно увеличить размер передаваемых блоков при постоянном значении Bandwidth.
Можно попробовать увеличить общий объем кэш или поместить тома данных на большем количестве жестких дисков.
На предыдущую зависимость можно посмотреть немножко с другой стороны. Увеличение количества дисковых накопителей в Back-end приводит к повышению Throughput.
Эту закономерность можно использовать, например, когда нам по каким-то причинам необходимо увеличить размер блока данных. Соответствующее падение Throughput можно хотя бы частично компенсировать за счет расположения данных на большем количестве шпинделей.
Более четко эта зависимость выражается следующей формулой:
Т. е. Throughput прямо пропорциональна Bandwidth и обратно пропорциональна размеру блока данных Request Size. Сразу оговорюсь, что в реальной жизни эта зависимость, конечно, не линейна и зависит еще от множества параметров. Здесь же я привожу эту упрощенную формулу с тем, чтобы было проще запомнить взаимное “направление” изменения параметров. При постоянной Throughput увеличение размера блока ведет к росту общего объема передаваемых данных, т. е. Bandwidth. И, наоборот, при постоянной Bandwidth, увеличение размера блоков приводит к возможности передавать данные меньшим количеством пакетов и, соответственно, снижению Throughput.
При постоянных характеристиках ввода-вывода увеличение количества пакетов приводит к росту общего объема передаваемых данных.
Как уже говорилось, Response Time зависит от Queue Length и Service Time.При увеличении нагрузки на дисковый массив, растет длина очереди, увеличивается общее количество запросов, требующих записи и чтения данных между кэшем и физическими накопителями в Back-end. Поэтому Response Time нелинейно зависит от Throughput.
Эта зависимость мало заметна при низких значениях пропускной способности, но имеет очень важное значение при высоких нагрузках.
Конечно, форма этой кривой будет сильно отличаться для различных моделей и конфигураций систем хранения. Некоторые дисковые массивы среднего уровня могут показать очень высокий уровень производительности при малых нагрузках, но на серьезных задачах заметно уступят своим более мощным High-end собратьям. Это еще раз доказывает, что ко многим опубликованным синтетическим тестам производительности дисковых массивов стоит относиться с осторожностью, понимая общие условия тестирования и специфику нагрузки.
Напомню, что для улучшения общей производительности системы хранения нам нужно стремиться к уменьшению Response Time. Как этого можно достичь хотя бы в теории? Например, можно увеличить размер передаваемых блоков при постоянном значении Bandwidth.
Можно попробовать увеличить общий объем кэш или поместить тома данных на большем количестве жестких дисков.
На предыдущую зависимость можно посмотреть немножко с другой стороны. Увеличение количества дисковых накопителей в Back-end приводит к повышению Throughput.
Эту закономерность можно использовать, например, когда нам по каким-то причинам необходимо увеличить размер блока данных. Соответствующее падение Throughput можно хотя бы частично компенсировать за счет расположения данных на большем количестве шпинделей.
19 октября 2009 г.
Теорема Литтла (Little’s Law)
Чуть раньше я упомянул теорему Литтла. Оказывается, это очень интересная штука...
Первое доказательство теоремы было представлено сравнительно недавно - в 1961г. Оно было сделано Джоном Литтлом (John Dutton Conant Little), который последние 47 лет работает профессором Массачусетского Технологического Института. Кроме теоремы, Литтл известен своими работами по маркетингу и считается родоначальником научного подхода в этой области (marketing science).
Классическая, более известная формулировка теоремы гласит, что среднее количество клиентов (N) в стабильно-функционирующей системе, равно произведению усредненной скорости прибытия клиентов (lambda) на среднее время, которое они проводят в системе(T):
Хочется заметить, что это, на первый взгляд, простое соотношение, удивительным образом никак не зависит от распределения вероятности прибытия клиентов и, соответственно, не требует никаких знаний или предположений о том по каким расписаниям они будут появляться и обслуживаться в системе.
Рассмотрим пример применения теоремы. Предположим, мы знаем, что в среднем в небольшой банк каждые 2 минуты заходит клиент и там он проводит около 10мин. В соответствии с теоремой можно сделать вывод о том, что обычно там единовременно находятся 5 человек (0,5чел/мин * 10мин.). И наоборот, если помещение холла этого банка позволяет одновременно пребывать не более чем 10 клиентам, то необходимо постараться, чтобы каждый человек дождался своей очереди и был обслужен в среднем за 20 мин. (10чел. / 0,5чел/мин.).
Первое доказательство теоремы было представлено сравнительно недавно - в 1961г. Оно было сделано Джоном Литтлом (John Dutton Conant Little), который последние 47 лет работает профессором Массачусетского Технологического Института. Кроме теоремы, Литтл известен своими работами по маркетингу и считается родоначальником научного подхода в этой области (marketing science).
Классическая, более известная формулировка теоремы гласит, что среднее количество клиентов (N) в стабильно-функционирующей системе, равно произведению усредненной скорости прибытия клиентов (lambda) на среднее время, которое они проводят в системе(T):
Хочется заметить, что это, на первый взгляд, простое соотношение, удивительным образом никак не зависит от распределения вероятности прибытия клиентов и, соответственно, не требует никаких знаний или предположений о том по каким расписаниям они будут появляться и обслуживаться в системе.
Рассмотрим пример применения теоремы. Предположим, мы знаем, что в среднем в небольшой банк каждые 2 минуты заходит клиент и там он проводит около 10мин. В соответствии с теоремой можно сделать вывод о том, что обычно там единовременно находятся 5 человек (0,5чел/мин * 10мин.). И наоборот, если помещение холла этого банка позволяет одновременно пребывать не более чем 10 клиентам, то необходимо постараться, чтобы каждый человек дождался своей очереди и был обслужен в среднем за 20 мин. (10чел. / 0,5чел/мин.).
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).
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).
11 октября 2009 г.
Опять о терминологии
К сожалению, в различной англоязычной литературе нет единодушия по поводу использования терминов Bandwidth и Throughput. Даже в документах на смежные темы Throughput может употребляться как в качестве пропускной способности, так и полосы пропускания.
В статьях на русском языке горячо любимая “пропускная способность” вообще зачастую употребляется как синоним “производительности”. А универсальный термин “скорость передачи” может заменять собой Bandwidth, Throughput или Transfer Rate.
В таком терминологическом беспорядке при чтении литература нас могут выручить только знание предметной области и понимание контекста употребления. Например, можно догадаться, о чем идет речь при описании “Transaction and Throughput-oriented applications”, или “анализе пропускной способности резервного копирования” ;) .
Личные беседы с коллегами на профессиональные темы всегда стоит начинать с терминологических договоренностей. Потраченные пять минут помогут вам в дальнейшем сэкономить кучу времени. Сколько раз все мы присутствовали и даже участвовали в жарких, но совершенно бесполезных спорах, причиной которых, на поверку, оказывалось простое непонимание друг друга...
В статьях на русском языке горячо любимая “пропускная способность” вообще зачастую употребляется как синоним “производительности”. А универсальный термин “скорость передачи” может заменять собой Bandwidth, Throughput или Transfer Rate.
В таком терминологическом беспорядке при чтении литература нас могут выручить только знание предметной области и понимание контекста употребления. Например, можно догадаться, о чем идет речь при описании “Transaction and Throughput-oriented applications”, или “анализе пропускной способности резервного копирования” ;) .
Личные беседы с коллегами на профессиональные темы всегда стоит начинать с терминологических договоренностей. Потраченные пять минут помогут вам в дальнейшем сэкономить кучу времени. Сколько раз все мы присутствовали и даже участвовали в жарких, но совершенно бесполезных спорах, причиной которых, на поверку, оказывалось простое непонимание друг друга...
9 октября 2009 г.
Transfer Rate, Bandwidth и Throughput
Для определения аппаратной производительности компонентов и каналов доступа часто используется метрика скорости передачи (Transfer Rate), которая описывает количество битов информации, передаваемых по каналу в единицу времени, и измеряется в Gigabit per second (Gbps или Gbit/s).
Хочу обратить ваше внимание на то, что Transfer Rate является параметром производительности передачи всех данных, т. е. как полезной, так и служебной информации. Объем только полезных данных, передаваемых в единицу времени, описывается метрикой ширина полосы пропускания (Bandwidth). Она чаще всего измеряется в Megabytes per second (MB/s).
Сам объем полезных данных в I/O запросах далее по контексту я буду называть размером блока данных или Request Size.
Из Transfer Rate можно вычислить максимальное теоретически достижимое значение Bandwidth. Реальный максимум пропускной способности будет немного меньше теоретического. Пример для интерфейсов Fibre Channel показан в таблице:.
Конечно, текущее значение Bandwidth может отличаться от максимального. Но, при этом, передача битов данных по каналу будет все равно производиться на скорости Transfer Rate. К примеру, 2Gbps FC HBA сервера, генерирующего нагрузку всего 50MB/s, все равно будет передавать данные лазерными импульсами с частотой ~2,126GHz. Более того, протокол Fibre Channel требует постоянного заполнения канала, поэтому в нашем случае приблизительно ? данных, передаваемых по оптическому линку, будут “пустыми” примитивами IDLE.
Количество операций ввода-вывода, передаваемых в единицу времени позволяет оценить метрика пропускной способности (Throughput). Измеряется она в I/Os per second (IOPS).
Стоит заметить, что чаще всего для описания требований к производительности конкретных приложений используется только одна из метрик Throughput или Bandwidth. Для программных комплексов, выполняющих операции произвольного доступа блоками данных малого размера (например, OLTP - Online Transaction Processing, web-серверы, файловые серверы) важно получить максимальное количество пакетов в минимальные сроки. Поэтому для них основной метрикой производительности является Throughput. Напротив, приложения, ориентированные на операции с последовательным потоком данных большими блоками (например, DSS - Decision Support System, обработка видео, высокопроизводительные вычисления HPC, резервное копирование), в первую очередь требуют высоких общих объемов переданной полезной информации. Соответственно для них наиболее критичной является метрика Bandwidth.
Очень важно применять правильную метрику в каждом конкретном случае. Например, рассуждения о Bandwidth при оценке производительности OLTP-приложения, могут быть расценены коллегами как признак непрофессионализма.
В качестве небольшой подсказки, когда стоит применять ту или иную метрику, можно использовать следующую довольно условную градацию приложений по типу ввода-вывода.
Хочу обратить ваше внимание на то, что Transfer Rate является параметром производительности передачи всех данных, т. е. как полезной, так и служебной информации. Объем только полезных данных, передаваемых в единицу времени, описывается метрикой ширина полосы пропускания (Bandwidth). Она чаще всего измеряется в Megabytes per second (MB/s).
Сам объем полезных данных в I/O запросах далее по контексту я буду называть размером блока данных или Request Size.
Из Transfer Rate можно вычислить максимальное теоретически достижимое значение Bandwidth. Реальный максимум пропускной способности будет немного меньше теоретического. Пример для интерфейсов Fibre Channel показан в таблице:.
Тип FC интерфейса | Transfer Rate | Теоретическая макс. Bandwidth half duplex | Реальная макс. Bandwidth half duplex | Реальная макс. Bandwidth full duplex |
1GFC | 1,063Gbps | 100MB/s | 90MB/s | 0,18GB/s |
2FGC | 2,126Gbps | 200MB/s | 180MB/s | 0,36GB/s |
4GFC | 4,252Gbps | 400MB/s | 360MB/s | 0,72GB/a |
8GFC | 8,5Gbps | 800MB/s | 720MB/a | 1,44GB/s |
Конечно, текущее значение Bandwidth может отличаться от максимального. Но, при этом, передача битов данных по каналу будет все равно производиться на скорости Transfer Rate. К примеру, 2Gbps FC HBA сервера, генерирующего нагрузку всего 50MB/s, все равно будет передавать данные лазерными импульсами с частотой ~2,126GHz. Более того, протокол Fibre Channel требует постоянного заполнения канала, поэтому в нашем случае приблизительно ? данных, передаваемых по оптическому линку, будут “пустыми” примитивами IDLE.
Количество операций ввода-вывода, передаваемых в единицу времени позволяет оценить метрика пропускной способности (Throughput). Измеряется она в I/Os per second (IOPS).
Стоит заметить, что чаще всего для описания требований к производительности конкретных приложений используется только одна из метрик Throughput или Bandwidth. Для программных комплексов, выполняющих операции произвольного доступа блоками данных малого размера (например, OLTP - Online Transaction Processing, web-серверы, файловые серверы) важно получить максимальное количество пакетов в минимальные сроки. Поэтому для них основной метрикой производительности является Throughput. Напротив, приложения, ориентированные на операции с последовательным потоком данных большими блоками (например, DSS - Decision Support System, обработка видео, высокопроизводительные вычисления HPC, резервное копирование), в первую очередь требуют высоких общих объемов переданной полезной информации. Соответственно для них наиболее критичной является метрика Bandwidth.
Очень важно применять правильную метрику в каждом конкретном случае. Например, рассуждения о Bandwidth при оценке производительности OLTP-приложения, могут быть расценены коллегами как признак непрофессионализма.
В качестве небольшой подсказки, когда стоит применять ту или иную метрику, можно использовать следующую довольно условную градацию приложений по типу ввода-вывода.
- Если размер блоков передаваемых данных <=32KB, то приложение характеризуется как Throughput oriented
- Если размер блоков данных >=64KB, то приложение можно описать как Bandwidth oriented
- Значения от 32KB до 64KB требуют индивидуального рассмотрения.
3 октября 2009 г.
Queue Length и ABQL
Количество запросов уже стоящих в очереди называется длиной очереди (Queue Length). Она является отличным показателем загруженности оцениваемого объекта (LUN, SP, диска и т. д.). Обычно дисковые массивы предоставляют информацию об усредненном значении этой метрики. Сумма значений Queue Length, полученных в моменты замеров (polling intervals), просто делится на количество этих замеров за время выборки.
При расчете ABQL (Average Busy Queue Length), не учитываются моменты, в которые запросы в очереди отсутствовали. Эта метрика дает нам информацию о стабильности нагрузки. Если ABQL сильно отличается от Queue Length, нагрузка нестабильна и имеет ярко выраженные пики.
Если объем полезных данных в запросах ввода-вывода варьируется в небольших пределах, то верна следующая формула:
В сетях хранения данных (SAN, Storage Area Networks) со значительным разнесением компонент, временем распространения сигналов пренебрегать нельзя, а общее Response Time очень сильно зависит от физической длины канала передачи.
При расчете ABQL (Average Busy Queue Length), не учитываются моменты, в которые запросы в очереди отсутствовали. Эта метрика дает нам информацию о стабильности нагрузки. Если ABQL сильно отличается от Queue Length, нагрузка нестабильна и имеет ярко выраженные пики.
Если объем полезных данных в запросах ввода-вывода варьируется в небольших пределах, то верна следующая формула:
В сетях хранения данных (SAN, Storage Area Networks) со значительным разнесением компонент, временем распространения сигналов пренебрегать нельзя, а общее Response Time очень сильно зависит от физической длины канала передачи.
1 октября 2009 г.
Response и Service Times
По пути своего следования между приложением и жесткими дисками используются различные протоколы и системы кодирования. Поэтому данные проходят большое количество преобразований.
В каждой точке таких преобразований должны формироваться целостные операций ввода-вывода (Input-Output, I/O). Это происходит посредством фрагментации либо агрегирования пакетов с добавлением соответствующей заголовков и вспомогательной информации. Заголовки (headers) чаще всего бывают фиксированного размера. Объем полезных данных (payload) может варьироваться в заранее определенных пределах.
Интервал времени между посылкой запроса на выполнение I/O операции и получением подтверждения ее успешного завершения, называется временем отклика (Response Time). Это наиболее наглядная и понятная метрика. Именно высокое значение Response Time часто является причиной раздражения пользователей систем, ожидающих обновления экрана, выполнения какого-либо скрипта или подтверждения завершения транзакции.
Очень важно понимать и явно указывать контекст использования этого термина в каждом конкретном случае. Ведь время отклика можно замерять на каждом из уровней. Естественно, что Response Time с точки зрения конечного пользователя приложений будет кумулятивно суммироваться из времен отклика всех предыдущих уровней. Т. к. этот документ, прежде всего, посвящен дисковым массивам, то далее я буду ограничиваться только рассмотрением уровней систем хранения данных.
Response Time дисковых накопителей иногда называют латентностью (Latency).
В системах, где инициатор I/O запроса и целевое устройство расположены недалеко друг от друга, временем распространения электрических и оптических сигналов, а также продолжительностью генерации и передачи коротких пакетов, подтверждающих выполнение операции, можно пренебречь. В рамках такого приближения, Response Time является суммой времени ожидания всех запросов, уже стоящих в очереди на обслуживание (Wait Time), и, собственно, продолжительности обработки требуемых данных (Service Time).
В каждой точке таких преобразований должны формироваться целостные операций ввода-вывода (Input-Output, I/O). Это происходит посредством фрагментации либо агрегирования пакетов с добавлением соответствующей заголовков и вспомогательной информации. Заголовки (headers) чаще всего бывают фиксированного размера. Объем полезных данных (payload) может варьироваться в заранее определенных пределах.
Интервал времени между посылкой запроса на выполнение I/O операции и получением подтверждения ее успешного завершения, называется временем отклика (Response Time). Это наиболее наглядная и понятная метрика. Именно высокое значение Response Time часто является причиной раздражения пользователей систем, ожидающих обновления экрана, выполнения какого-либо скрипта или подтверждения завершения транзакции.
Очень важно понимать и явно указывать контекст использования этого термина в каждом конкретном случае. Ведь время отклика можно замерять на каждом из уровней. Естественно, что Response Time с точки зрения конечного пользователя приложений будет кумулятивно суммироваться из времен отклика всех предыдущих уровней. Т. к. этот документ, прежде всего, посвящен дисковым массивам, то далее я буду ограничиваться только рассмотрением уровней систем хранения данных.
Response Time дисковых накопителей иногда называют латентностью (Latency).
В системах, где инициатор I/O запроса и целевое устройство расположены недалеко друг от друга, временем распространения электрических и оптических сигналов, а также продолжительностью генерации и передачи коротких пакетов, подтверждающих выполнение операции, можно пренебречь. В рамках такого приближения, Response Time является суммой времени ожидания всех запросов, уже стоящих в очереди на обслуживание (Wait Time), и, собственно, продолжительности обработки требуемых данных (Service Time).
Что такое производительность?
Этот пост о терминологии. На эту тему я планирую гундеть регулярно и обстоятельно. Чем и начну сейчас заниматься... ;)
К сожалению, в любых областях деятельности человека существует огромное количество многозначных терминов. В информационных технологиях ситуацию ухудшает неоднозначность транскрипции и вольность перевода на наш “великий и могучий”, а также, зачастую, бездумное использование сленга и “русификации” профессиональных понятий. Поэтому любой предметный разговор о технологиях стоит всегда начинать с терминологических договоренностей. Для исключения неоднозначности, я в своих документах стараюсь использовать термины в оригинальном написании на английском языке, по возможности, приводя наиболее распространенные варианты их перевода. Подход, снимающий большое количество проблем, рекомендую...
Понятие производительности (performance), по сути, является субъективным. Одна и та же система в зависимости от требований может расцениваться как “быстрая” или “очень медленная”. Для практической работы использование таких оценок малоэффективно. Нужны объективные и точные характеристики. Поэтому для описания производительности систем хранения данных используются множество различных метрик. В самом начале разговора стоит дать основные определения и познакомиться фундаментальными понятиями.
Следующий пост о терминах Response и Service Times...
К сожалению, в любых областях деятельности человека существует огромное количество многозначных терминов. В информационных технологиях ситуацию ухудшает неоднозначность транскрипции и вольность перевода на наш “великий и могучий”, а также, зачастую, бездумное использование сленга и “русификации” профессиональных понятий. Поэтому любой предметный разговор о технологиях стоит всегда начинать с терминологических договоренностей. Для исключения неоднозначности, я в своих документах стараюсь использовать термины в оригинальном написании на английском языке, по возможности, приводя наиболее распространенные варианты их перевода. Подход, снимающий большое количество проблем, рекомендую...
Понятие производительности (performance), по сути, является субъективным. Одна и та же система в зависимости от требований может расцениваться как “быстрая” или “очень медленная”. Для практической работы использование таких оценок малоэффективно. Нужны объективные и точные характеристики. Поэтому для описания производительности систем хранения данных используются множество различных метрик. В самом начале разговора стоит дать основные определения и познакомиться фундаментальными понятиями.
Следующий пост о терминах Response и Service Times...
Подписаться на:
Сообщения (Atom)