Mssql не потребляет память

Обновлено: 06.07.2024

У меня SQL Server 2014 с максимальной памятью 6 ГБ (физическая память 8 ГБ).

Сервер памяти Target иногда 6GB , а затем падает обратно Общий сервер памяти (приблизительно 5.3GB, никогда не достигает 6GB). Я использовал committed_kb в sys.dm_os_sys_info , чтобы проверить память , используемую SQL Server.

Когда я наблюдаю за sys.dm_os_buffer_descriptors , я вижу, что страницы удаляются из кэша - но все еще остается 700 МБ памяти. Если бы ничто не требовало памяти, как бы вы объяснили тот факт, что страницы удаляются из кэша? Я ожидаю, что SQL Server удаляет страницы только тогда, когда ему нужна память.

Нераспределенные временные таблицы не являются проблемой на этом сервере. Мой PLE - 3632. Кэш процедуры - 2182 МБ.

Я ожидал бы, что страницы будут отбрасываться только тогда, когда не останется памяти, но у меня свободно 700 МБ, или я неправильно понял это?

Может кто-нибудь, пожалуйста, попытайтесь объяснить это поведение?

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

Я провел еще несколько исследований и прочитал огромное количество страниц с диска в память и заметил что-то в диспетчере задач во время чтения:

  • Объем используемой памяти составлял 7,0 ГБ -> 7,2 ГБ -> 7,0 ГБ -> 7,2 ГБ -> .
  • Sqlservr.exe вышел из 5,3 ГБ -> 5,5 ГБ -> 5,3 ГБ -> 5,5 ГБ -> .

Это так же, как Windows не позволяет sqlservr.exe расти до 6 ГБ.

Я выполнил запрос, предоставленный Shanky:

Это дало следующий результат:

Я не понимаю, почему Total_Memory_in_MB не равно 6144 (максимальный объем памяти)?

В sys.dm_os_ring_buffers я обнаружил RESOURCE_MEMPHYSICAL_LOW , так что я думаю, что Windows не хватает памяти и SQL Server должен вернуть некоторые. Но доступно около 1 ГБ памяти => почему Windows сообщает, что у нее мало памяти?

Обновление
После еще одного исследования, почему всегда было доступно 1 ГБ памяти, я думаю, что-то нашел.
Возможно ли, что SQL Server может выделять только свободную память, а доступная память игнорируется? При запуске Process Explorer (Sysinternals) я увидел, что свободной памяти было 0.

Для начала я должен сказать, что вы установили максимальный объем памяти сервера в 6 ГБ, а общий объем памяти - 8 ГБ, поэтому вы просто оставили 2 ГБ для ОС, что во многих случаях, даже если на компьютере с Windows ничего не установлено, кроме SQL Server слишком мало памяти для ОС. Для правильной работы в системе с установленным антивирусом ОС должно быть выделено не менее 4 ГБ. Я сразу оставляю 2 ГБ для ОС и 1,5 Г для AV.

Память целевого сервера иногда составляет 6 ГБ, а затем возвращается к общей памяти сервера (около 5,3 ГБ, никогда не достигает 6 ГБ).

Память целевого сервера показывает, сколько памяти требуется SQL Server для правильной работы в идеальном случае. Объем памяти целевого сервера составляет 6 ГБ, поскольку вы установили максимальное значение памяти сервера на 6 ГБ. Он пытается использовать всю память, которой ему позволено.

Общий объем памяти сервера - это то, что SQL Server действительно может использовать прямо сейчас. Это выделенная память и подкрепленная физическим ОЗУ. Это максимум 5,5 ГБ в вашем случае.

SQL Server пытается увеличить потребление памяти, но после того, как он достигнет 5,3 или 5,5 ГБ, операционная система просит SQL Server не увеличивать потребление памяти и может фактически отмечать уведомление о нехватке памяти. Это происходит потому, что ОС может столкнуться с нехваткой памяти, как уже было сказано выше. SQLOS отвечает, если операционная система Windows сталкивается с нехваткой памяти, запрашивая свои кеши для сокращения их потребления. Вы можете запросить кольцевой буфер, чтобы проверить, не было ли уведомлено о нехватке памяти. Я должен добавить DMV sys.dm_os_ring_buffer без документов, но безопасно.

Я вижу, что страницы удаляются из кеша, но остается еще 700 МБ памяти. Если бы ничто не требовало памяти, как бы вы объяснили тот факт, что страницы удаляются из кэша? Я ожидаю, что SQL Server удаляет страницы только тогда, когда ему нужна память.

Если вы ищете свободную память, я бы не советовал вам просматривать DMV sys.dm_os_buffer_descriptors . Счетчик ОС Available Mbytes покажет вам количество физической памяти в байтах, доступной для процессов , запущенных на компьютере. Я предлагаю вам также посмотреть, что является детерминированным методом для оценки разумного размера пула буферов? а также прочитайте: Нужно ли SQL Server больше оперативной памяти, чтобы узнать, сколько оперативной памяти нужно SQL Server и сталкивается ли SQL Server с нехваткой памяти. Из того, что вы упомянули, если вы уверены, что страницы удаляются из пула буферов, то да, SQL Server чувствует, что страницы должны быть перемещены, потому что ему нужно место для размещения новых страниц. Я не уверен, как вы рассчитали 700 МБ бесплатно.

Еще одна вещь, пожалуйста, не смотрите в диспетчере задач для потребления памяти SQL Server. Это не всегда дает правильное значение, особенно когда учетная запись службы SQL Server имеет права на блокировку страниц в памяти . В вашем случае, даже если SQL Server имеет максимальный объем памяти сервера 6 ГБ, ОС выделяется всего 2 ГБ, что заставляет SQL Server не увеличивать потребление, поскольку для SQL Server 2 ГБ мало. Есть ли что-нибудь кроме SQL Server, работающего в системе?

Если вы хотите рассчитать потребление памяти SQL Server, используйте:

Я не понимаю, почему Total_Memory_in_MB не равно 6144 (максимальный объем памяти).

Столбец Total_Memory_in_MB обозначает общий объем памяти, используемый SQL Server (RAM + файл подкачки). ОЗУ - это фактически используемая физическая память или выделенная память. Некоторая часть процесса SQL Server также выгружается на диск и представляет собой виртуальную память или файл подкачки, поэтому, если вы увидите, что ОБЩАЯ память используется SQL Server, это будет сумма физической памяти и файла подкачки.

В то время как столбец Physical_Memory_usedby_Sqlserver_MB - это просто используемая физическая память (память, поддерживаемая физической или фиксированной памятью). Это причина, почему оба они разные. Если вы видите реальный столбец, то сначала используется физическая память, а другой - выделенная виртуальная память.

Если вы хотите увидеть выгружаемую память, это будет разница между Total_Memory_in_MB и Physical_Memory_usedby_Sqlserver_MB .

ПРИМЕЧАНИЕ. Общая используемая память будет больше, чем используемая физическая память.

Добрый день.
Есть физический сервер на котором поднят VMWARE. там поднята виртуальная машина на которой стоит сервер 1с и sql server.
Проблема в том что сервер sql не хочет потреблять озу. Тоесть он как при запуске системы выделил себе 105 мб (для MS SQL 2008 ) или 75мб (SQL 2012) так и крутиться на этой памяти. Потребления ресурсов почти нет (незначительный прирост в потребление ОЗУ +1-2 %).Кто нибудь сталкивался с таким ? Поиски ни к чему не привели , обычно у людей проблема обратного характера =).

Мешает это тем что работает очень медленно. Проверяли средствали Винды и средствами VMWARE. 1с работает жутко медленно Гилев выдает 10 балов при отличном железе. Плюс на другой ВМ на другом физическом сервере все ровно. Тоесть sql сервер нармально потребляет ОЗУ (5-7 гб) при выгрузке ДТ.

Да конечно.
Даже при установке значения допустим 8гб в параметре минимальное количество памяти ОЗУ в свойствах сервера. Сервер продолжает работать на примерно 100 мб.

(5) Попробуйте еще посмотреть значения в мониторе ресурсов. Есть подозрение что диспетчер задач показывает вам кол-во памяти используемое для блокировок.

еще выполните в menegment studio
DBCC MEMORYSTATUS
и смотрите информацию в разделе memory manager

Всем спасибо. Решили проблему отключением энергосбережения в биосе.

(10) разобрался.. было включено "Блокировка страниц в памяти" в групповой политике. Из за этого в диспетчере задач отображалась некорректная информация.

разобрался.. было включено "Блокировка страниц в памяти" в групповой политике. Из за этого в диспетчере задач отображалась некорректная информация.

Добрый день!
Нарвался на аналогичную фигню.
2 новых виртуальных машины, идентичные конфигурации, но в одной SQL работает как надо, а во второй ест 100МБ и не больше не хочет.
Решается отключением для учетной записи из под которой работает процесс SQL параметра "Блокировка страниц в памяти", о чем написано выше.

SQL кушает 140М
Ограничение на память SQL не стоит, свободная память есть.

Почему так мало кушает SQL? Я привык что он выедает всю свободную память.

Никакими большими запросами раскочегарить SQL не удается.

(1)У меня есть опасение, что она мало кеширует и часто читает с винта
2(5) система - 64 битная, скл ервер - тоже 64 битный.
продолжай
(7) в следующий раз будь внимательней. мы следим за тобой.
:)

(0) 9 к 10 что смотришь не там.

если смотришь сколько жрет СКЛ в диспетчере задач, то ты ламер

(11) - Максимальный, тобишь не ограничено
(10)НА предыдущих серваках в диспетчере кушалось до 10Г на подобных конфигурациях, еще и ограничивать приходилось
в диспетчере задач отображается корявая инфа. смотрите системный монитор. все в порядке у вас.
в смысле если задача занимает больше 2х гигов, то диспетчер задач тупит.
скока общий объем памяти занят?
(18) процесс эксплорер - таже самая хрень что и диспетчер задач. тянут инфу из одного же места.
смотрите системный монитор или монитор производительности он там называется.

Смотреть на sqlservr.exe, колонка Working set

(19)врядле microsoft закрыл глаза н корявость данных в x64, думаю причина в другом
(23) вы хоть пробовали запустить то монитор производительности?
(21) по колонке виртуал вроде в обоих случаях отображается больше, чем 140 метров.
ну виртуальные - это значит и своп.. а рабочий набор - в физ.ю памяти
(24)Запустил, свободно 7 гиг. Какой показатель в нем Вы предлагаете посмотреть?
(25)Виртуал это не физическая (вернее не только физическая)
(27) так вы запустите свой процесс инфо для физ памяти и для не своего сервера тоже. скока покажет?
а какой смотрели?
(26) спасибо за науку, не знал прямо. ага
автор виртуальную память не своего сервера сравнивает с рабочей памятью своего сервера. как думаете - правильное сравнение?
тэкс колонки пропустил Working set в одном случае. может хотфикса для сервера не хватает. сервер который не ваш - там операционка какая?
(29)Автор в обоих случаях сравнивает колонку Working set, которая есть в обоих картинках, но последовательность колонок разная
(28)Второй сервер не доступен, картинка с прошлого места работы.
Смотрел Memory/Available MBytes

(33) это счетчик системы, а не скуля. смотреть нужно закладку SQL Server:Memory
там счетчик Target Server Memory

(34)таргет показывает 13Г, свободной физической щас 1,2Г
Ссылку сейчас почитаю, спасибо

Смущает описание:
Target Server Memory (KB)
Общий объем динамической памяти, которую МОЖЕТ использовать сервер.

А вот
SQL Cache Memory (KB)
Общий объем динамической памяти, которую ИСПОЛЬЗУЕТ сервер для динамического кэша SQL.
А тут 93M

огда как же обнаружить проблемы с памятью? Можно начать с просмотра счетчиков Performance Monitor (PerfMon): SQL Server:Memory Manager:Target Server Memory и SQL Server:Memory Manager:Total Server Memory. Счетчик Total Server Memory покажет, сколько памяти использует SQL Server. Если в течение некоторого времени Total Server Memory однозначно ниже, чем значение Target Server Memory, значит, в системе нет проблем с памятью. SQL Server не занимает больше памяти, чем он использует. Тем не менее, если величина Total Server Memory равна или превышает Target Server Memory, недостаток памяти может вызвать проблемы.

Есть много неправильных представлений о SQL с использованием памяти (RAM) на физическом сервере. Самое частое, что можно услышать, - это то, что пользователь беспокоится о том, что ОЗУ сервера будет максимально заполнено. SQL Server предназначен для использования как можно большего объема памяти. Единственным ограничением является количество памяти, на которое установлен экземпляр (Максимальная память), и объем оперативной памяти на сервере.

Например, представьте, что ваш сервер SQL работает оптимально, только с 8 ГБ памяти, а сервер показывает

95% от общего объема используемой оперативной памяти. Вы можете удвоить ОЗУ на машине, удвоить настройку Max Memory экземпляра SQL, а затем наблюдать, как сервер медленно поднимается до 95%. Это не обязательно проблема. SQL просто кэширует столько временных данных, сколько может с тем, что ему дано.

Ниже приведены наши краткие сведения о том, есть ли на самом деле проблема с памятью или SQL Server просто выполняет то, что предполагается сделать:

  1. Проверьте параметр Max Memory в свойствах экземпляра и сравните его с общей памятью сервера. SQL нужно давать как можно больше, но каждая среда отличается. Есть также много факторов, которые необходимо учитывать (количество экземпляров, приложений, нагрузка, состояние кластера и т. д.). По крайней мере, убедитесь, что для операционной системы осталось несколько ГБ. Кроме того, убедитесь, что все остальное, что для этого нужно, на этой машине.
  2. Если максимальная память установлена на 2147483647, измените ее прямо сейчас. Это значение по умолчанию, с которым устанавливается SQL, и говорит о необходимости использовать столько, сколько ему нужно. Это может вызвать проблемы с производительностью для ОС и других приложений на сервере и замедлить все, если это когда-либо будет узким местом.


  1. Запустите встроенный отчет о потреблении памяти из свойств экземпляра. Полезные детали для немедленного поиска - это высокое значение PLE и низкое значение ожидающих предоставления памяти. Page Life Expectancy - это количество секунд, в течение которых страница будет оставаться в пуле буферов, прежде чем ее можно будет «повторно использовать» на сервере. Общая рекомендация - иметь 300 секунд или больше, но эта рекомендация экспоненциально увеличивается, когда на сервере больше оперативной памяти. Memory Grants Pending - это число процессов, ожидающих предоставления памяти рабочей области. Ноль - это лучшее значение, поскольку оно означает, что все, что работает, может сделать это с достаточным объемом памяти, который ему необходим.



  1. Запустите приведенный ниже запрос, чтобы проверить текущие счетчики памяти. Третий набор результатов покажет временную метку, когда произошло изменение памяти. Следите за любыми «низкими» предупреждениями о памяти и с этого момента определяйте, следует ли дополнительно исследовать нагрузку на память, если SQL использует соответствующее количество.

SELECT @@SERVERNAME AS [Server Name]

,total_physical_memory_kb / 1024 AS [Total Physical Memory (MB)]

,available_physical_memory_kb / 1024 AS [Available Physical Memory (MB)]

,total_page_file_kb / 1024 AS [Total Page File Memory (MB)]

,available_page_file_kb / 1024 AS [Available Page File Memory (MB)]

,system_memory_state_desc AS [Available Physical Memory]

,CURRENT_TIMESTAMP AS [Current Date Time]

SELECT physical_memory_in_use_kb / 1024 AS [Physical Memory In Use (MB)]

,locked_page_allocations_kb / 1024 AS [Locked Page In Memory Allocations (MB)]

,memory_utilization_percentage AS [Memory Utilization Percentage]

,available_commit_limit_kb / 1024 AS [Available Commit Limit (MB)]

,CASE WHEN process_physical_memory_low = 0 THEN 'No Memory Pressure Detected' ELSE 'Memory Low' END AS 'Process Physical Memory'

,CASE WHEN process_virtual_memory_low = 0 THEN 'No Memory Pressure Detected' ELSE 'Memory Low' END AS 'Process Virtual Memory'

Читайте также: