В последнее время у нас было много проблем с производительностью баз данных, и я пытался понять, смогу ли я понять, почему. У нас нет администратора баз данных (я являюсь разработчиком программного обеспечения), поэтому я как бы его обожаю, и большая часть того, что я нахожу в Интернете, выглядит для меня как иностранный язык.
Мы перезапускали SQL Server каждое утро, потому что это единственный способ его работы в течение рабочего дня. Я заметил, что каждое утро около 5 часов утра мы начинаем получать это сообщение каждые две минуты в журнале:
FlushCache: очищено 11848 буфферов с 7432 записями за 97168 мс (исключено 8139 новых грязных буффов) для 9: 0
последняя цель невыполнена: 4, avgWriteLatency 32
средняя пропускная способность: 0,72 МБ / с, насыщенность ввода-вывода: 11635, переключатели контекста 18849
Конечно, числа меняются каждый раз, но это повторяет одно и то же сообщение, пока я не перезагружу сервер. Я не уверен, как это интерпретировать, я пытался узнать об этом в Google, и все, что я понял, это то, что это может быть что-то не так с вводом / выводом, и что что-то занимает больше времени, чем предполагалось. Недавно мы перешли на использование SSD, поэтому я не думал, что это должно быть проблемой записи.
Может ли кто-нибудь пролить свет на это?
источник
Ответы:
Сообщение FlushCache в журнале ошибок вызвано регистрацией контрольной точки, и в этом случае длинной контрольной точкой (которая определяется как контрольная точка, которая занимает больше времени, чем интервал восстановления). Вне зависимости от того, зарегистрирован он или нет, поведение до 2012 и 2012+ будет другим. До выхода SQL Server 2012 для регистрации контрольных точек необходимо было включить флаг трассировки (T3504). Но начиная с SQL Server 2012, это сообщение регистрируется по умолчанию при обнаружении длинной контрольной точки.
Теперь что касается вопроса "это на самом деле плохо ?" Вам действительно нужно начать смотреть на эти цифры с учетом их контекста. Вам потребовалось более 97 секунд, чтобы очистить только около 93 МБ грязных буферов. Похоже, что это может быть смесь большого количества данных (во время самой контрольной точки буферы объемом около 64 МБ также были загрязнены) и потенциально хранилища, которое не поспевает за изменением данных и / или остальными рабочей нагрузки ввода / вывода.
Я хотел бы проверить работоспособность вашей подсистемы хранения , посмотреть на ожидания и просто получить общую картину производительности экземпляра. Посмотрите на счетчики производительности логических дисков и посмотрите, какова общая отток ввода-вывода с пропускной способностью , задержкой и операциями ввода-вывода . Это поможет вам нарисовать более яркую картину того, как работают диски. Если у вас есть возможность сравнить свою систему хранения, если вы еще не определили ее, вы должны увидеть, на что способны эти тома ( SQLIO - отличная утилита для этого) и что они делают прямо сейчас (приятно иметь базовый уровень, когда объемы были сопоставлены с текущим уровнем).
Вот отличная статья, объясняющая это сообщение: как это работает: когда сообщение FlushCache добавляется в журнал ошибок SQL Server?
РЕДАКТИРОВАТЬ : Перечитывая ваш вопрос, я, должно быть, пропустил этот комментарий:
Посмотрите, что происходит в вашем хранилище в настоящее время в соответствии с указаниями выше. Это похоже на запланированную учебником операцию, которая сказывается на хранении, из-за чего производительность контрольной точки снижается и становится «длинной».
источник