SQL Server полностью замедляется после заполнения полной памяти

На нашем сервере с 32 ГБ оперативной памяти у нас есть экземпляр SQL Server, который ограничен максимальной памятью на 80%.

Все работает нормально, когда использование памяти невелико. См. Снимок экрана ниже.

Но со временем, через 3-4 дня, SQL будет использовать полную RAM (80% от общего числа).

В течение этих 3-4 дней мы не делаем никаких изменений на сервере, но с каждым днем он продолжает потреблять больше ОЗУ.

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

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

Это будет работать в течение недели или около того, после чего мы должны снова перезапустить его

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

Есть ли утечка памяти? Или хранимая процедура, потребляющая много памяти и никогда не выпускающая ее? Если да, то как его отладить?

Ответ 1

По умолчанию SQL-сервер потребляет всю память, если она не используется, и использует всю доступную память, если она ограничена. Это нормальная. Также вам необходимо обеспечить, чтобы SQLSERVER был единственным приложением в поле (которое рекомендуется) и также пытаются ограничить память в соответствии с лучшими методами.

Я бы начал устранение неполадок с использованием подхода ниже

1.start найти верхнюю память, потребляющую запросы, и посмотреть, могу ли я уменьшить использование памяти в запросе. Возможные потребительские запросы могут быть найдены в следующем запросе.

SELECT TOP 10 SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC -- logical reads
-- ORDER BY qs.total_logical_writes DESC -- logical writes
-- ORDER BY qs.total_worker_time DESC -- CPU time

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

EX: запрос может выполнять много чтений из-за неподходящего индекса или может быть у вашего устройства ввода-вывода проблема, из-за которой пул буферов многократно очищается

2.Вы можете также найти верхние компоненты, которые используют память, что дает вам представление о том, как RAM расходуется

SELECT TOP(20) [type], [name], SUM(single_pages_kb) AS [SPA Mem, Kb] 
FROM sys.dm_os_memory_clerks 
GROUP BY [type], [name]  
ORDER BY SUM(single_pages_kb) DESC;

Если буферный пул использует больше памяти последовательно, я бы об этом не беспокоился, но если это cachestore_obcp.then, у вас может быть много специальных запросов, заполняющих кеш-память, которая плохая

Одна часть исследования ведет к другой, поэтому вам придется устранять неполадки, основанные на выводах, поскольку нет решения для кликов

Боковое примечание: не рекомендуется:
один из наших экземпляров dev использовался для решения одной и той же проблемы, поэтому вместо того, чтобы выполнять все настройки, мы использовали команду ниже, которая эффективно освобождает память сразу... но это совсем не рекомендуется для производственного экземпляра, так как это очищает планы хранятся в кеше, и вы можете столкнуться с небольшим давлением процессора.

DBCC FREEPROCCACHE WITH NO_INFOMSGS;

Ссылки:

Ответ 2

Вам нужно найти наиболее дорогие запросы и просмотреть код запроса, много раз код запроса не оптимизирован эффективно. Настройка производительности вам нужно сделать.