Срок службы страницы SQL Server 2012 сбрасывается до 0 примерно через 50 дней


12

Я заметил странное поведение в кластере высокой доступности с двумя серверами, и я надеялся, что кто-то может подтвердить мое подозрение или, возможно, предложить какое-то другое объяснение ... Вот мои настройки:

  • Установка SQL 2012 SP1 с двумя серверами
  • SQL AlwaysOn HA был включен для нескольких баз данных
  • Процессоры 2,4 ГГц, 4 ядра
  • Объем оперативной памяти составляет 34 ГБ (это экземпляр AWS, отсюда и нечетное число)
  • Использование ресурсов относительно низкое - на каждом сервере свободно 14 ГБ памяти, и SQL не ограничен объемом используемой памяти.
  • Время доступа к диску в порядке - редко превышает 15 мс / чтение или запись
  • Базы данных не большие - 1 ГБ, 1,5 ГБ, 7,5 ГБ
  • Процесс SQL-сервера использует приватные байты 16 ГБ, рабочий набор 15 ГБ

В целом, никаких проблем с ресурсами не отмечено. Теперь о странной части. SQL не перезапускается (процесс работает почти 6 месяцев), но, похоже, что каждые ~ 50 дней счетчик ожидаемой продолжительности жизни падает до (почти) 0. До этого момента он постоянно поднимается, без падений. Вот график перф:

введите описание изображения здесь

Когда я смотрю на данные счетчика (у меня нет точного числа, только часовая агрегация), кажется, что значение счетчика PLE достигало примерно 4 295 000 с (примерно 50 дней) каждый раз (по крайней мере, каждый раз, когда у меня есть данные).

Моя сумасшедшая теория заключается в том, что число PLE содержится в миллисекундах как длинное целое без знака (с пределом 4 294 967 295) и через 49,71 дня оно сбрасывается либо по замыслу, либо из-за ошибки. Это объясняет поведение двух серверов и их идентичность. Или это может быть что-то совершенно другое, и я просто не вижу смысла. :)

Кто-нибудь видел что-нибудь подобное или может объяснить такое поведение?

PS Я видел этот пост, но мой случай кажется немного другим.

PPS Это репост - я изначально разместил его здесь , но мне посоветовали аудиторию здесь более подходящую.

Благодарность!


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Пол Уайт 9

Ответы:


3

Я видел такое поведение на клиентском сайте под управлением SQL2012 SP1. Особенностью здесь были NUMA и PLE, демонстрирующие «пилообразный» паттерн, но в часовом цикле.

Несколько потоков на SQLServerCentral обсуждались вокруг этого:

http://www.sqlservercentral.com/Forums/Topic1415833-2799-1.aspx http://www.sqlservercentral.com/Forums/Topic1424826-2799-1.aspx

конечный результат заключается в том, что применение SP1 CU4, похоже, решило проблему.

CU4 содержит исправление, которое выглядит невинно. Доступно обновление для управления памятью в SQL Server 2012 KB2845380

Стоит попробовать?


Спасибо за публикацию этого сообщения (извините за задержку с ответом, по какой-то причине я не получил уведомление о вашем сообщении). Я посмотрел на ссылки - они действительно выглядят примерно одинаково, поэтому я попытаюсь скопировать настройки в QA, применить CU4 (или, возможно, даже перейти прямо к SP2), а затем проверить еще раз. С темпом, который я вижу (каждые 50 дней), пройдет некоторое время, прежде чем я смогу подтвердить, но я отправлю ответ, когда у меня будут результаты. Кстати, мои паттерны остаются в силе - стабильный подъем в течение ~ 50 дней, затем резкое падение до ~ 0 и повторный подъем - всего 4 с момента запуска сервиса в декабре.
CRCerr0r

Обновление ... Я подтвердил это в нашей среде QA. Статистика, которую я получил оттуда: Общее количество дней между перезагрузками - 49,71 (+/- 1 минута); Достигнуто максимальное значение PLE - 4 294 961 (при 1-минутной выборке, поэтому оно могло быть немного выше). Это в значительной степени подтверждает производственные наблюдения. Я буду применять CU4 и сообщу через ~ 50 дней ... :)
CRCerr0r

1
Есть новости по этому поводу?
Майкл Грин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.