Описание проблемы
Известны несколько статей об обнаружении проблем ввода-вывода, связанных с SQL Server. Существуют разные методы поиска "узких мест" ввода-вывода, мы же сконцентрируемся тут на вопросе: Какие счётчики производительности необходимы для того, чтобы быстро понять, являются ли диски "узким местом"?
Решение
В сети можно найти много разной информации о том, как определить возможные узкие места ввода-вывода. Доступная информация настолько обширна, что в ней легко потеряться. Быстро определить является ли узким местом дисковая подсистема достаточно трудная задача, решение которой главным образом зависит от типа хранилища, которое может быть: DAS, SAN, NAS, iSCISI, виртуальный диск и т.п. В большинстве организаций диски доступные для SQL Server - это "чёрный ящик", что делает задачу определения реального размещения данных достаточно тяжёлой.
Во время конференции PASS Summit 2010 года на встрече SQL Clinic автор общался с экспертами в области анализа загрузки дисков на тему того, как быстро идентифицировать возможные проблемы с дисками. В конце беседы Premier Field Engineer представил очень простой, но эффективный набор счётчиков производительности для такого анализа.
Основная идея сводится к тому, чтобы использовать такие счётчики производительности, которые не нуждаются в дополнительной информации, требующей интерпретации. Есть несколько подходящих счётчиков, но только некоторые из них позволяют измерить абсолютные величины в том смысле, что они не нуждаются в дополнительных измерениях показаний других счётчиков или интерпретации полученной информации.
Таким образом, можно выделить два основных счётчика, которые можно использовать для того, чтобы быстро проанализировать работу дисков:
Avg. Disk sec/Read - показывает среднее время в секундах, потраченное на чтение данных с диска.
Avg. Disk sec/Write - показывает среднее время в секундах, потраченное на запись данных на диск.
Используя эти счётчики при исследовании загрузки нескольких дисков, можно выяснить то, как обстоят дела с каждым отдельным диском, таким образом, можно понять, является ли узким местом какой-либо из исследуемых дисков.
Подобно правилу буравчика, если мы имеем дело с OLTP системой, среднее значение должно быть меньше 15 ms со всплесками до 25 ms. Если у вас эти значения ниже указанного порога, тогда ваш ввод-вывод не испытывает затруднений, и никакой дополнительный анализ узких мест дисков больше не потребуется. Это эмпирическое правило может использоваться для любого типа системы. Чем меньше времени требуется для чтения или записи данных, тем быстрее будет ваша система.
Картинка ниже показывает Avg. Disk sec/Read для диска C:. Можно видеть, что среднее значение порядка 0.130, что составляет 130 ms, и максимальное значение 1.089, что составляет 1089 ms. Таким образом, у исследуемой системы ввод-вывод является узким местом, что видно из полученных значений счётчиков. Если бы интерпретировалось значение Avg. Disk sec/Write, оно привело бы к аналогичным выводам.
Если значения представленных выше счётчиков превышают указанные оптимальные пороговые значения, придётся заняться более глубоким анализом, измерив для этого данные следующих счётчиков производительности:
Disk Transfers/sec - демонстрирует нагрузку операций чтения и записи на диск.
Disk Reads/sec - нагрузка операций чтения с диска.
Disk Writes/sec - нагрузка операций записи на диск.
Avg. Disk Queue Length - показывает среднее значение числа запросов чтения и записи, которые стояли в очереди к выбранному диску во время интервала измерений.
Current Disk Queue Length - показывает число запросов, адресованных выбранному диску в то время, когда непосредственно выполнялись измерения.
Заключение
Целью этой статьи была рекомендация счётчиков производительности, которые годятся для экспресс-анализа того, является ли дисковая подсистема узким местом в работе компьютера. Если вы наблюдаете превышающие пороговые значения этих счётчиков, понадобится потратить дополнительное время на то, чтобы "раскопать" источник проблемы.
По материалам статьи Маттео Лорини (Matteo Lorini): "Perfmon Counters to Identify SQL Server Disk Bottlenecks".