MS SQL Server замедляется со временем?

Кто-нибудь из вас испытал следующее, и вы нашли решение:

Большая часть серверной части нашего веб-сайта - это MS SQL Server 2005. Каждую неделю или две недели сайт начинает работать медленнее - и я вижу, что запросы в SQL все дольше и дольше выполняются. У меня есть запрос, который мне нравится использовать:

USE master
select text,wait_time,blocking_session_id AS "Block",
percent_complete, * from sys.dm_exec_requests 
CROSS APPLY sys.dm_exec_sql_text(sql_handle)  AS s2 order by start_time asc

Что довольно полезно ... он дает снимок всего, что работает в тот момент на вашем сервере SQL. Приятно, что даже если ваш процессор по какой-то причине привязан к 100%, а Activity Monitor отказывается загружаться (я уверен, что некоторые из вас были там), этот запрос все равно возвращается, и вы можете видеть, какой запрос убивает вашу БД.

Когда я запускаю это или Activity Monitor во время, когда SQL начал замедляться, я не вижу каких-либо конкретных запросов, вызывающих проблему - они ВСЕ работают медленнее по всем направлениям. Если я перезапущу службу MS SQL, то все в порядке, она ускоряется - в течение недели или двух, пока не произойдет снова.

Ничего из того, что я могу придумать, не изменилось, но это началось всего несколько месяцев назад ... Идеи?

--Added

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

Что касается вставки результатов запроса, который я вставил выше, я действительно не могу этого сделать. В приведенном выше запросе перечислены логин пользователя, выполняющего задачу, весь запрос и т. Д., И т. Д., И я бы не хотел раздавать имена моих баз данных, таблиц, столбцов и логинов онлайн:) ... I могу сказать вам, что запросы, выполняемые в то время, являются нормальными, стандартные запросы для нашего сайта, которые выполняются постоянно, ничего сверх нормы.

- 24 марта

Прошло около двух недель с момента последней перезагрузки. Я сделал несколько изменений: я нашел несколько запросов, в которых мы интенсивно использовали временные таблицы, которые были совершенно ненужными, и наши разработчики изменили то, как они это делают. Я изменил размер некоторых постоянно (медленно, но верно) растущих баз данных до разумного размера для их роста. Я настроил параметры автоматического роста для всего, чтобы быть более интеллектуальным (они были ВСЕ установлены на рост 1 МБ). Наконец, я немного почистил MSDB. Мы занимаемся доставкой журналов и на самом деле не нужно хранить годы и годы резервных копий, я написал несколько сценариев, которые держат это всего несколько месяцев. Я буду постоянно обновлять эту ветку, так как пока рано говорить, решена ли проблема.

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

Вы должны спросить себя, что происходит при перезапуске службы SQL? Много вещей, но на ум приходят два важных момента:

1) память SQL освобождается

Его можно (не уверен , насколько вероятно), что если ваш MaxMemory установка слишком высока, что служба SQL растет использовать всю доступную память, и Windows , начинает своп важные вещи, чтобы файл подкачки. Убедитесь, что для MaxMemory задано разумное значение, оставляя достаточно дополнительной памяти для того, что еще нужно запустить на этом компьютере (это выделенный сервер SQL? Или это также сервер приложений?)

2) TempDB перестраивается из размеров по умолчанию.

Проверьте размеры файла tempdb по умолчанию, особенно размер по умолчанию и интервал роста файла журнала TempDB. Если интервал роста установлен слишком низким, тогда журнал может создать невероятную внутреннюю фрагментацию, которая может значительно замедлить нормальное использование. Посмотрите эти две отличные статьи в блоге Кимберли Трипп.

Вы интенсивно используете временные таблицы или курсоры? Убедитесь, что все курсоры закрываются и освобождаются правильно. Также следите за связанными серверами - мы должны использовать драйвер с ошибками для старого связанного сервера Informix, и это периодически означает, что мы должны перезагрузить сервер.

Если это выглядит странно, тогда ищи странное.

Если настройка параметров сервера sql не помогает, попробуйте диспетчер задач Windows: перейдите на вкладку «Процессы», затем выберите «Параметры»> «Столбцы»> «Добавить время процессора», «Обрабатывать», «Чтение», «Запись», «Другое» и параметры памяти.

Вернитесь к списку процессов. Для каждого столбца сортируйте по возрастанию и убыванию и посмотрите на 5 лучших процессов. Что-нибудь необычное? Например, утечка памяти в процессе будет иметь странное количество дескрипторов. У нас есть некоторые * ki принтеры, которые добавляют дескриптор процесса DCSLoader каждые 2 секунды. Через несколько недель машина перечисляет много свободной памяти и процессора, но процесс с 100 000 дескрипторов и едва перемещает указатель мыши.

Проверьте свой список запланированных задач тоже. Скажите своему AV, чтобы не сканировать файлы .mdf.

Дэйв,

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

Если ваша резервная копия «Модель восстановления» является ПОЛНОЙ, то улучшит ли вообще создание резервной копии БД, а затем резервную копию журналов транзакций? В системе, где не хватает места на диске, подобные вещи могут объяснить проблему.

Кажется, у меня конфигурация очень похожа на вашу (16 ГБ, обновленная до 32 ГБ, и MD1000 с терабайтом дисков, двойной четырехъядерный Xeon).

Единственная вещь, которая помогла мне диагностировать причудливые проблемы в прошлом, это beta_lockinfo от Erland Sommarskog. Запустите его, когда будет медленное время, и сравните.

Также у меня было безумное количество проблем с SQL 2005 до SP2, но SP3 действительно стабильный.

Надеюсь, что это дает более полезную информацию:

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

Убедитесь, что с БД все в порядке:

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

Следите за журналом с:

DBCC SQLPERF(LOGSPACE)

Если вы видите, что расширение продолжается, это определенно замедлит процесс. Если вы запустите это, вы увидите, что ваше пространство журналов становится все ближе и ближе к 100%, тогда журнал будет расширяться, и процент будет уменьшаться, так как у него есть некоторое пространство. Надеюсь, вам никогда не удастся увидеть его расширение до того, как ваша резервная копия сработает и очистит журнал.

В основном идиотская конфигурация. Случается.

• Во-первых, вы должны регулярно запускать дефрагментацию индекса в цикле обслуживания. Запланируйте это как мероприятие, непосредственно перед или после создания резервных копий.

• Во-вторых, не наращивайте базу данных автоматически и особенно не уменьшайте ее автоматически. В зависимости от нагрузки autogrow / autoshrink в основном настройки самоубийства.

Не видел такого замедляющегося SQL Server, как раньше. Можете ли вы опубликовать результаты этого запроса в период стресса? Уверены, что с вашей стороны перегрузит SQL Server в то время?