Маркетинг...

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

Заказчик, которому мельком покажут такую картинку, будет “аргументировано” убежден в неоспоримых преимуществах продуктов производителя A (название я так уж и быть замазал ;) ). Если же внимательно присмотреться к масштабу изображений, то разница (4% если считать “на сколько меньше” и 5%, если” на сколько больше”) становится уже не такой убедительной. А учитывая минимальный объем информации о том, как и в каких условиях, это тестирование производилось, такой разницей можно вообще пренебречь.

И еще, совет от одного бывалого эксперта: “Хотите спрятать реальное состояние дел – активно используйте гистограммы ;) “ .

Уровни драйверов и HBA

Любая HBA имеет физические ограничения на максимальные возможные значения Bandwidth и Throughput.

FC интерфейс HBA	Макс. Bandwidth на порт half duplex	Макс. Throughput на порт
2FGC	180MB/s	~40.000IOPS
4GFC	360MB/s	~150.000IOPS
8GFC	720MB/a	~210.000-500.000IOPS (данные из различных источников)

Для обеспечения высокого уровня Bandwidth необходимо использовать 8GFC HBAs. Не стоит забывать, что при этом они должны быть подключены к соответствующим 8Gbps портам FC коммутаторов.
Некоторые производители предлагают свои проприетарные методы повышения Bandwidth. Например, HBA Brocade, позволяют агрегировать два порта одной карты в единый канал передачи данных (trunk), тем самым практически удваивая суммарную полосу пропускания.

Если максимальные показатели Bandwidth у HBAs различных моделей отличаются друг от друга незначительно, то значения Throughput могут различаться очень заметно. Это связано с архитектурными особенностями адаптеров различных производителей. В одних моделях за буферизацию и обработку пакетов отвечают несколько отдельных модулей программно управляемых микрокодом (firmware). В HBA другого производителя большая часть функций “зашита в железо” специализированных ASIC, что позволяет при обработке данных минимизировать внутренние накладные расходы, тем самым уменьшая задержки передачи и повышая максимальное количество IOPS.

Но даже в рамках модельного ряда одного производителя, следующие поколения HBAs имеют более мощную аппаратную начинку и эффективные внутренние методы передачи данных. Поэтому в уже существующей инфраструктуре SAN на базе 4Gbps FC коммутаторов, модернизация HBA 4GFC на 8GFC все равно позволит увеличить максимальную Throughput. За подробностями отсылаю вас к рекомендациям на сайтах производителей.

Внутренние соединения HBA

Факты из истории виртуальной памяти

С момента появления идеи до признания преимуществ использования виртуальной памяти и ее массового использования прошло достаточно много времени. Вот некоторые исторические факты.

В конце 1947г. в лабораториях Bell Labs команда под руководством Вильяма Шокли представила первый работающий образец биполярного транзистора. Достаточно скоро появились вычислительные комплексы, использующие эту революционную технологию. Историки их называют компьютерами второго поколения. Такие системы в качестве оперативной памяти обычно использовали жутко дорогие устройства на ферритовых сердечниках. Именно тогда была выдвинута мысль о возможности расширения физической области оперативного хранения данных за счет использования более дешевых, но медленных магнитных барабанов.

К сожалению, эта смелая идея не нашла поддержки в тогдашней достаточно консервативной среде. Поэтому первая работающая система с использованием идей виртуализации памяти начала серьезно разрабатываться только в период 1959-1962 гг. в рамках проекта команды из University of Manchester, который назывался Atlas Computer.

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

В мире персональных компьютеров виртуальная память была представлена достаточно недавно, с появлением protected mode процессора Intel x86.

Кстати, в Большом Советском Энциклопедическом Словаре есть следующая статья: “виртуальная память (кажущаяся память ЭВМ) - система запоминающих устройств, организованных таким образом, что программист может рассматривать их как одну большую оперативную память, что существенно упрощает процедуру составления программ для мультипрограммных ЭВМ”. Но, несмотря на авторитетность издания, я все-таки соглашусь с замечанием журналиста Леонида Черняка в одной из статей: “такая память никому не кажется и не мерещится, а функционирует в полном согласии с законами физики” :) .

Виртуальная Память

Уровни приложений описываются здесь

Для логической изоляции процессов друг от друга, расширения адресного пространства и более рационального управления RAM, в большинстве современных операционных систем используется специальная схема адресации, которая называется виртуальной памятью (virtual memory). Совершенно прозрачно для приложений в ее логически непрерывное адресное пространство кроме оперативной памяти можно включать другие физически раздельные области, находящиеся на внешних запоминающих устройствах. Например, специальные разделы или даже файлы на уже используемых файловых системах. Такие области называются разделами или файлами подкачки (swap или paging, в зависимости от операционной системы).

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

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

Better then nothing

17 ноября посетил EMC форум. Достаточно интересным показалось выступление Брайана Галахера (Brian Gallagher), который в EMC является самым большим боссом по Hi-end линейке Symmetrix (вот здесь видюшка с его рассуждениями по поводу FAST). Особенно последокладные ответы на вопросы по поводу развития технологий репликации и дисков SSD. Ну да рассказ не об этом.
Через пару дней, воодушевленный возможностью послушать и пообщаться с человеком, "который знает куда катится мир", посетил внутренние посиделки в центре разработки EMC в Питере, где Брайан общался с народом. В конце беседы коснулись одной очень мощной, но глюкавой внутренней тулзы для анализа статистики Symm. Я пожаловался, что без этого инструмента мне в работе не обойтись, но его применение регулярно вызывает массу негативных эмоций. На это Брайан ответил "You are right, but that's better then nothing"...

Последнее время, когда меня что-то начинает раздражать, сама собой всплывает фраза "but that's better then nothing"...  и правда становится легче...  :)

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

Менеджеры Томов - часть 2 Plaids

Часть 1 об использоании Volume Managers

Если визуально представить себе VM страйпинг LUNs, которые уже сами по себе уже страйпированы (RAID 5, RAID 6, RAID 10), получится клетчатый “узор”, напоминающий шотландку-тартан. Благодаря этому такие конфигурации в литературе часто называются пледами (plaid).

Обычно используется 3 типа plaids:

• High Bandwidth plaid имеет смысл использовать при размерах I/O запросов приложений >= размера RAID stripe на дисковом массиве (размер stripe element * количество дисков данных в RAID). Это необходимо для увеличения производительности записи за счет full-stripe writes (будем обсуждать далее в разделе xxx). В однопоточных приложениях Volume Manager создает отдельные потоки данных на каждую LUN, равномерно распределяя нагрузку сразу по нескольким дискам.

Для повышения полосы пропускания рекомендуется
o    распределять нагрузку между портами различных контроллеров (SP)
o    для каждого активного пути к портам контроллера использовать на сервере выделенную HBA
o    по возможности распределять нагрузку между различными дисковыми массивами
o    настраивать только одну LUN на RAID Group.

• High Throughput plaid имеет жесткое ограничение на VM stripe element = RAID stripe. Основная идея такая же, как и в предыдущем случае – по максиму распределить нагрузку по различным шпинделям. Этот тип plaid можно организовывать как на RAID 5/6, так и на RAID10.

Для повышения пропускной способности рекомендуется
o    распределять нагрузку между портами различных контроллеров (SP)
o    для каждого активного пути к портам контроллера использовать на сервере выделенную HBA
o    настраивать только одну LUN на RAID Group

• Cross-striping plaid используется при random I/O с размерами запросов от приложения <8KB. Для эффективной балансировки random нагрузки применяется “размазывание” сразу нескольких LUNs по максимально возможному количеству дисков. При распределении LUNs по RAID Groups необходимо быть уверенным в том, что эти тома не будут испытывать пиковую нагрузку в одни и те же моменты времени.

Менеджеры томов - часть 1 общие принципы

Основной задачей менеджеров томов (Volume Managers, VM) является расширение возможностей подсистемы управления дисками сервера. В стеке протоколов операционной системы они обычно встраивается между драйверами SCSI и файловой системой. Поэтому верхние уровни ОС воспринимают тома, формируемые Volume Manager, как обычные жесткие диски, напрямую подключенные к серверу. Их можно использовать и в качестве сырых устройств.

Базовым элементом, на котором строится вся конфигурация, является LUN дискового массива. Обращаю ваше внимание, что ни операционная система, ни менеджер томов ничего не знают о способе подключения дискового массива или используемых уровнях RAID. Более того, в документации на Volume Manager могут даваться рекомендации, не совместимые с используемой конфигурацией комплекса хранения данных. Потому решаясь на использование VM, системный администратор должен иметь полную информацию о характеристиках нагрузки приложений и четко осознавать все плюсы и минусы, которые он получит при использовании этого промежуточного ПО. Неграмотное использование Volume Manager может очень сильно ухудшить производительность доступа к ресурсам хранения. В случае сомнений, следует провести дополнительные исследования на тестовых системах.

В базовые операции, поддерживаемые большинством VM, входят:

• разделение (partitioning) LUN на логические тома меньшего размера
• объединение (aggregation) нескольких LUN в тома большего размера
• организация защиты данных посредством RAID
• распределение (distribution) нагрузки между несколькими LUN за счет страйпинга (striping)

Все эти операции поддерживаются любыми современными дисковыми массивами (неинтеллектуальные полки JBOD в данном документе я не рассматриваю). Естественно, что на уровне массива такие действия не потребляют ресурсов сервера и требуют значительно меньших усилий по управлению. В тоже время, возможности распределения нагрузки между несколькими дисковыми массивами, а также их контроллерами, в некоторых случаях позволяют улучшить производительность доступа к данным.

При использовании Volume Manager с дисковыми массивами следует придерживаться следующих достаточно жестких запретов:

• Никогда не использовать VM для организации parity RAIDs (RAID 3, RAID 5 и RAID 6)
• Никогда не использовать VM для страйпинга LUNs из одной и той же RAID Group дискового массива
• Никогда не делать размер VM stripe element меньше LUN stripe дискового массива
• Воздержаться от использования VM для страйпинга LUNs на RAID Groups различных типов RAID, размеров stripe elements или с различным количеством дисков. Устранение неполадок, а также анализ и настройка производительности в таких системах может стать настоящим кошмаром.

Часть 2 о Plaids

Заметки на полях (файловые системы)

• Буферизация файловых систем является одной из причин небольших значений hit on reread.
• Некоторые системы, например, VxFS или AIX, реализуют механизм предшествующего чтения (Read-ahead). Это приводит к увеличению Request Size на чтение.
• В NTFS любые IO больших размеров все равно передаются блоками по 512K.
• Если NTFS переформатирована с экстентами не-default размера, то дефрагментировать ее уже нельзя (добавлено:  гуру утверждают, что давно можно).

Уровень файловых систем

На уровне файловой системы последовательный поток байтов, следующий от приложения, организуется в блоки. Именно здесь определяются нижняя и верхняя границы Request Size.

Минимально возможный Request Size задается размером блока файловой системы. Правда, в некоторых системах метаданные могут записываться порциями меньшими, чем размер блока, но их общий объем не велик и обычно не влияет на характер I/O. Размер блока зависит от типа и параметров файловой системы. Он обычно задается одним из трех способов:

• Фиксированный размер, по умолчанию или заданный явно при создании файловой системы. Например, default block size в Solaris UFS = 8K.
• Фиксированный размер, определяемый по величине создаваемой файловой системы (file system size). Так в NTFS при размерах тома 513MB - 1,024GB block size = 1KB, при 1,025GB – 2GB block size = 2KB, а при 2 – 4GB block size = 4KB.

Многие файловые системы поддерживают оба способа, например, при создании ext2 можно либо явно задать размер блока 1KB, 2KB или 4KB (mke2fs –b), либо позволить утилите mk2fs самой определить требуемый block size, исходя из величины файловой системы (по умолчанию).

• Размер, динамически изменяемый в процессе записи данных на файловую систему. Например, ZFS в зависимости от текущих параметров ввода-вывода позволяет записывать данные блоками различных размеров (до 128KB).

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

Несколько последовательных блоков в буфере могут быть объединены в единый запрос. Каждая файловая система имеет параметр, определяющий, какое максимальное количество блоков может быть объединено. Зная этот параметр, мы можем легко вычислить максимальный размер запроса к дисковому массиву. Например, если файловая система позволяет объединять не более 128 блоков размером 8KB, то максимальный размер Request Size равен 1MB (128 * 8KB).

Во вновь созданной файловой системе блоки данных файлов имеют последовательно идущие LBA. Фрагментация файловой системы приводит к тому, что даже если с точки зрения приложений операции чтения и записи производятся последовательно, то на уровне файловой системы они все равно не могут эффективно объединяться в большие запросы. Таким образом, sequential операции превращаются в random, что увеличивает накладные расходы на их обработку и очень заметно сказывается на общей производительности. Поэтому, если файловая система предполагает наличие значительного количества последовательных запросов (например, резервное копирование данных), необходимо регулярно проводить ее дефрагментацию.

Базы данных обычно имеют свою собственную буферизацию. Для того чтобы избежать неэффективного использования ресурсов за счет двойной буферизации, в некоторых случаях резонно не использовать дополнительную прослойку файловой системы, а передавать данные напрямую на сырые устройства (raw devices).

Raw devices не имеют ограничений на размер блока и поэтому позволяют варьировать размеры Request Size в более широком диапазоне. В силу своей организации они также не подвержены фрагментации на уровне блоков.
В тоже время, использование сырых устройств усложняет управление, а также резервное копирование и восстановление данных. В современных системах с большим объемом оперативной памяти, файловые системы часто показывают более высокое быстродействие, чем сырые устройства.

По бразильской системе...

Из Книги Кэри Миллсапа и Джеффа Хольта “Oracle оптимизация производительности”

"Гэри Гудман, рассказывал о проектах внедрения приложений, которыми он руководил во время работы в Oracle Corporation. Один из приемов, практикуемых им в процессе внедрения, состоял в отключении всех прикладных отчетов в системе. Когда пользователи приходили с просьбой о недостающем отчете, специалисты подключали его обратно. По опыту Гэри, ни разу не пришлось подключить больше 80% отчетов, первоначально имевшихся в системе."

Другие замечательные цитаты из книги здесь и здесь

Заметки на полях (базы данных)

Скорее не полноценный пост, а памятка самому себе...

• Стоит всегда стараться изолировать log-файлы от данных СУБД на отдельном RAID10.
• Если Response Time файлов данных СУБД <6ms – отлично, 6-20ms – приемлемо, >20ms – плохо.
• Если Response Time log-файлов СУБД <2ms – отлично, 2-6ms – приемлемо, 6-15ms – скоро начнутся проблемы, >15ms – проблемы уже начались.

Уровень приложений

Существует великое множество разнообразных комбинаций приложений и способов их использования. Казалось бы, это ведет к бесконечному количеству различных типов ввода-вывода. Соглашусь с этим только отчасти. Конечно, детально рассматривая производительность дискового массива, мы увидим совершенно уникальное сочетание значений метрик. Но, в тоже время, по неким общим чертам и схожестям характеристик, можно выделить общие I/O паттерны приложений.

Обычно приложения группируются на основе следующих характеристик нагрузки:

• особенностей доступа к данным логических томов – выборки информации последовательным (sequential) или произвольным (random) образом.
• соотношения количества запросов на чтение (read) и запись (write)
• среднего размера блоков данных (Request Size)
• стабильности (steady) или наличия пиков (bursty)

При sequential доступе обрабатываются блоки данных, логические адреса (logical block address, LBA) которых расположены близко друг к другу и могут составлять последовательную цепочку (например, блоки 105, 106, 107, 108 или 23, 27, 25, 24, 26). Напротив, при random доступе адресуются LBA, которые не являются смежными и произвольным образом разбросаны по адресному пространству LUN. Конечно, эти определения являются достаточно общими и не описывают степень случайности или локализации требуемых данных, но для качественного описания I/O паттернов вполне годятся.

В таблице приведены характеристики для наиболее распространенных типов приложений.

Приложение	Тип доступа	Request Size	Интенсивность записи	Стабильность нагрузки
MS Exchange	Очень произвольный	4KB	Относительно высокая	Пики
MS Exchange Backup	Произвольный	64KB	Очень низкая	Стабильна
SAP/Oracle	Очень произвольный	4KB	Зависит от приложения	Пики
СУБД файлы данных/ OLTP	Очень произвольный	Page size	Относительно высокая	Пики
СУБД файлы данных/ DSS	Частично последовательный	64KB - 1MB	Низкая	Стабильна
СУБД online (transaction) logs	Последовательный	512bytes+	Высокая (за исключением archiving)	Пики
СУБД temp space	Произвольный	Page size	Очень высокая	Пики
Потоковое мультимедиа	Частично произвольный	64KB - 128KB	Низкая	Пики
Потоковое видео	Последовательный	64KB+	Высокая	Стабильна

Более детальная информация об основных типах I/O содержит данные о значениях Random Read Hit (RRH), Random Read Miss (RRM), Sequential Read (SR) и Writes (WRT). Надеюсь, позднее я уделю этим характеристикам отдельное внимание.

Средние значения Request Size для операций чтения и записи показаны на следующем графике. Хочу обратить внимание, на то, что реальные показатели Request Size будут колебаться вокруг этих усредненных значений.

Уровни обработки и хранения данных

В рамках классической модели хранении и обработки данных, информация перемещаются между различными уровнями (layers) технологического стека, выступающими в роли потребителей ресурсов и поставщиков услуг. Часто рассматривается упрощенный стек, который формируется из 9 основных уровней.

Реальный опыт показывает, что наиболее эффективным направлением анализа производительности комплекса является сверху вниз. Чаще всего, максимальный эффект дает оптимизация верхних уровней. Ведь именно они формируют все запросы, которые в дальнейшем обрабатываются остальными подсистемами. Зачастую, добавление дополнительных индексов таблиц, использование более эффективного алгоритма сортировки или изменение размера буферов и Shared Memory дают просто ошеломляющий прирост производительности. К сожалению, многие организации не имеют возможности, а подчас, и просто не заинтересованы в оптимизации приложений и баз данных.

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

Немного особняком стоит уровень инфраструктуры сети хранения данных. Как я уже говорил, его влияние на общую производительность при передаче данных на небольшие расстояния (до 100км.) обычно не велико, т. к. вносимые задержки обычно не превышают нескольких десятков µs. В тоже время при значительном удалении устройств комплекса друг от друга, скорость распространения данных в сетях FC и IP SAN становится одним из основных факторов, ограничивающих производительность. В том и в другом случаях, при проектировании сетей хранения стоит учитывать требования к доступности данных.

Уровень приложений обсуждается здесь. Уровень файловых систем здесь. менеджеры томов здесь и здесь. Виртуальная память здесь. Уровни драйверов и HBA здесь. инфраструктура SAN здесь, здесь и здесь.

Теория Массового Обслуживания

В предыдущих постах мы обсуждали зависимости, которые были получены экспериментальным путем. К слову сказать, существует и теоретическая база для всего этого наукообразия. Она называется Теория Массового Обслуживания (Queuing Theory). Первые задачи данной теории были рассмотрены сотрудником Копенгагенской телефонной компании Агнером Эрлангом (Agner Krarup Erlang 1878-1929) еще в начале прошлого века. Этот в высшей степени выдающейся человек решил задачу упорядочивания работы телефонной станции, рассчитав параметры качества обслуживания потребителей в зависимости от количества используемых устройств.
В наше время Теория Массового Обслуживания активно используется для решения широкого спектра задач. С ее помощью можно достаточно точно оценить необходимое количество кассиров, требуемых в разное время для обслуживания посетителей супермаркета, или требования к производительности работы международного аэропорта.

Как и любая другая математическая теория, Queuing Theory требует основательного знания математики. Я не буду утомлять себя и читателя выкладками серьезных формул. Для тех, кто хочет глубоко в этом разобраться существуют многочисленные специализированные книги и статьи. Да и с прикладной точки зрения необходимости в этом нет. На широких просторах сети не сложно найти уже готовые таблицы Excel, которые очень удобно использовать для простых оценок. Расчеты и графики из этого поста можно взять здесь.

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

Одним из очень упрощенных следствий модели является следующая формула:

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

Интересны еще несколько зависимостей, следующих из модели M/M/m. При постоянном Service Time увеличение количества каналов обслуживания очереди (m) ведет к “сдвигу” точки перегиба в право. Это означает, например, что увеличение пунктов досмотра багажа пассажиров, стоящих в единой очереди терминала аэропорта, при возрастании общего пассажиропотока позволит заметно увеличить эффективную утилизацию этих пунктов.

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

А вот уменьшение самого Service Time системы всего лишь сжимает график, тем самым сокращая общий Response Time, но не изменяя точки перегиба. Т. е. рост производительности пунктов досмотра багажа из предыдущего примера, конечно, в какой-то мере уменьшит общее время прохождения досмотра, но не позволит заметно повысить их утилизацию.

Внимательный читатель скажет: “А ведь я уже видел такие сдвиги и растяжения графиков", и будет прав. Посмею сделать утверждение, доказательство которого оставлю на совести гуру Теории Массового Обслуживания. Добавление кэша или количества дисковых накопителей в определенных случаях можно промоделировать при помощи увеличения количества каналов обслуживания. А уменьшение Request Size опосредованно ведет к снижению Service Time и также, с некоторыми оговорками, вписывается в рамки модели M/M/m.

Для желающих подробнее познакомиться с Теорией Массового Обслуживания предлагаю несложную задачку с решением.
Администрация вокзала решила внедрить новую систему обслуживания пассажиров и установить автоматические кассы-терминалы по продаже билетов. Количество пассажиров, встающих в очередь, - в среднем 3 чел./мин. Максимальное время, которое пассажир готов стоять в очереди, а не дождавшись поехать без билета - 5 мин. Рассматривается вопрос о приобретении 4 касс. На выбор есть кассы с производительностью обслуживания 1 чел./мин. и 1,3 чел/мин..
Необходимо выбрать наиболее оптимальный из двух вариантов, который поможет сократить количество тех, кто не дождался своей очереди и поехал без билета. Вариант I - организовать в каждую кассу отдельную очередь. Вариант II - организовать единую очередь ко всем кассам. Причем, во втором варианте для интереса мы будем учитывать использование более производительных касс. Решение задачки можно проанализировать все в той же таблице.

Даже несмотря на то, что в варианте II предполагается использование более производительных касс, вариант I все же будет лучше. Интересно отметить, что если количество пассажиров, встающих в очередь, уменьшится до 0,5 или увеличится до 4, более предпочтительным станет второй вариант (см. график). Вот такие интуитивно-непонятные выводы... :)

Обратная связь

Давайте немного поговорим о сложных процессах взаимного влияния инициатора нагрузки и поставщика сервисов хранения. С точки зрения сервера существует понятная зависимость между Response Time, ожидаемым приложением, и требуемой для этого Throughput. Есть даже емкий английский термин для такой формы зависимости – anticipating demands. Что бы записать или получить данные с дискового массива за меньшее время, серверу необходимо просто увеличить количество соответствующих запросов, т. е. повысить Throughput.
Хочу обратить ваше внимание, что этой зависимостью управляет именно ожидание сервера, т. е. ось ординат Response Time на графике anticipating demands.

Что же в это время происходит на дисковом массиве? Предположим, что он имеет достаточное количество свободных ресурсов для того, чтобы выполнить I/O операций в рамках ожидаемого Response Time. Более того, у него есть дополнительные невостребованные мощности и поэтому массив обработает запросы с Throughput, которая даже больше требуемой. Хранилище просто “проглотит” данные быстрее, чем того ожидает сервер. В таком случае, приложение имеет возможность уменьшить Response Time, ужесточив требования к Throughput. Увеличение пропускной способности может (но, конечно, не обязательно) происходить до тех пор, пока требования сервера не подойдут к пределу возможностей дискового массива, т. е. до пересечения их кривых.

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

Таким образом, происходит взаимное давление с обеих сторон взаимодействия. Этот механизм обратной связи приводит к адаптивной регуляции нагрузки.
“Если все так самоорганизуется, то откуда же тогда берутся проблемы с производительностью?”, спросит пытливый читатель. Все дело в требованиях конечных пользователей приложений. Если результирующее Response Time дискового массива будет высоким, то это приведет к увеличению времени отклика приложений. Его несоответствие формальным требованиям или даже просто субъективным ожиданиям потребителей, будет являться поводом для оптимизации использования ресурсов или модернизации не справляющегося со своей работой оборудования.

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

Модернизация оборудования

Нравится мне книжка Кэри Миллсапа и Джеффа Хольта “Oracle оптимизация производительности”. В Oracle я не силен, зато подходы к анализу производительности там очень правильные и стиль изложения простой...  Вот еще одна цитата:
“ Модернизация оборудования - последняя из возможностей, которую следует рассматривать при повышении производительности. Последнее место она занимает по вполне очевидным причинам:
• Дорогостоящая модернизация оборудования редко способна дать тот же эффект, что и недорогие мероприятия по исключению бесполезной нагрузки.
• Плохо спланированная модернизация оборудования может в действительности ухудшить производительность пользовательской операции, которую вы пытаетесь ускорить.


Многие руководители считают модернизацию беспроигрышным вложением, считая, что “Разве может быть слишком много процессоров (памяти, дисков и т. д.)?”. Расхожее мнение гласит, что даже если модернизация напрямую не решит имеющуюся проблему производительности, то как она сможет навредить? Ведь дополнительные мощности, так или иначе, будут использованы, разве нет? Увы, не всегда. Далеко не все осознают риск, связанный с принятием такого решения.
…
Более близкое знакомство с законом Амдала помогло мне понять, что любая модернизация может привести к снижению производительности какой-либо пользовательской операции вследствие возникновения конкуренции за ресурс, который не был модернизирован. Вопрос только в том, заметит ли кто-нибудь эти ухудшения”.

Базовые зависимости

Изменение характеристик потока ввода-вывода либо параметров 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 можно хотя бы частично компенсировать за счет расположения данных на большем количестве шпинделей.

Теорема Литтла (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чел/мин.).

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).

Опять о терминологии

К сожалению, в различной англоязычной литературе нет единодушия по поводу использования терминов Bandwidth и Throughput. Даже в документах на смежные темы Throughput может употребляться как в качестве пропускной способности, так и полосы пропускания.
В статьях на русском языке горячо любимая “пропускная способность” вообще зачастую употребляется как синоним “производительности”. А универсальный термин “скорость передачи” может заменять собой Bandwidth, Throughput или Transfer Rate.

В таком терминологическом беспорядке при чтении литература нас могут выручить только знание предметной области и понимание контекста употребления. Например, можно догадаться, о чем идет речь при описании “Transaction and Throughput-oriented applications”, или “анализе пропускной способности резервного копирования” ;) .

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

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 показан в таблице:.

Тип 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 требуют индивидуального рассмотрения.