Мониторинг производительности дисковой подсистемы в Windows Server

Часто встречающийся запрос: у меня есть сервер под управлением Windows Server 2003/2008/2012(R2), стоит задача увеличить производительность дисковой подсистемы в существующем сервере или собрать новый. Конечно, производительности много не бывает, но мы всегда стараемся предложить заказчику необходимый и достаточный вариант.
Для детального анализа всех аспектов производительности желательно использовать xperf и Windows Performance Analyzer из набора Windows Performance Toolkit. WPT сейчас входит в состав ADK и позволяет в числе прочего ответить на другой популярный в наши дни вопрос: "будет ли эффективным SSD кэш и каков его оптимальный размер?"

Правильное применение Windows Performance Analyzer - тема для отдельной статьи. На изучение WPA у вас могут уйти многие часы, так что начать можно с базовых инструментов, так как для начала нам нужно получить ответ на два простых вопроса:

• справляется ли дисковая подсистема с нагрузками?
• если нет, то какие параметры требуют улучшения и насколько именно?

Для этого нам нужно провести мониторинг нагрузки за достаточно продолжительное время. Естественно, нагрузка должна быть максимально приближена к "боевой". Например, если речь идет о некой CRM системе, то собирать статистику нужно за весь рабочий день или за несколько часов пиковой нагрузки, когда с системой интенсивно работает большая часть пользователей.
Использовать можно самый обыкновенный Perfmon. Запускаем:

Создаем новую сборщиков данных:

Create manually, затем выбираем System Performance и добавляем счетчики для объекта Physical Disk:

Нужны данные не по всем дискам вместе (_Total), а раздельно по интересующим томам. Счетчики:

• Avg. Disks Read Queue Length, Avg. Disk Write Queue Length: средняя длина очереди на чтение и запись за интервал измерения. Является вычисляемой, т.е. просто умножается Disk Transfers/sec на Disk sec/Transfer
• Current Disk Queue Length: текущая длина очереди
• Disk Reads/sec, Disk Writes/sec: усредненное (за интервал измерения) количество завершенных запросов на чтение/запись в секунду, т.е. пресловутые IOPS'ы. Сами по себе IOPS'ы мало что значат, т.к. важно не только обработать большое количество запросов в секунду, но и обеспечить максимально быструю обработку каждого отдельного запроса. Читайте ниже про задержки.
• Avg. Disk Bytes/Read, Avg. Disk Bytes/Write: средний размер одной операции ввода-вывода
• Avg. Disk sec/Read, Avg. Disk sec/Write: отображает такой важный показатель, как полную задержку (latency) - сколько времени ушло на выполнение запроса. Высокие задержки — одна из главных причин проблем с производительностью дисковой подсистемы, особенно для OLTP нагрузок. Можно иметь систему, способную обработать десятки тысяч IOPS на случайный доступ блоками 4k, но при задержке в 500мс. Приемлемые значения зависят от решаемой задачи, в большинстве случаев (OLTP, VDI, почта) стоит бить тревогу при росте задержки свыше 15-30мс.

Интервал измерения можно задать в свойствах сборщика, общее время работы — в свойствах группы:

Запускаем сборщик и получаем на выходе лог в двоичном формате (blg файл), который можно изучать в том же perfmon или конвертировать в CSV, например, для использования в Gnuplot.

Зная текущую конфигурацию дисковой подсистемы и счетчики производительности, мы можем более-менее точно запланировать возможные действия. Например, когда в пиках появляется по 10000 IOPS на запись по 4-32К, очередь растет до нескольких десятков и задержка аж до 500-700мс и выше, то можно точно сказать, что имеющейся пары SAS HDD в зеркале тут не хватит и проблему можно решить добавлением дисков, включением write-back кэша, использованием SSD (напрямую или в качестве кэша, в зависимости от конкретной задачи, которая будет определять профиль нагрузки).
Самый быстрый способ - отправить подробную информацию о сервисах, конфигурации и архив с логом специалистам компании True System и получить детальный отчет и несколько вариантов решений.