Використання монітора продуктивності для визначення вузьких місць апаратних засобів

Список контрольних питань аудиту продуктивності

















































Назва лічильника Середнє число Мінімум Максимум
Пам'ять: Сторінки / секунди      
Пам'ять: Доступне простанство (байти)      
Фізичний диск: Час роботи диска%      
Фізичний диск: Середня довжина черги диска      
Процесор: Процесорний час%      
Система: Довжина черги процесора      
Буфер SQL Server: Коефіцієнт вдалого звернення до кеш буфера      
SQL Server: Користувальницькі підключення      

Введіть ваші результати в таблицю, наведену вище.


Використання монітора продуктивності (Performance Monutor) для ідентифікації вузьких місця апаратних засобів SQL Server


Найкраще почати аудит продуктивності SQL Server з монітора продуктивності (System Monitor). Моніторинг декількох основних лічильників за період 24 годин дозволить вам одержати досить гарне уявлення про будь головних апаратних проблеми, які позначаються на продуктивності SQL Server.


У ідеалі Ви повинні використовувати монітор продуктивності для створення файлу реєстрації (журналу) показань ключових лічильників строком на 24 години. Вам належить обрати "типовий" 24-годинний період для створення файлу реєстрації. Наприклад, виберіть типовий робочий день, не кінець тижня або свято.


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


Як інтерпретувати ключові лічильники монітора продуктивності


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


Пам'ять: Сторінки / секунди


Цей лічильник вимірює кількість сторінок в секунду, що скидаються з оперативної пам'яті на диск, або зчитуються в оперативну пам'ять з диска. Чим інтенсивніше відбувається обмін сторінками, тим більшу навантаження на операціях вводу / виводу відчуває ваш сервер, що, у свою чергу, може негативно позначитися на продуктивності SQL Server. Ваша мета полягає в тому, щоб постаратися звести обмін сторінками до мінімуму, не усуваючи його.


У припущенні, що SQL Server є єдиним головним додатком, що виконується на вашому сервері, це число повинне в ідеалі знаходитися в інтервалі між нулем і 20. Досить імовірно, що Ви будете спостерігати викиди, значно перевищують 20, що цілком нормаллю. Основним тут є підтримка середнього значення обміну сторінками в секунду менше 20.


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


У більшості випадків, на фізичному сервері, спеціалізованому під SQL Server, з адекватною кількістю оперативної пам'яті, середнє значення обміну сторінками буде менше ніж 20. Адекватна кількість оперативної пам'яті для SQL Server можна визначити за наступним критерієм: сервер повинен мати коефіцієнт вдалого звернення до кеш буфера (Buffer Hit Cache Ratio) 99% і вище. Даний лічильник описаний нижче в цій статті. Якщо Ви маєте SQL Server, у якого цей коефіцієнт має значення 99% або вище протягом 24 годин, але Ви отримуєте середнє значення обміну сторінками більше 20 протягом того ж самого періоду часу, це може вказувати на те, що у Вас виконуються і інші додатки на фізичному сервері крім SQL Server. Якщо справа йде саме так, Ви повинні в ідеальному випадку видалити ці програми, дозволивши SQL Server бути єдиним головним додатком на фізичному сервері.


Якщо ваш Сервер SQL не виконує ніякі інші програми, і обмін сторінками перевищує 20 в середньому протягом 24 годин, це може означати, що Ви змінили параметри налаштування пам'яті SQL Server. SQL Server повинен бути конфигурирована так, щоб була встановлена опція "Dynamically configure SQL Server memory" (Динамічно конфігурувати пам'ять SQL Server), а установка "Maximum Memory" повинна знаходитися в найбільшому значенні. Для оптимальної роботи, SQL Server потрібно дозволити взяти стільки оперативної пам'яті, скільки йому потрібно для власних потреб, не відчуваючи необхідності конкурувати за оперативну пам'ять з іншими додатками.


Пам'ять: Доступне простір


Інший спосіб з'ясувати, чи має ваш SQL Server досить фізичної оперативної пам'яті, полягає в тому, щоб перевірити лічильник Memory Object: Available Bytes. Його значення має бути більше 5 МБ. В іншому випадку, ваш Сервер SQL має потребу в більшій кількості фізичної оперативної пам'яті. На сервері, спеціалізованому під SQL Server, останній намагається утримувати від 4-10MB вільної фізичної пам'яті. Залишилася, фізична оперативна пам'ять використовується операційною системою і SQL Server. Коли обсяг доступної пам'яті близько до 5 МБ або нижче, найбільш ймовірно, що SQL Server відчуває перевантаження через брак пам'яті. Якщо це має місце, Ви повинні збільшити кількість фізичної оперативної пам'яті в сервері, зменшити навантаження на сервер або змінити параметри налаштування конфігурації пам'яті вашого SQL Server відповідно.


Фізичний диск: Час роботи диска%


Цей лічильник показує, наскільки зайнятий фізичний дисковий масив (не логічний розділ або окремий диск в масиві). Він забезпечує хорошу відносну міру того, наскільки зайняті ваші дискові масиви.


Як емпіричне правило, лічильник часу диска повинен показувати менше 55%. Якщо показання лічильника перевищують 55% протягом безперервних періодів (понад 10 хвилин протягом ваших 24 годин моніторингу), то ваш SQL Server може мати проблеми з операціями вводу / виводу. Якщо Ви спостерігаєте це поведінка лише зрідка протягом ваших 24 годин моніторингу, я б не хвилювався занадто сильно, але якби це траплялося часто (скажімо, кілька разів годину), то я почав би шукати способи збільшити продуктивність операцій введення / виводу на сервері або зменшити завантаження сервера. Деякі способи збільшувати дисковий введення / висновок полягають у додаванні нових дисків в масив (якщо це можливо), заміни дисків на більш швидкі, додаванні кеш-пам'яті на платі контролера (якщо це можливо), використання різних версій RAID або установки більш швидкого контролера.


Перед використанням цього лічильника під NT 4.0, потрібно вручну включити його, ввівши в Command Prompt наступне: "diskperf-y". Після цього потрібно буде перезавантажити ваш сервер. Таким чином, потрібно відразу включати дискові лічильники під Windows NT 4.0. Якщо Ви працюєте під Windows 2000, цей лічильник включений за замовчуванням.


Фізичний диск: Середня довжина черги диска


Крім спостереження за значенням лічильника "Фізичний Диск: Час роботи диска", бажано також відстежувати значення лічильника середньої довжини черги диска (Avg. Disk Queue Length). Якщо це значення перевищує значення 2 для безперервних періодів (понад 10 хвилин протягом вашого 24 годинного моніторингу) для кожного дисководу в масиві, то цей масив може виявитися вузьким місцем продуктивності системи. Подібно лічильнику часу роботи диска, якщо це відбувається зрідка протягом 24 годин періоду моніторингу, я не сильно хвилювався б, але якщо це відбувається часто, тоді я б почав шукати способи збільшити продуктивність системи вводу / виводу сервера, як це описано вище.


Вам доведеться обчислити цей показник, оскільки Performance Monitor не знає, скільки фізичних дисків знаходиться у вашому масиві. Наприклад, якщо у вас є масив з 6 фізичних дисків, і середня довжина черги дорівнює 10 для цього масиву, тоді фактичне середнє значення дискової черзі для кожного диска складає 1.66 (10 / 6 = 1.66), що добре вкладається в рекомендований показник 2 на один фізичний диск.


Перед використанням цього лічильника під NT 4.0, не забудьте вручну включити його, набравши на запрошення до введення команд NT (Command Prompt) таке: "diskperf-y" з подальшою перезавантаження вашого сервера. Тому потрібно включати дискові лічильники відразу після установки Windows NT 4.0. Якщо Ви використовуєте Windows 2000, то цей лічильник буде включений за замовчуванням.


Використовуйте обидва описаних вище лічильника, щоб точно з'ясувати, чи відчуває ваш сервер проблеми з системою введення / виводу. Наприклад, якщо Ви бачите багато періодів часу, протягом яких час роботи диска більше 55%, і коли середнє значення довжини черги диска складає більше 2 на один фізичний диск, Ви можете бути впевненими, що сервер має проблеми з системою введення – виведення.


Процесор: Процесорний час%


Лічильник Processor Object:% Processor Time є для кожного центрального процесора і оцінює використання кожного окремого центрального процесора. Аналогічний лічильник є також для всієї сукупності центральних процесорів (загальна кількість). Це ключовий лічильник для стеження за використанням центрального процесора. Якщо загальний час завантаження процесорів з цього лічильнику перевищує 80% протягом безперервних періодів (понад 10 хвилин протягом 24 годинного періоду моніторингу), то Ви можете вважати центральний процесор вузьким місцем системи. Якщо ці періоди сильної завантаження відбуваються зрідка, і Ви вважаєте, що можете змиритися з цим, то все в порядку. Але якщо вони виникають часто, Вам слід розглянути такі варіанти зниження завантаження сервера, як придбання більш швидких центральних процесорів, установку більшої кількості центральних процесорів, або придбання центральних процесорів, які мають більший вбудований кеш другого рівня (L2).


Система: Довжина черги процесора


Поряд з лічильником процесорного часу, Вам слід також контролювати лічильник довжини черги процесора (Processor Queue Length). Якщо цей показник перевищує значення 2 на один центральний процесор протягом безперервних періодів (понад 10 хвилин протягом вашого 24 годинного періоду моніторингу), то ймовірно це є вузьким ланкою системи. Наприклад, якщо на Вашому сервері є 4 центральних процесора, довжина черги процесора не повинна перевищувати в цілому значення 8.


Якщо довжина черги процесора регулярно перевищує рекомендований максимум, але використання центрального процесора не настільки високо (що є типовим випадком), то розгляньте варіант зменшення значення конфігураційного параметра SQL Server "max worker threads" (максимального числа ниток). Можливою причиною високого значення довжини черги процесора є наявність надлишкового числа робочих ниток, які чекають своєї черги. Зменшуючи їх кількість, що Ви і робите з допомогою цього параметра, змушує задіяти пулинг ниток (якщо це ще не має місце), або підвищити його роль.


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


Буфер SQL Server: Коефіцієнт вдалого звернення до кеш буфера


Цей лічильник (SQL Server Buffer: Buffer Cache Hit Ratio) показує, як часто SQL Server звертається до буфера, а не до жорсткого диска, щоб отримати дані. У додатках OLTP, цей коефіцієнт повинен перевищувати 90%, а в ідеалі бути вище 99%. Якщо ваш коефіцієнт вдалого звернення до буферний кеш нижче 90%, Вам слід піти і купити більше оперативної пам'яті вже сьогодні. Якщо цей коефіцієнт лежить в діапазоні між 90% і 99%, то Ви повинні серйозно розглянути варіант покупки додаткової оперативної пам'яті, тому що чим ближче Ви наближаєтеся до 99%, тим швидше ваш SQL Server буде працювати. У деяких випадках, якщо ваша база даних є дуже великий, Вам не вдасться наблизитися до 99%, навіть якщо Ви поставите максимально допустиму кількість оперативної пам'яті на вашому сервері. Тоді все, що Ви можете зробити, – це додати пам'ять по максимуму і змиритися з існуючим станом речей.


У додатках OLAP, коефіцієнт може бути набагато менше через природи роботи цього OLAP-додатки. У будь-якому випадку, збільшення оперативної пам'яті повинно прискорити роботу SQL Server.


SQL Server: Користувальницькі підключення


Оскільки число користувачів Сервер SQL, впливає на його продуктивність, рекомендується стежити за лічильником користувальницьких підключень (SQL Server General Statistics Object: User Connections counter). Він показує число користувальницьких підключень, а не кількість користувачів, які підключені до SQL Server в даний момент часу.


Якщо показання цього лічильника перевищують 255, то Вам слід збільшити значення конфігураційного параметра "Maximum Worker Threads" (максимальне число робочих ниток), значення за замовчуванням якого дорівнює 255. Якщо число підключень перевищує наявну кількість робочих ниток, то SQL Server почне спільно використовувати робочі нитки, що може негативно позначитися на продуктивності. Установка цього параметра повинна бути вище, ніж максимальне число підключень, яке може бути досягнуто на вашому сервері.


Що далі


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

Brad M. McGehee(Оригінал: Using Performance Monitor to Identify SQL Server Hardware Bottlenecks)
Переклад: Моісеєнко С.І.
Оригінал перекладу

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


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

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

Ваш отзыв

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

*

*