Плохая производительность, когда SQL Server использует 99% памяти
У меня есть сервер, который сообщает, что 8 ГБ оперативной памяти израсходованы на 99%. При перезапуске Sql Server он падает примерно до 5%, но постепенно восстанавливается до 99% примерно за 2 часа.
Когда я смотрю на процесс sqlserver, сообщается, что он использует только 100 КБ оперативной памяти и, как правило, никогда не поднимается или не ниже этого числа очень сильно. Фактически, если я сложу все процессы в моем TaskManager, он едва ли затронет мою общую доступную информацию (но TaskManager по-прежнему показывает использование памяти 99% со «Все процессы показаны»).
Похоже, что у Sql Server происходит огромная утечка памяти, но он не сообщает об этом. Сервер работал нормально почти два года, и это начало проявляться только в последние 3-4 недели.
Кто-нибудь видел это или имеет какое-либо представление о проблеме?
РЕДАКТИРОВАТЬ
Когда уровень сервера достигает 99%, производительность падает. Все запросы к серверу, приложениям и т. Д. Переходят в обход. Перезапуск службы снова делает работу быстрой, пока не пройдет 2 часа, и сервер снова не достигнет 99%.
SQL-сервер будет кэшировать столько данных, сколько сможет, что, как говорят другие, хорошо. Кэшируемые данные называются буферный кеш - но вам нужно ограничить это.
Итак, что вам нужно сделать, чтобы исправить это, это ограничить размер буферный кеш. Практическое правило: (Total_RAM - (2 ГБ или 10% (в зависимости от того, что больше)) = Максимальный буферный кеш. Если вы не ограничите размер этого кеша, сервер может начать испытывать нехватку памяти, когда ОС и SQL начинают соперничать для памяти. Этот параметр можно найти в разделе памяти свойств сервера SQL в Management Studio:
Посмотрите на лучшие практики памяти в Контрольный список развертывания SQL Server Брента Озара, часть ii для более подробной информации об этом.
Поскольку это начало происходить недавно, я предполагаю, что кто-то сделал что-то, чтобы создать конкуренцию памяти с сервером SQL, установив или запустив другое программное обеспечение.
Наконец, если вы хотите узнать, сколько памяти SQL-сервер фактически использует для пула буферов, посмотрите на SQL Server Memory Manager: Total Server Memory счетчик perfmon. Это объем памяти, который использует буферный пул (а не общая память сервера). Таскман не показывает это воспоминание.
Причина, по которой он не отображается в диспетчере задач, заключается в использовании AWE, который блокирует и выделяет страницы в памяти. Это делает важным установить максимальный объем памяти сервера, поскольку память не выгружается. http://blogs.msdn.com/b/psssql/archive/2009/09/11/fun-with-locked-pages-awe-task-manager-and-the-working-set.aspx
Это не утечка; Это SQL должен работать. Он захватывает всю оперативную память, которую может. SQL - это то, что определенно должно быть единственным приложением в коробке, в том числе по этой причине. Если вам действительно нужно было его ограничить, я верю, что вы можете это сделать, но небеса помогут вам, если SQL когда-либо понадобится больше ОЗУ, чем вы установили его предел.
Да, скорее всего, это SQL, и что-то могло измениться в ваших шаблонах использования из-за подключений SQL. Я считаю, что SQL начинает кэширование данных SQL в ОЗУ только тогда, когда эти данные запрашиваются, так что, возможно, в последнее время у вас появилось больше запросов. Если у вас плохая производительность SQL, я бы предположил, что он делает то, что должен.
Я не уверен, почему это поведение изменилось за последние несколько недель, но похоже, что SQL Server ведет себя так, как задумано. Обычно он удерживает столько памяти, сколько разрешено, до максимального предела памяти сервера, отказываясь от нее только в том случае, если какой-либо другой процесс действительно это нужно. Точка, в которой ты думаю, что SQL должен освободить оперативную память и время, когда SQL считает, что следует отказаться от ОЗУ, очевидно, не синхронизированы. Это нормально и не является чем-то необычным, поэтому есть средства управления, чтобы вы могли это прояснить. Установите параметр максимальной памяти сервера, чтобы позволить ОС и фоновым приложениям немного ОЗУ, и все будет в порядке.
Вот проницательный пост, который поможет вам понять - http://sqlblog.com/blogs/jonathan_kehayias/archive/2009/08/24/troubleshooting-the-sql-server-memory-leak-or-understanding-sql-server-memory-usage.aspx
Кроме того, посмотрите номер 3 на этой странице, чтобы понять, почему Диспетчер задач - неподходящий инструмент для проверки использования памяти x64 SQL Server - http://blogs.msdn.com/b/psssql/archive/2009/09/11/fun-with-locked-pages-awe-task-manager-and-the-working-set.aspx