Я студент из университета Фонтис в Эйндховене, и в настоящее время я провожу серию интервью, чтобы помочь с разработкой инструмента SQL Server, и я хотел бы получить отзывы от экспертов в этой области.
Один из моих вопросов:
Какие счетчики производительности можно посмотреть в экземпляре SQL Server, чтобы определить его производительность и общее состояние?
Особенно меня интересуют пороговые значения, когда хорошее становится плохим.
Джамиль Янг Эйндховен Нидерланды
Ответы:
Вот мой учебник Perfmon для SQL Server: http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/
Для большего количества счетчиков и порогов, вот плакат, который мы сделали, когда я был в Квесте: http://www.quest.com/documents/landing.aspx?id=11635
Это большая тема с большим количеством материала, доступного с пятном Googling. В качестве отправной точки, это те счетчики, на которые я склонен смотреть сначала:
Процессор -% процессорного времени
Система - длина очереди процессора
Скорее всего, вы получите различное целевое значение для загрузки ЦП от каждого запрашиваемого администратора БД. Лицензии на SQL Server стоят дорого, поэтому, с одной стороны, вы хотите максимально использовать процессоры, а с другой - не ставить под угрозу доступность. В идеальном мире с хорошо понятыми рабочими нагрузками вы можете нацеливаться на 70% использования, предупреждать на 80-90%, предупреждать на 90% +. Вернувшись в реальный мир с пиковой и минимальной рабочей нагрузкой, вам может быть удобнее ориентироваться в среднем на 50-60%.
Память - Доступные МБайт
Файл подкачки -% использования
В случае выделенного сервера SQL Server, в зависимости от установленной оперативной памяти, менее 100-200 МБ доступной памяти может указывать на истощение и риск подкачки ОС. В общем, мы не хотим видеть большую активность файла подкачки, поэтому я буду исследовать, было ли% Usage больше 2%, и беспокоиться, если оно достигнет 5%.
Buffer Manager - Коэффициент попадания в буферный кеш
Buffer Manager - ожидаемая продолжительность жизни страницы
Оба этих счетчика лучше рассматривать против установленной базовой линии для сервера. В идеале мы хотели бы, чтобы коэффициент попадания в кэш был как можно ближе к 100%, а PLE работал до тысяч секунд. Обратите внимание, когда они отклоняются от исторических средних.
Статистика SQL - Пакетные запросы / сек
Статистика SQL - Компиляции / сек
Статистика SQL - Перекомпиляции / сек
Количество запросов / сек - отличная мера относительной загруженности сервера. Высокие значения компиляции / перекомпиляции могут указывать на то, что циклы ЦП теряются при компиляции запроса.
Физический диск - ср. Диск с / Чтение
Физический диск - ср. Disk sec / Write
Физический диск - чтение диска / сек
Физический диск - запись на диск / сек
Грубая рекомендация для правильно сконфигурированной системы ввода-вывода составляет <5 мс (в идеале 1 мс) для дисков журналов, <20 мс (в идеале <10 мс) для данных. Число операций чтения / записи в секунду следует рассматривать в сравнении с известным пределом для накопителя (ей), т. Е. Если у вас емкость 1000 IOPS, я буду оценивать параметры обновления, когда среднее значение IOPS достигнет 750.