Что такое базовые счетчики perfmon для мониторинга SQL Server и что они означают?
Вот счетчики, которые я отслеживаю, и почему (см. Кнопку объяснения в perfmon для подробного объяснения того, что они делают). Обратите внимание, что многие из этих счетчиков бесполезны, если у вас нет базового показателя для измерения. Вы должны контролировать приложения, прежде чем у них возникнут проблемы с производительностью.
Объект процесса:% загруженности процессора - если у вас есть рост, а этот счетчик в среднем составляет 80%, пора обновить. 75-80% в среднем - это полностью загруженный сервер. Постоянные всплески, особенно при низком уровне пользовательских подключений, могут означать, что запрос плохо написан или может означать, что пришло время для обновления, безусловно, лучше, чтобы кто-то взглянул на код.
Системный объект: длина очереди процессора - это значение должно быть меньше двукратного количества процессоров в системе. Если он растет, а процент ЦП (выше) составляет 80% +, то вам, вероятно, потребуется больше или более быстрые процессоры.
Объект памяти: Страниц / сек. Как правило, добавление памяти (или выделение большего объема для SQL) должно снизить этот счетчик. Этот счетчик сам по себе НЕ указывает на проблему с производительностью. Этот счетчик субъективен. Что говорит о том, что если со временем это возрастет, а производительность снизится, определенно пора выделить больше оперативной памяти для sql-сервера. Как правило, при условии, что sql server - единственное приложение в коробке, это число должно в среднем 0 за 24-часовой период (с пиками). Ниже 20 не стоит особо замечать с точки зрения производительности, выше 20 и вам, вероятно, понадобится больше оперативной памяти.
Объект памяти: доступные мегабайты - ищите постоянство во времени - не магическое число, теоретически идеальный мир это будет как можно ближе к 0
Объект PhysicalDisk: Сред. Disk Queue Length - хорошее эмпирическое правило: не больше, чем количество шпинделей X 2, это число субъективно
Объект PhysicalDisk:% времени простоя - используйте это - 100, чтобы получить более точное представление о% времени на диске (это мое старое примечание, в версиях 2008 года это могло быть исправлено, но были некоторые проблемы с 2000 и 2003). вы настраивали, вы хотели бы знать соотношение чтения и записи - это просто базовая производительность
Объект сетевого интерфейса: всего байтов / сек - здесь вы ищите проблемы с сетью. если он ненормально низкий (скажем, в диапазоне 20%) и у вас приличная нагрузка, взгляните на конфигурацию сети; аналогично, если она превышает 60%, у вас может быть неправильная конфигурация или узкое место в сети. 60% должно быть около 3000 пакетных запросов в секунду.
Объект методов доступа к SQL Server: полное сканирование в секунду - если вы видите, что многие из этих индексов SQL-сервера не используются, найдите разработчика sql и принесите летучую мышь (используйте дерево, поскольку алюминиевые имеют тенденцию к вмятинам), обратите внимание, что это относительное к базовому уровню, так как не все запросы могут использовать индекс, но, безусловно, стоит попросить разработчика взглянуть, есть ли какое-либо дополнительное индексирование, которое может быть выполнено
Объект базы данных SQL Server: транзакций / сек - используйте это, чтобы указать среднюю загрузку сервера, это будет иметь тенденцию к снижению производительности (обратите внимание, что SQLServer: SQL Statistics: Batch Requests / Sec более точен, как бы я ни обнаружил, что TPS полезнее)
Объект диспетчера буферов SQL Server: коэффициент попадания в буферный кэш - как вы могли догадаться, чем больше, тем лучше, и большее количество оперативной памяти должно (но не обязательно) увеличивать это значение.
Объект общей статистики SQL Server: подключения пользователей - используется больше для отслеживания тенденций, чем для фактической производительности, приложения на основе Java часто нагнетают это значение до 1000 из-за способа подключения к серверу sql.
SQL Server блокирует объект: среднее время ожидания - опять же субъективно, с течением времени, чтобы указать тенденции / проблемы производительности, однако это также отлично подходит для отдельных проблем (например, почему этот отчет работает так медленно), если эти всплески заставят разработчика взглянуть на код за тот конкретный отчет. Это может просто создать много замков, или его, возможно, придется настроить (так что на этот раз оставьте биту на своем столе)