Максимальна пам'ять SQL Server, що не обмежує використання оперативної пам'яті


18

Я хотів би, щоб ваш внесок з цього приводу був. У мене є сервер sql 2008r2 Ent. Ред. 64-бітний з 16 ядрами і 64 ГБ оперативної пам’яті. Є один екземпляр сервера SQL, повністю зафіксований станом на 20111014.

Максимальний таран встановлений у 60000MB. Кількість безкоштовних операційних балів становить 0, за словами менеджера завдань через кілька днів в Інтернеті.

Якщо я поміняю максимальний баран на менше 53 ГБ, він через кілька днів стабілізується і матиме кілька безкоштовних операційних карт.

Саме sql процес розподіляє баран згідно менеджеру завдань. Як я змирився з тим, що насправді проблема? Само собою зрозуміло, що я вже багато тестував, але ще не вирішив це на свій смак. і о, у нас не спостерігається відставання типового голодування пам’яті, коли наявний баран знижується до 0 безкоштовно.

Оновлення 1:

Натхненний іншим запитанням, пов'язаним з оперативною пам’яттю на цій сторінці /dba//a/7062/2744 . Я використав ці два, щоб побачити, для чого використовується оперативна пам'ять.

SELECT TOP ( 10 )
        [type] AS [Memory Clerk Type] ,
        SUM(single_pages_kb) AS [SPA Mem, Kb]
FROM    sys.dm_os_memory_clerks
GROUP BY [type]
ORDER BY SUM(single_pages_kb) DESC
OPTION  ( RECOMPILE ) ;

SELECT  DB_NAME(database_id) AS [Database Name] ,
        COUNT(*) * 8 / 1024.0 AS [Cached Size (MB)]
FROM    sys.dm_os_buffer_descriptors
--WHERE   database_id > 4 -- system databases
--        AND database_id <> 32767 -- ResourceDB
GROUP BY DB_NAME(database_id)
ORDER BY [Cached Size (MB)] DESC
OPTION  ( RECOMPILE ) ;

Використовувана ними сума - це виберіть спочатку 7948432 Kb другий 44030,57812 Мб, що в цілому близько 52 ГБ, що використовується сервером sql ... так куди пішла решта моєї оперативної пам’яті? :-) Диспетчер завдань показує зараз кешований 363, доступний 401, вільний 40 і sqlservr.exe має приватний набір пам'яті 64 459 656. Max Ram встановлений на 60000MB, як і раніше.

Відповіді:


20

Налаштування максимальної пам’яті серверів SQL визначає межі лише для використання буферного пулу. Будуть мінливі, але значні виділення, що перевищують цю межу.

Джонатан Кехайяс , Крістіан Болтон та Джон Самсон на рівні 300/400 публікацій з цієї теми. У Brent Ozar є легша для читання стаття, яка може бути кращим місцем для початку.

Також пов'язано: SQL Server 2008 R2 "Пам'ять про привид"


так, я погоджуюся, що він обмежує лише буферний пул. Дякую за закладки, я буду розглядати їх.
Martin Sjöberg

Я читаю на цих посиланнях, і там є якісь непогані речі. Я оновлю своє питання тим, що дізнаюся. Я також відчуваю, що я пережив, що у мене є номер Макс піцерії, який легко доступний ... Цікаво, чи роблять вони домашню доставку?
Мартін Шьоберг

16

Як було сказано, пул буфера та кеш процедур - це єдині речі, якими керує максимальна пам'ять сервера. Є багато іншого в SQL Server, який може з'їсти пам'ять за межею. Вони включають (але не обмежуються ними):

  • База даних пошти
  • SQLCLR
  • Розширені збережені процедури
  • Бінарні файли вони самі
  • SQL Mail
  • SSIS
  • SSAS
  • SSRS

З вищезазначеного ми використовуємо двійкові файли ofc і ssis на цьому сервері.
Мартін Шьоберг

1
Яке інше програмне забезпечення встановлено на сервері? І я маю на увазі що завгодно. Драйвери MPIO, драйвери флеш-накопичувача, резервне програмне забезпечення, антивірус,
системні

Сервер досить чистий і нещодавно встановлений, але часто у нас його є. Я спробую скласти повний список, складений наприкінці цього тижня. Короткий і з моєї пам’яті… у нас є йодрів (dell), mcafee, Processsexplorer на робочому столі, іометр, розмір дерев ...
Martin Sjöberg

1
Драйверу FusionIO потрібно багато пам'яті для роботи. Це, мабуть, забирає багато цього.
mrdenny

Чи можна це довести? Або налаштувати його на використання менше оперативної пам’яті? Sofar, здається, випустить оперативну пам’ять, коли це доведеться, і я не помітив жодних недоліків, але просто у випадку, коли ми повинні збільшити кількість пакетів ssis. Мене хвилює, що може статися з використанням оперативної пам'яті.
Мартін Шьоберг

3

Від SQL 2012 року single_pages_kb в цьому DMV замінили pages_kb. https://msdn.microsoft.com/en-us/library/ms175019.aspx?f=255&MSPPError=-2147217396

Тож якщо ви хочете запустити запит, включений у запитання, на сервері 2012+ вийміть рядок single_.


Спасибі. Я перетворив його на page_size_in_bytes, але це було не те саме.
Ілля

2

http://msdn.microsoft.com/en-us/library/ms178067.aspx

Для зменшення максимальної пам'яті сервера може знадобитися перезапустити SQL Server, щоб звільнити пам'ять.

Я розумію, що якщо сторінка в буферному пулі не була записана на диск, вона не буде випущена, поки вона не буде.

Чи призводить до зниження налаштування максимальної пам’яті SQL Server змивання брудних сторінок?

Він міг контролювати менеджер буфера в perfmon, щоб перевірити це. Perfmon -> SQLServer: Buffer Manager: Сторінки баз даних


Вам "може" знадобиться перезапустити SQL Server. Це не завжди потрібно. Чи знаєте ви умови, за яких перезапуск необхідний або не потрібен для звільнення пам'яті?
Нік Чаммас

Я відредагував би ці відомості у вашій існуючій відповіді та видалив би цю. Можливо, mrdenny може відповісти на ваше запитання про промивання брудних сторінок.
Нік Чаммас

1
Правильно, SQL не може випустити сторінку пам’яті, коли вона забруднена (написано на). Кожен раз, коли контрольні пункти системи брудні сторінки записуються на диск. Я не вірю, що зміна максимальної пам'яті сервера спричиняє контрольну точку.
mrdenny

1
Перезапуск екземпляра для зміни налаштувань пам'яті може бути великою помилкою. Хоча зміна налаштувань пам'яті не спричиняє CHECKPOINTоперацій з базами даних, вона змиває кеш процедур. Якщо ви перезапустите примірник лише для зміни налаштувань пам'яті, кеш процедури не тільки буде холодним, але й кеш даних буде холодним. Якщо максимум пам’яті неможливо зменшити через брудні сторінки в пам’яті, запустіть CHECKPOINTкоманду на базі даних для видалення брудних сторінок на диск, а потім змініть налаштування пам’яті в не піковий час, не перезавантажуючи примірник.
Джон Сейгель
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.