Я студент університету Fontys в Ейндховені, і в даний час я провожу низку інтерв'ю, щоб допомогти у розробці інструменту 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. Як вихідний, це лічильники, на які я схильний розглядати спочатку:
Процесор -% часу процесора
Система - Довжина черги процесора
Ви, ймовірно, отримаєте інше цільове значення для використання процесора від кожного запиту DBA. Ліцензії на SQL Server є дорогими, тому, з одного боку, ви хочете максимально використовувати процесори, а з іншого боку, ви не хочете погіршувати доступність. В ідеальному світі з добре зрозумілими робочими навантаженнями ви можете орієнтуватися на 70% використання, попередити 80-90%, насторожити 90% +. Повернувшись до реального світу з навантаженням, що досягає піків і корит, вам може бути зручніше орієнтуватися на 50-60% середнього.
Пам'ять - наявні Мбайт
Файл підкачки -% використання
З виділеним SQL-сервером, залежно від встановленої оперативної пам’яті, менше 100-200 Мб доступної пам’яті може вказувати на голодування та ризик підключення до ОС. Взагалі ми не хочемо бачити активність файлів на сторінці, тому я би розслідував, чи не більше% використання, і стурбовано, чи не вдалося досягти 5%
Buffer Manager - коефіцієнт хітів буферного кешу
Buffer Manager - тривалість життя сторінки
Обидва ці лічильники краще розглядати щодо встановленої базової лінії для сервера. В ідеалі, ми хотіли б, щоб коефіцієнт показів кешу був максимально наближеним до 100%, а PLE працював у тисячах секунд. Зверніть увагу, коли вони відхиляються від середніх історичних показників.
Статистика SQL - Пакетні запити / сек
Статистика SQL - Компіляції / сек
Статистика SQL - Рекомпіляції / сек
Запити / сек - чудова відносна міра для того, наскільки "зайнятий" сервер. Високі значення компіляції / перекомпіляції можуть свідчити про те, що цикли процесора витрачаються на компіляцію запитів.
Фізичний диск - Сер. Диск сек / Прочитайте
Фізичний диск - Сер. Диск сек / Пишіть
Фізичний диск - Читання диска / сек
Фізичний диск - Запис диска / сек
Приблизним орієнтиром для правильно налаштованої системи вводу-виводу є <5 мс (в ідеалі 1 мс) для журнальних приводів, <20 мс (в ідеалі <10 мс) для даних. Читання / запис в секунду слід враховувати, як відомо, обмеження для накопичувачів, тобто, якщо у вас є ємність для 1000 IOPS, я б оцінював варіанти оновлення, коли середній показник IOPS досяг 750.