Я заметил странное поведение в кластере высокой доступности с двумя серверами, и я надеялся, что кто-то может подтвердить мое подозрение или, возможно, предложить какое-то другое объяснение ... Вот мои настройки:
- Установка 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 Это репост - я изначально разместил его здесь , но мне посоветовали аудиторию здесь более подходящую.
Благодарность!
Ответы:
Я видел такое поведение на клиентском сайте под управлением 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
Стоит попробовать?
источник