Почему периодические перезапуски необходимы для поддержания хорошей работы моего экземпляра?

У нас есть рабочий сервер БД на SQL 2005. Некоторое время все работает нормально, но через пару недель мы видим заметное падение производительности. Только перезапуск SQL Server возвращает производительность к норме.

Немного предыстории:

• Работает более 1200 баз данных (в основном один арендатор, несколько мультитенант). Прежде чем кто-либо читает лекции о переходе только на мультитенанта, есть веские причины для сохранения этой структуры ......
• Объем оперативной памяти составляет 16 ГБ. После перезапуска SQL Server не займет много времени, чтобы вернуться к использованию 15 ГБ.
• Количество активных соединений с БД составляет около 80 соединений - что, по нашему мнению, является вполне приемлемым, учитывая, что на каждый веб-сервер приходится один пул соединений, поэтому у нас нет проблем с утечкой соединения.

Мы попробовали несколько вещей в непиковое время: - Запустите DBCC DROPCLEANBUFFERS (с CHECKPOINT), чтобы очистить кеш данных. Это не имеет никакого эффекта и не очищает использование ОЗУ). - Запустите FREEPROCCACHE и FREESYSTEMCACHE, чтобы очистить планы запросов и сохраненный кэш процедур. Нет эффекта.

Очевидно, что перезапуск SQL Server не идеален в активной производственной среде. Мы что-то упустили. Кто-нибудь еще проходит через это?

ОБНОВЛЕНИЕ: апрель-28-2012 Все еще борется с этой проблемой. Я уменьшил объем памяти для SQL Server до 10 ГБ, просто чтобы исключить конфликты с ОС. Я становлюсь ближе к сужению, но мне нужна помощь с моего следующего шага.

Вот что я нашел после перезапуска SQL Server, файл подкачки колеблется между 12,3 ГБ и 12,5 ГБ. Это останется таким в течение многих дней. Общее количество потоков сервера будет зависать между 850 и 930 - также стабильно и согласованно в течение нескольких дней подряд (sqlserver стабильно составляет от 55 до 85 из них в зависимости от трафика).

Затем есть «событие». Я понятия не имею, что это за событие, я не вижу его в журналах, и я не вижу ничего непротиворечивого в день недели или время, когда это происходит, но весь suddent он переходит на файл 14.1 или 14.2. ГБ, и потоки переходят между 1750 и 1785.

Проверяя производительность, когда это происходит, более 900 из этих потоков являются sqlserver. Поэтому я перехожу к sp_who2, чтобы увидеть, откуда берутся эти потоки ... и есть только используемые 80 или около того соединений db.

Итак .... у кого-нибудь есть идеи, как определить местонахождение остальных 900 потоков на сервере SQL и что они делают?

ОБНОВЛЕНИЕ: июнь-01-2012 Все еще борется с проблемой. Для тех, кто читает это все еще, проблема с подпрыгивающими нитями была решена. Это было вызвано автоматическим программным обеспечением для резервного копирования ComVault. Он создавал поток, пытаясь создать резервную копию баз данных, которых больше не было (он поддерживал список предыдущих баз данных), а не просто создавал резервные копии текущих баз данных.

Но проблема остается, и мы должны перезагружать каждую неделю, давать или брать несколько дней. Работаем с командой Rackspace, чтобы узнать, смогут ли они пролить свет.

Вы говорите, что все хорошо, а потом через пару недель производительность падает. (Обычно люди утверждают, что производительность падает быстро, либо в определенное время, либо с, казалось бы, случайными интервалами. Это может означать плохую производительность ввода-вывода или штормы блокировки или интенсивные запросы процессора, выполняемые в странное время, или тяжелое запланированное задание или отсутствие индексация или плохая статистика, приводящая к интенсивным процессорным запросам, чтению с диска или другим вещам.) Недели необычны.

Моя гипотеза состоит в том, что другое приложение на вашем сервере теряет память. Я видел это с вирусным программным обеспечением (любимым злоумышленником для каждого администратора БД) и сторонним программным обеспечением. Со временем я бы дважды проверил использование памяти SQL Server, а также взял бы все использование памяти другими приложениями на коробке. Если у вас установлены жесткие ограничения на использование памяти SQL Server и он запрещает подкачку страниц, это могут быть другие приложения, которые выгружаются из памяти и расходуют ресурсы ввода-вывода.

Это не сложно искать. Если вы еще не храните метрики на сервере, я бы просто запустил Perfmon и брал образец каждые 30 или 60 минут. Через несколько дней вы можете заметить, что использование памяти другими приложениями увеличивается.

Есть ли сообщения об ошибках в журнале SQL Server о том, что «значительная часть сервера sql была выгружена»? Это также будет большой подсказкой.

Позвольте мне поздравить вас с возможностью запустить 1200 БД на одном экземпляре SQL-сервера с 16 ГБ ОЗУ и иметь проблемы такого типа после нескольких недель бесперебойной работы. Хорошая история, чтобы рассказать в местной главе PASS.

Теперь для устранения неполадок: ваша оперативная память составляет 16 ГБ для SQL и ОС. Я предполагаю, что ваш максимальный объем памяти составляет 15 ГБ или макс. Это может привести к тому, что буферный пул израсходует всю память и захлебнется ОС. Вы говорите, что очистка пула буферов и кэшей не показывает каких-либо различий, плюс ваш PLE выше 300. Это свидетельствует о недостатках памяти. Как процессор и IO на сервере (спецификации / статистика)?

Запустите select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidи какие ресурсы вы видите (wait_type, wait_time, last_wait_type, wait_resource).

1200 баз данных, операционная система и, возможно, другие вещи? Да, я думаю, что самому серверу для работы потребуется более 1 ГБ оперативной памяти, особенно если учесть, что если вы установите 15 ГБ в качестве параметра максимальной памяти SQL Server, ему все равно потребуется дополнительная память за пределами этих 15 ГБ для потоков.

Я бы снизил SQL Server до 14 ГБ, чтобы дать серверу немного больше передышки.

Кроме того, пример, приведенный в разделе «Внутренние компоненты и устранение неполадок в Профессиональном SQL Server 2008», посвященный допускам памяти в системе SQL Server 2008 x64 с утилитой резервного копирования третьей части с 16 ГБ ОЗУ:

• 2 ГБ для Windows
• 1 ГБ для рабочих потоков
• 1 ГБ для MPA и т. Д.
• 1 ГБ для программы резервного копирования
• 11 ГБ для SQL Server

В книге показано, как определить максимальное количество потоков, которое вы можете иметь, и как рассчитать, сколько памяти они будут занимать. Запустите это (измените тип сервера в соответствии с вашим сервером), чтобы выяснить, сколько памяти понадобится вашим потокам.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Если память базы данных равномерно распределена по всем базам данных, у вас есть только 12,8 мегабайта для каждой базы данных (15 * 1024) /1200=12,8. Вам нужно больше памяти.

Вам необходимо выяснить, почему производительность снижается. Вы видите блокировку, блокировку и т. Д.? Как выглядит статистика ожидания?

Команды DBCC только собираются очистить буферы памяти, которые они не собираются освобождать память назад к ОС.

Знаете ли вы, что SQL Server фактически потребляет память? Я бы посоветовал посмотреть на настройку сеанса Perfmon или начать собирать информацию о DMV после перезапуска, чтобы узнать, что SQL Server делает и работает. Также обратите внимание, что пользователи выполняют больше работы, чем обычно, во время сбора данных (например, обработка в конце месяца и т. Д.). Работаете ли вы SSRS, SSIS или SSAS на одном сервере?

В вашей системе 1200 баз данных, какая у вас база данных самого большого размера?