У SQL Server виникли запити вводу / виводу, що тривали більше 15 секунд

На виробництві SQL Server у нас є така конфігурація:

3 сервери Dell PowerEdge R630, об’єднані в групу доступності Усі 3 підключені до одного накопичувача SAN Dell SAN, який є масивом RAID

Час від часу на ПОЧАТКУ ми бачимо повідомлення, схожі на наведені нижче:

SQL Server зіткнувся з 11 явищами запитів вводу / виводу, тривалістю яких більше 15 секунд для завершення файлу [F: \ Data \ MyDatabase.mdf] у ідентифікаторі бази даних 8.
Ручка файлу ОС 0x0000000000001FBC.
Зсув останнього довгого вводу-виводу становить: 0x000004295d0000.
Тривалість довгого вводу / виводу становить: 37397 мс.

Ми початківці у вирішенні проблем з продуктивністю

Які найпоширеніші способи чи найкращі практики щодо вирішення цієї проблеми, пов’язаної зі зберіганням? Які лічильники, інструменти, монітори, додатки тощо потрібно використовувати для звуження до першопричини таких повідомлень? Чи можуть бути розширені події, які можуть допомогти, або якийсь аудит / реєстрація?

У нас є аналогічне налаштування, і нещодавно в журналах зустрічалися ці повідомлення. Ми використовуємо DELL Compelect SAN. Ось кілька речей, які потрібно перевірити, отримуючи ці повідомлення, які допомогли нам знайти рішення

• Перегляньте свої лічильники роботи Windows на свої диски, на які вказують попереджувальні повідомлення, зокрема:
  • Сер. Диска час читання
  • Сер. Диска час запису
  • Диск читання байтів / сек
  • Диск запису байтів / сек
  • Дискові перекази / сек
  • Сер. довжина черги диска
• Вищезазначені є середніми. Якщо у вас на одному диску багато файлів баз даних, ці показники можуть перекосити результат і замаскувати горловину пляшки на конкретних файлах бази даних. Ознайомтеся з цим запитом від Paul S. Randal, який повертає середню затримку для кожного файлу з dmv sys.dm_io_virtual_file_stats. У нашому випадку середня повідомлена затримка була прийнятною, але під обкладинками було багато файлів із середньою затримкою> 200 мс.
• Перевірте терміни. Чи є якась закономірність? Чи трапляється це частіше в певний час ночі? Якщо так, перевірте, чи виконуються будь-які завдання з технічного обслуговування на той час або якась запланована діяльність, яка може збільшити активність диска та виявити горловину пляшки у вашій підсистемі вводу-виводу.
• Перевірте переглядач подій Windows на наявність помилок. Якщо ваш перемикач або SAN перевантажені або не налаштовані належним чином для вашої програми, ви можете знайти деякі повідомлення в цьому журналі, і добре передати цю інформацію своєму адміністратору SAN. У нашому випадку ми отримували помилки підключення iSCSI часто протягом дня, натякаючи на проблему.
• Перегляньте свій код SQL Server. Коли ви отримуєте ці повідомлення, ви не повинні відразу думати, що це проблема підсистеми вводу-виводу, і передавати їх своєму адміністратору SAN. Вам потрібно зробити свою частину і переглянути базу даних. У вас справді погані запити, які часто проводяться через тонни даних? Погана індексація? Запис надмірних журналів транзакцій? Ви можете використовувати деякі запити з відкритим кодом, щоб отримати перевірку стану здоров’я вашої бази даних, приклад перевірки того, як виглядає ваш план запитів, є sp_blitzCache
• Не ігноруйте їх. Сьогодні ви можете їх отримувати кілька разів на день ... потім через кілька місяців, коли ваше навантаження збільшується, і ви забули стежити за ними, вони починають збільшуватися. Отримання великої кількості цих повідомлень може завадити доступу SQL Server до певного файлу, і якщо він є tempdb , це не добре. У нашому випадку стало так погано, що SQL Server закрився.

Нашим рішенням було оновлення нашого перемикача до перемикача SAN. Так, це всі пункти, які слід охопити в SQL Server. Що дозволило нам з'ясувати, що це перемикач, це те, що ми щодня отримували близько 1500 помилок відключення iSCSI pdu у переглядачі подій програми Windows на SQL Server. Це спонукало до розслідування наших адміністраторів SAN в комутаторі.

Відразу після оновлення помилки iSCSI пішли і середня затримка знизилася до 50 мс для всіх файлів, і це корелює з кращою продуктивністю в додатку. Маючи на увазі ці моменти, сподіваємось, ви зможете знайти своє рішення.

Це набагато рідше випуск диска, і набагато частіше випуск мережі. Ви знаєте, N в SAN?

Якщо ви перейдете до своєї команди SAN і почнете говорити про те, що диски повільні, вони покажуть вам фантазійний графік із затримкою 0 мілісекунд, а потім вкажуть на вас степлером.

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

Тоді ви можете використовувати позначку Crystal Disk Mark або diskpd для перевірки цих швидкостей. Якщо вони знову не вишикуються, це, швидше за все, мережа.

Ви також повинні шукати у своєму журналі помилок повідомлення, які містять "FlushCache" та "saturation", тому що вони також можуть бути ознаками суперечності мережі.

Одне, що ви можете зробити, щоб уникнути таких речей, як DBA, - це переконатися, що ваше обслуговування та будь-які інші важкі завдання (наприклад, ETL) не продовжуються одночасно. Це, безумовно, може чинити великий тиск на мережу зберігання даних.

Ви також можете перевірити відповіді, щоб отримати додаткові пропозиції: Повільна контрольна точка та попередження вводу / виводу 15 секунд на флеш-пам’яті

Я блогів про подібну тему тут: від сервера до SAN

Навіщо зберігати дані в SAN? У чому справа? Вся продуктивність бази даних прив’язана до вводу-виводу диска, і ви використовуєте 3 сервери з одним пристроєм для вводу-виводу за ними. Це не має сенсу ... і, на жаль, так поширене.

Я проводжу своє життя, стикаючись з погано розробленими апаратними платформами, де люди просто намагаються створити широкомасштабний комп'ютер. Вся потужність процесора тут, всі диски там ... сподіваємось, не існує такого поняття, як віддалена оперативна пам'ять. І найсумніше - вони компенсують недостатню ефективність цієї конструкції величезними серверами, які коштують удесятеро дорожче, ніж повинні. Я бачив інфраструктуру на $ 400 000 повільніше, ніж ноутбук на $ 1 тис.

Програмне забезпечення сервера SQL - це дуже вдосконалене програмне забезпечення, воно розроблене для того, щоб скористатися будь-якими бітами обладнання, процесорними ядрами, кешем процесора, TLB, оперативною пам'яттю, дисковими контролерами, кешем жорсткого диска ... Вони майже включають всю логіку файлової системи. Вони розробляються на звичайних комп'ютерах і орієнтовані на високих класах. Тому SQL-сервер повинен мати власні диски. Встановлення їх в SAN - це як "емуляція" комп'ютера, ви втрачаєте всі оптимізації продуктивності. SAN призначені для зберігання резервних копій, незмінних файлів та файлів, до яких ви просто додаєте дані (журнали).

Адміністратори датацентру прагнуть поставити все можливе на SAN, оскільки таким чином у них є лише один запам’ятовуючий запас для управління, це простіше, ніж турбота про зберігання на кожному сервері. Це вибір "я не хочу робити свою роботу", і дуже поганий, адже тоді їм доводиться стикатися з проблемами продуктивності, і вся компанія страждає від цього. Просто встановіть програмне забезпечення на апаратне забезпечення, для якого воно призначене. Не ускладнювати. Догляд за пропускною здатністю вводу / виводу, кешем та контекстними перемиканнями режиму, тремтінням ресурсу (трапляється, коли ресурс спільний). Ви в кінцевому підсумку підтримуватимете 1/10 пристроїв з однаковою вихідною потужністю, заощадите команді ops багато головних болів, отримаєте продуктивність, яка зробить ваших кінцевих користувачів щасливими та більш продуктивними, зробить вашу компанію кращим місцем для роботи та економте багато енергії (планета буде вам вдячна).

Ви сказали в коментарях, ви плануєте поставити SSD на свій сервер. Ви не розпізнаєте налаштування з виділеними SSD-дисками, порівняно з SAN ви отримаєте щось на зразок покращення в 500 разів навіть із файлами журналу даних та транзакцій на одному диску. У найсучаснішому SQL сервері буде швидко відокремлений SSD для даних та журналу транзакцій на різних каналах апаратних контролерів (більшість материнських плат сервера мають кілька). Але в порівнянні з вашою нинішньою установкою ми говоримо про наукову фантастику. Просто спробуйте SSD.

Добре, для всіх, хто цікавиться,

Ми вирішили проблему в "Запитаннях" пару місяців тому, просто встановивши приєднані SSD-накопичувачі на кожен з 3-х серверів і перемістивши дані БД та файли журналу з SAN на ці SSD-диски

Ось підсумок того, що я зробив для дослідження цього питання (використовуючи рекомендації з усіх постів, це це питання), перш ніж ми вирішили встановити SSD-накопичувачі:

1) розпочав збір лічильників PerfMon для наступних накопичувачів на всіх 3 серверах:

Disk F:- це логічний диск на базі SAN, містить файли даних MDF
Disk I:- це логічний диск на базі SAN, містить файли журналу LDF
Disk T:, безпосередньо додається SSD, присвячений виключно tempDB

На малюнку нижче - середні значення, зібрані за 2 тижні

Disk I: (LDF)у нього такий невеликий IO, а затримка дуже низька, тому Disk I: можна ігнорувати
Ви можете бачити, що він Disk T: (TempDB)має більший IO порівняно з Disk F: (MDF), і він має значно кращу затримку одночасно - 0 мс

Очевидно, що з Disk F щось не так: там, де перебувають файли даних, він має високу затримку та середню чергу запису диска, незважаючи на низький IO

2) Перевірена затримка окремих баз даних за допомогою запиту на цьому веб-сайті

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Мало активних баз даних на первинному сервері мали затримку читання 150-250 мс та затримку запису 150-450 мс
Що цікаво, майстри та файли баз даних MSDB мали затримку до 90 мс, що підозріло, враховуючи невеликий розмір даних та низький IO - ще одна вказівка, що щось не в порядку з SAN

3) Конкретних термінів не було

Під час якого "SQL Server зіткнувся з появою випадків ..." з'явилися повідомлення
Не було технічного обслуговування або важкого диска ETL, коли ці повідомлення були зареєстровані

4) Переглядач подій Windows

Не показано жодних інших записів, які б натякали на проблему, за винятком випадків виникнення "SQL Server".

5) Розпочали перевірку топ-10 запитів

Від sp_BlitzCache (процесор, зчитування тощо) та оптимізація, де це можливо,
Немає важких запитів супер IO, які б виправляли тони даних і сильно впливали на сховище, хоча
індексація в базах даних нормальна, я її підтримую

6) У нас немає команди SAN

У нас є лише 1 sysadmin, який допомагає з
певних випадків Мережевий шлях до SAN - це багатофазний, кожен з 3 серверів має 2 мережевих кабелю, що ведуть до комутаторів, а потім до SAN, і його повинен бути 1 гігабайт / сек.

7) Результатів CrystalDiskMark не було

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

8) Налаштування сеансу розширених подій на події контрольно-пропускного пункту для відповідної бази даних

Сеанс XE допоміг виявити, що під час повідомлень "SQL Server зіткнувся з випадками ..." контрольний пункт відбувався дуже повільно (до 90 секунд)

9) Журнал помилок SQL Server

Містяться записи "FlushCache" "Насичення"
Вони повинні з'являтися, коли час контрольної точки для даної бази даних перевищує налаштування інтервалу відновлення

Деталі показали, що кількість даних, яку КПП намагається стерти, невелика, і це потребує тривалого часу, а загальна швидкість - близько 0,25 Мб / с ... дивно

10) Нарешті, на цьому малюнку показана схема усунення несправностей із зберіганням:

Здається, у нас просто "Проблема обладнання: - Працюйте з системним адміністратором / постачальником обладнання, щоб виправити будь-яку неправильну конфігурацію SAN, старих / несправних драйверів, контролерів, програмного забезпечення тощо".

В іншому запитанні "Повільна контрольна точка ..." Повільна контрольна точка та 15-секундні попередження вводу-виводу на флеш-пам’яті Шон мав дуже приємний перелік того, що потрібно перевірити на апаратному та програмному рівні для усунення несправностей.

Наш sysadmin не міг перевірити всі речі зі списку, тому ми просто вирішили кинути певну техніку в цьому питанні - це зовсім не було дорого.

Роздільна здатність:

Ми замовили 1 TB накопичувачі SSD та встановили прямо на сервери

Оскільки у нас є групи доступності, ми перенесли файли даних БД з SAN на SSD на вторинних репліках, потім не вдалося перенести та перенесли файли на колишній первинний. Це дозволило за мінімальний загальний час простою - менше 1 хвилини

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

Наскільки ефективність щодо затримки вводу-виводу покращилася після перенесення файлів БД на SSD?

Для оцінки впливу використовували журнали продуктивності Windows Performance Monitor за 2 тижні до міграції та 4 тижні після міграції:

Також нижче наведено порівняння статистики затримки рівня БД (використана статистика захоплених віртуальних файлів SQL Server до та після міграції)

Підсумок

Міграція з SAN на безпосередньо приєднані локальні SSD була варте того, що
вона мала великий вплив на затримку пам’яті та покращилася в середньому понад 90% (особливо WRITE-операції), і ми вже не маємо 20-50-ти сек.

Перехід на локальний SSD вирішив не лише проблеми зі збереженням даних, але й безпеку даних, про які я був стурбований (якщо SAN виходить з ладу, усі 3 сервери втрачають свої дані одночасно)