Моніторинг SQL Server, Інші СУБД, Бази даних, статті

Більше ніяких авралів – просто систематичне спостереження


Яке питання найменше хотілося б отримати адміністратору баз даних? Ймовірно, повідомлення від користувача про погіршення роботи програми або питання про те, що сталося з базою даних. Доводиться відкладати всі справи і переходити в «аварійний режим», гадаючи, чи надовго це. Так як однієї з основних обов’язків адміністратора баз даних є забезпечення якісного функціонування промислових баз даних, залишається тільки максимально швидко усунути несправність. Часу на з’ясування причини збою, як правило, немає.


Але хіба це єдине, що можна зробити? Існує можливість проводити попереджуючий моніторинг продуктивності, просту процедуру управління, яка використовує визначення базових параметрів роботи системи, отримання еталонів і безперервне спостереження. У цій статті я розповім про те, як застосовувати попереджуючий моніторинг і як створити безкоштовну контрольну систему з використанням Windows System Monitor.


Попереджуючий моніторинг


Попереджуючий моніторинг продуктивності – це нескладна система, яка дозволяє вирішити проблеми до того, як вони стануть критичними. Хтось, імовірно, вже використовує спостереження за винятковими ситуаціями, коли створюються автоматизовані процеси, які помічають тільки відхилення від норми, але не забезпечують глибинної інформацією і не надають можливості запобігти проблеми. Попереджуючий моніторинг продуктивності, навпаки, забезпечує користувача всілякої інформацією про робочий оточенні і додатках, і короткострокової, і довгострокової. Знімаються показання лічильників характеристик бази даних, встановлюються еталонні метрики і підтримується активний режим спостереження.


Як припускає назву, попереджуючий моніторинг продуктивності вимагає дій. Потрібно затратити трохи часу на установку і деякий час на осмислення функціонування баз даних і додатків. Щоб попереджуючий моніторинг продуктивності був ефективним, необхідно переглядати повідомлення, так що є можливість використовувати великі зібрані дані.


Базові параметри, еталон, монітор


Давайте почнемо з визначення декількох термінів. Базові параметри (baseline) – це набір параметрів, що відображають поведінку сервера і програми в звичайних умовах. Базові параметри отримані як середні за результатами декількох вимірів, виконаних в однакових умовах, вони є орієнтирами для порівняння.


Еталон (Benchmark) показує продуктивність системи при певному рівні завантаження сервера, що дозволяє порівняти продуктивність промислового сервера при такому рівні і визначити показники сервера, наскільки вони вище або нижче норми (тобто коли сервер працює погано). Як і у базових параметрів, значення еталонів знімаються в контрольованому оточенні, ключові значення визначаються щодо зумовлених показників. Якщо потрібно подивитися, як поводиться сервер і додаток на декількох рівнях або типах завантаження, то зазвичай отримують кілька еталонних значень (по відношенню до базових параметрами)


Моніторинг (Monitoring) – це планове спостереження в режимі реального часу за сервером на зумовлених умовах (сукупностях умов, визначених для подальшого дослідження або попереджень). Наприклад, якщо буде потрібно дізнатися, скільки часу займає вдале виконання важливого бізнес-додатки, скільки часу займає резервне копіювання або коли певні значення продуктивності будуть досягнуті, то за цими конкретними подіями ведеться спостереження.


Тепер займемося випереджувальним моніторингом. Можна використовувати продукти третіх фірм або безкоштовне рішення, яке задіює System Monitor. Рішення третіх фірм можуть спростити процес налагодження попереджувального моніторингу та мати функції, відмінні від тих, які може забезпечити безкоштовне вбудоване рішення. Але перш ніж почати, я покажу, як приступити до виконання попереджувального моніторингу за допомогою System Monitor.


Крок 1: Визначити базові параметри продуктивності


На першому кроці забезпечення режиму попереджувального моніторингу встановлюється сукупність основних параметрів роботи сервера бази даних. Ця сукупність вказує на продуктивність сервера в нормальних умовах, допомагає документувати і зрозуміти всі значущі фонові процеси, також допомагає визначити ситуації, “не вимагають втручання”, щоб надалі не звертати на них уваги. Іншими словами, адміністратори баз даних можуть визначити варіанти ігнорування повідомлень системи, тому що інакше формується велика кількість помилкових повідомлень.


Для того щоб наочно показати якість функціонування, кращі базові параметри використовують трохи графіків (в ідеалі один), щоб з першого погляду можна було побачити, як працює сервер. Коли будуть визначені базові параметри, потрібно зробити наступне. По-перше, виберіть варіант для збереження даних по продуктивності в системному журналі або їх відображення в реальному часі. Ідеально мати обидві можливості: журнали реєстрації дозволяють повернутися до показань в будь-який момент часу, щоб проаналізувати, якою була продуктивність, коли безпосереднє спостереження за системою не велося. Моніторинг в реальному часі не займає робочий простір на диску і ресурси сервера, але вимагає приділити системі 100 відсотків уваги. По-друге, потрібно визначити інтервал, через який буде вестися спостереження, враховуючи витрати в продуктивності для збору даних і операції введення-виведення даних і оцінити витрати на необхідну простір. Чим більше інтервал, тим вище ймовірність, що цікавлять дані по продуктивності не будуть отримані. І, нарешті, виберіть локальний або дистанційний моніторинг. Локальний моніторинг, при якому процес спостереження використовує контрольований сервер, додає непродуктивні витрати на процесор і диск сервера. Дистанційний моніторинг, який використовує окремий сервер, може позбавити від подібних проблем, однак це сильно збільшує робоче навантаження на мережу.


В Таблиці 1 перераховані метрики System Monitor або лічильники, які рекомендується використовувати для визначення базових параметрів. Я не можу сказати, яке значення “правильне” в контексті окремо взятого додатки, так як воно змінюється від системи до системи. Використовуйте середнє значення різних базових параметрів для установки звичайної стандартної (по базовим параметрам) продуктивності і позначте, що цей варіант і є правильним для експлуатованої системи


Визначення базових параметрів за допомогою System Monitor


Тепер для цілей збору базових параметрів викличемо System Monitor. Відкриємо Control Panel, Administrative Tools, Performance. Двічі клацнемо на Performance Logs and Alerts на лівій панелі. Натиснемо праву кнопку на Counter Logs і вкажемо New Log Settings. Введіть ім’я для графіка, потім натисніть OK. У діалоговому вікні Select Counters виберіть перший лічильник, потім натисніть Add. Повторюйте ці операції до тих пір, поки всі лічильники не будуть додані, потім натисніть Close.


Для початку спробуйте за замовчуванням 15-секундний інтервал. Або виберіть інший інтервал, натиснувши Properties (або використовуйте клавішну комбінацію швидкого виклику Ctrl + Q), а потім введіть значення під позначенням Sample automatically every: _ seconds. Довші інтервали займають менше місця, однак вони забезпечують менше докладні дані.


Виберіть таблицю Log Files і визначте місце, де будуть зберігатися дані. Є можливість переглянути дані пізніше, використовуючи подання View Log File Data. System Monitor буде виглядати так, як на екрані 1, коли він збирає дані базових параметрів продуктивності. Видно, що при одночасному відстеження безлічі лічильників можна зібрати дуже багато даних, так що слід уважно вибирати лічильники для основної лінії.


Крок 2: Встановлення еталонних значень


Після того як встановлені базові параметри продуктивності сервера, можна приступати до установки еталонних значень, що полегшує розуміння продуктивності сервера при роботі в декількох заздалегідь встановлених ситуаціях.


Для еталонів використовується той же режим моніторингу, що і для визначення базових параметрів. Можна використовувати своє рішення або один з поширених промислових засобів, таких як TPC-C або SAP, але кращі результати обчислення еталонних значень виходять при розробці звичайних індивідуальних сценаріїв, які налаштовані на використання певного сервера бази даних і його додатків.


Можна створити власний сценарій, використовуючи набір сценаріїв T-SQL, утиліти osql або Query Analyzer, SQL Profiler і System Monitor. Розробка сценаріїв навантажувальних тестів у T-SQL зазвичай займає декілька днів. Ще більше часу може знадобитися на збір даних виконання навантажувальних тестів і аналіз отриманих даних.


Після визначення базових параметрів продуктивності сервера при заздалегідь заданих навантаженнях можна буде дізнатися, чого можна очікувати від системи. Використовуйте дані, зібрані при отриманні еталонних значень для формування основи планового спостереження. Наприклад, з’ясувалося, що сервер здатний забезпечити до 249 транзакцій в секунду, перш ніж його робота почне сповільнюватися. В цьому випадку можна встановити повідомлення з низьким пріоритетом, коли сервер досягне завантаження близько 200 TPS і повідомлення з високим пріоритетом, коли сервер досягне 235 TPS. Такий спосіб дозволить адміністратору дізнатися про можливі проблемах з сервером і вжити необхідних заходів до того, як користувачі небудь помітять. І ніяких критичних ситуацій. Тепер це можливо.


Крок 3: Плановий моніторинг


Можливо, найбільш важлива складова режиму попереджувального моніторингу – це плановий моніторинг. Без нього не можна стежити за функціонуванням бази даних або виявляти проблеми в продуктивності.


Можна створити недорогий засіб для спостереження за SQL Server, використовуючи поєднання SQL Server Agent і System Monitor. SQL Server Agent дозволяє визначити, яка подія вивело помилку на монітор, встановити, хто отримує повідомлення про події і автоматично послати повідомлення, коли з’являється подія з помилкою.


Установка SQL Server Agent може бути тривалою за часом і складною, тому потрібно буде звернутися до розділу опису Alerts в SQL Server Books Online (BOL). SQL Server Agent зазвичай здійснює поточний контроль за повідомленнями про помилки роботи сервера бази даних і не контролює виконання.


Для контролю продуктивності сервера використовується System Monitor для спостереження за поточними лічильниками (встановіть частоту опитування з точністю до 15 хвилин).


Memory-Pages/sec


Network Interface-Bytes total/sec


Physical Disk-Disk Transfers/sec


Processor-% Processor Time


SQLServer:Access Methods-Full Scans/sec


SQLServer:Buffer Manager-Buffer Cache Hit Ratio


SQLServer:Databases Application Database-Transactions/sec


SQLServer:General Statistics-User onnections


SQLServer:Latches-Average Latch Wait Time


SQLServer:Locks-Average Wait Time


SQLServer:Locks-Lock Timeouts/sec


SQLServer:Locks-Number of Deadlocks/sec


SQLServer:Memory Manager-Memory Grants Pending


Встановіть значення для кожного лічильника між значеннями базових параметрів і еталонними значеннями, які показало тестування. Наприклад, можна встановити повідомлення, коли лічильник досягає 75 відсотків значення найвищої навантаження, і застережливе повідомлення, коли він проходить 90 відсотків.


Для виконання попереджень можна використовувати безкоштовні інструменти, такі як SQL Server Alerts & Notifications, System Monitor або придбати Microsoft Operations Manager (MOM) або інші засоби. Я рекомендую встановити попередження, по крайней мере, для наступних ситуацій:



Можна посилати сигнали тривоги для повідомлення адміністраторів за допомогою електронної пошти, пейджера або мережі. Можна встановити автоматизовані попередження для наступних джерел повідомлень:



Нарешті, необхідно впевнитися, що додатки власної розробки правильно реєструють помилки і, крім того, реагують на повідомлення про помилки від інших розроблених додатків.


Попереджуючий моніторинг продуктивності SQL Server означає визначення базових параметрів продуктивності, як для сервера, так і для програми; установку еталонних значень, які моделюють функціонування сервера у відповідності з наперед заданим використовуваним сценарієм, і виконання планового моніторингу, в ідеалі ініціюючого попередження, коли виявляється проблема. Незалежно від того, використовуються безкоштовні або вбудовані інструменти або вибрані рішення незалежних фірм, наявність контролю гарантує, що ви отримаєте в потрібний момент необхідну інформацію про роботу своїх додатків на SQL Server.



Таблиця 1. Об’єкти і лічильники System Monitor для визначення базових параметрів

















































Об’єкт і лічильник  Опис 
Memory-Pages/sec Число сторінок читання або запису на диск в секунду. Цей лічильник – первинний індикатор типів помилок, викликаних системними затримками або проблемами з продуктивністю
Network Interface-Bytes total/sec Число байтів, що проходять по мережевому інтерфейсу в секунду. Коли показник цього лічильника знижується або має таку тенденцію, це вказує на те, що проблеми з мережею можуть впливати на додаток
PhysicalDisk-Disk Transfers/sec Оцінка дискових операцій читання / запису. Встановіть лічильник для кожної фізичної диска на сервері
Processor-% Processor Time Процентне співвідношення часу, який процесор витрачає виконання робочого потоку. Цей лічильник працює як первинний індикатор діяльності процесора. Якщо всі процесори, що працюють на SQL Server, показують стовідсоткове використання, запити кінцевого користувача, швидше за все ігноруються
SQLServer:Access Methods-Full Scans/sec Число необмежених заповнених таблиць або індексних сканувань в секунду. Зниження значень цього лічильника на краще, бо перегляди часто викликають брак ресурсів проблеми кешування
SQLServer:Buffer Manager-Buffer Cache Hit Ratio Процентне відношення сторінок, які не вимагали читання від диска. Чим вище їх число, тим менше виробляється введення / виводу на диск. У добре налагодженій системі це значення повинно бути 80 або вище.
SQLServer:Databases-Log Growths На скільки, для конкретної бази даних, виріс файл транзакцій. У добре налагодженій системі значення цього лічильника повинно бути низьким, ймовірно, менше ніж один в кілька днів
SQLServer:Databases Application Database-Percent Log Used Процентне відношення вільного місця в журнальному файлі. Цей лічильник планово варіює, але не повинен досягати 100
SQLServer:Databases Application Database-Transactions/sec Число транзакцій, підтверджених у базі даних. Цей лічильник часом опускається в еталонах. Спостерігайте за тим, коли транзакції починають шикуватися в чергу, це вказує на те, що дисковий ввод / вивід може бути повільним
SQLServer:Latches-Average Latch Wait Time Середній час затримки запиту перед заповненням. Це значення лічильника може бути високим, коли сервер стикається з суперництвом за ресурси, особливо за пам’ять або за введення / виведення
SQLServer:Locks-Average Wait Time, Lock Waits/sec, Number of Deadlocks/sec Тимчасові блокування утримують ресурси SQL Server. Спостерігайте за висхідною тенденцією цих пов’язаних з блокуванням лічильників, що вказує на можливу проблему з продуктивністю
SQLServer:General Statistics-User Connections Число користувальницьких підключень до сервера бази даних. Перевіряйте будь помітні зрушення в значенні цього лічильника. Вони можуть вказувати на мережеві проблеми і свідчити про навантаження і уповільненні
SQLServer:Memory Manager-Memory Grants Pending Поточне число процесів, які очікують надання простору пам’яті. Висока або зростаюче значення може вказувати на недостатній обсяг пам’яті
SQLServer:User Settable-Query (a tracer query) Спеціалізований лічильник, також відомий як вказівник запитів. Цей лічильник – створений користувачем запит, який вказує загальну швидкість або ефективність системи. Щоб встановлювати це значення, додаток викликає sp_user_counter1 і повертає числове значення.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*