Очищення кешу SQL Server та введення / виведення диска

Ми зайняті тестуванням навантаження OLTP-системи, розробленої нами в .NET 4.0 і запускаємо SQL Server 2008 R2 ззаду. Система використовує черги SQL Server Service Broker, які є дуже ефективними, але ми відчуваємо особливу тенденцію під час обробки.

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

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

Під час усунення несправностей ми намагалися виконати наступне без істотних змін у шаблоні:

• Зупинено агент SQL Server.
• Загинув майже кожен інший запущений процес (немає A / V, SSMS, VS, Windows Explorer тощо)
• Видалено всі інші бази даних.
• Вимкнено всі таймери розмов (ми не використовуємо жодних тригерів).
• Відійшов від підходу, керованого чергою повідомлень, до простого / грубого дизайну моніторингу таблиці.
• Використовуються різні навантаження від легких до важких.
• Виправлені всі тупики.

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

Далі я планую перенести рішення до нашої спеціальної тестової середовища, щоб побачити, чи можу я повторити проблему. Будь-яка допомога в проміжку буде дуже вдячна.

Оновлення 1 За запитом, графік, що включає сторінки контрольної точки / сек , тривалість сторінки сторінки та деякі лічильники затримки диска.

Схоже, контрольна точка (світло-синя лінія) є причиною зниження продуктивності (жовта лінія), яку ми спостерігаємо. ^

Затримка диска залишається відносно послідовною під час обробки, а тривалість життя сторінки, здається, не робить помітного ефекту. Ми також відкоригували кількість оперативної пам’яті, доступну для SQL Server, що також не мало великого ефекту. Зміна моделі відновлення з SIMPLEна FULLтакож мало значення.

Оновлення 2 Змінивши "Інтервал відновлення" наступним чином, нам вдалося скоротити інтервал, у якому виникають контрольні точки:

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

Я не впевнений, чи це погана практика?

Інші вже вказали на вину: SQL Server накопичує оновлення в пам'яті (у буферному пулі) і лише періодично вимиває їх (у контрольних точках). Запропоновані два варіанти (-k та інтервал контрольної точки) є додатковими:

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

Але я не відповідав лише на те, щоб відрегулювати прекрасні коментарі, які ви отримали далеко далеко :)

На жаль, дуже типова поведінка обробки черг . Незалежно від того, чи використовуєте ви черговий сервіс-брокер чи вибираєте використання таблиць у якості підходу до черг , система дуже схильна до такої поведінки. Це пояснюється тим, що обробка на основі черги - це важке записування, навіть більше важке, ніж обробка OLTP. Обидва Епдіеіе і висновок з примітивів операція запису і там майже немає операції читання. Простіше кажучи, обробка черг створить найбільше записів (= найбільш брудні сторінки та найбільше журналу) порівняно з будь-яким іншим робочим навантаженням, навіть OLTP (наприклад, навантаженням TPC-C ).

Дуже важливо, що записи завантаження черги слідують за шаблоном вставки / видалення: кожен вставлений рядок дуже швидко видаляється. Це важливо, щоб відрізнити лише доданий зразок великої завантаженості (ETL). Ви, як правило, годуєте привидом прибирання повноцінною їжею, і можете легко його перемогти. Подумайте, що це означає:

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

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

Таким чином, у вас є ці три точки написання, гонки, щоб знову і знову відмітити одну і ту ж сторінку брудно. І це перш ніж ми розглянемо будь-які розбиття сторінок, до яких обробка черг може бути схильна також через порядок вставки ключів. Для порівняння "типові" навантаження на OLTP мають набагато більш збалансований коефіцієнт читання / запису, і OLTP записує розповсюдження через вставки / оновлення / видалення, часто з оновленнями ("зміни" статусу) та вставками, що займають левову частку. Записи обробки черги є виключно вставкою / видаленням з визначенням 50/50 розділення.

Наступні наслідки:

• Пункт пропуску стає дуже гарячим питанням (більше не для вас сюрприз)
• Ви побачите велику фрагментацію (фрагментація сама по собі не матиме великого значення, оскільки ви не збираєтеся робити сканування діапазону, але ваша ефективність вводу-виводу страждає і очищення привидів має більше працювати, уповільнюючи його ще більше)
• Ваша пропускна здатність IO для зберігання в МДФ стане вашим вузьким місцем

Моя рекомендація складається з 3 букв: S, S та D. Перемістіть ваш MDF у сховище, яке може працювати з швидким випадковим IO. SSD. Fusion-IO, якщо у вас є гроші. На жаль, це один із тих симптомів, який неможливо вирішити за допомогою більш дешевої оперативної пам'яті ...

Редагувати:

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