Повідомлення FlushCache, що з’являються в журналі в певний час

Останнім часом у нас виникає багато проблем із роботою бази даних, і я намагаюся зрозуміти, чи можу я зрозуміти, чому. У нас немає DBA (я розробник програмного забезпечення), тому я щось просто крилатую, і багато чого з того, що я знаходжу в Інтернеті, читається як іноземна мова для мене.

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

FlushCache: очищено 11848 помилок з 7432 записом у 97168 мс (уникнути 8139 нових брудних помилок) для db 9: 0

остання невирішена ціль: 4, avgWriteLatency 32

середня пропускна здатність: 0,72 Мб / с, насичення вводу / виводу: 11635, контекстні комутатори 18849

Цифри щоразу різняться, але це те саме повідомлення повторюється за цією схемою, поки я не перезавантажую сервер. Я не впевнений, як це інтерпретувати, я намагався Google про це, і все, що я зібрав, це те, що це означає, що з I / O може бути щось не так, і що щось займає довше, ніж належить. Нещодавно ми перейшли на використання SSD, тому я не вважав, що це має бути проблема запису.

Чи може хтось пролити на це світло?

Повідомлення FlushCache в журналі помилок викликається реєстрацією контрольної точки, а в цьому випадку - довгою контрольною точкою (яка визначається як контрольна точка, яка займає більше часу, ніж інтервал відновлення). Незалежно від того, зареєстровано чи ні, поведінка відрізняється до 2012 та 2012 років. Перед SQL Server 2012, щоб здійснити реєстрацію контрольної точки, вам потрібно було б увімкнути прапор трасування (T3504). Але починаючи з SQL Server 2012, це повідомлення реєструється за замовчуванням, коли виникає довга контрольна точка.

Щодо питання "чи це насправді погано ?" , вам дійсно потрібно почати дивитися на ці числа, враховуючи їхній контекст. Щоб промити лише близько 93 Мб брудних буферів, вам знадобилося 97+ секунд. Це виглядає так, що це потенційно може бути сумішшю великої кількості даних (під час фактичної самої контрольної точки також було забруднено близько 64 МБ буферів) і потенційно сховище, яке не йде в ногу з модифікацією даних та / або іншими робочого навантаження вводу / виводу.

Що я хотів би зробити, це перевірити стан вашої підсистеми зберігання даних , подивитися на очікування та просто отримати загальну картину продуктивності цього примірника. Погляньте на лінійні лічильники парфмонів дискових даних і подивіться, що таке загальний збір вводу / виводу з пропускною здатністю , затримкою та IOps . Це допоможе вам намалювати більш яскраві уявлення про ефективність дисків. Якщо у вас є можливість орієнтовувати ваше сховище, якщо ви його ще не встановили на базовому рівні, ви повинні побачити, на що здатні ці томи, про які йдеться ( SQLIO - це велика утиліта для цього) і що вони роблять зараз (приємно мати базовий рівень базового рівня, коли обсяги були підняті порівняно з поточним показником).

Ось чудова стаття, що пояснює це повідомлення - Як це працює: Коли додається повідомлення FlushCache до журналу помилок SQL Server?

EDIT : Перечитавши ваше запитання, я, мабуть, пропустив цей коментар:

Я помітив, що кожного ранку близько 5 ранку ми починаємо отримувати це повідомлення

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