SQL Server використовує не всю пам'ять


10

У мене є 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 Гб .

Я запустив запит, наданий Шенкі:

select
(physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(Virtual_address_committed_kb/1024 )Total_Memory_in_MB,--RAM+ Pagefile
process_physical_memory_low,
process_virtual_memory_low
from sys. dm_os_process_memory

Це дало такий результат:

Physical_Memory_usedby_Sqlserver_MB: 5247
Locked_pages_used_Sqlserver_MB: 0
Total_Memory_in_MB: 5625
process_physical_memory_low: 0
process_virtual_memory_low: 0

Що я не розумію, це те, чому Total_Memory_in_MB не дорівнює 6144 (максимальна пам'ять)?

Я знайшов у sys.dm_os_ring_buffersRESOURCE_MEMPHYSICAL_LOW , тому я думаю, що Windows втратило пам'ять, і SQL Server повинен повернути їх. Але є близько 1 ГБ пам’яті => чому Windows говорить про те, що в неї не вистачає пам’яті?

<Record id="13861" type="RING_BUFFER_RESOURCE_MONITOR" time="20635079241">   
   <ResourceMonitor>
        <Notification>RESOURCE_MEMPHYSICAL_LOW</Notification>
        <IndicatorsProcess>0</IndicatorsProcess>
        <IndicatorsSystem>2</IndicatorsSystem>
        <NodeId>0</NodeId>
        <Effect type="APPLY_LOWPM" state="EFFECT_OFF" reversed="0">0</Effect>
        <Effect type="APPLY_HIGHPM" state="EFFECT_IGNORE" reversed="0">85827186</Effect>
        <Effect type="REVERT_HIGHPM" state="EFFECT_OFF" reversed="0">0</Effect>   
   </ResourceMonitor>   
   <MemoryNode id="0">
        <TargetMemory>6050080</TargetMemory>
        <ReservedMemory>67208656</ReservedMemory>
        <CommittedMemory>5423548</CommittedMemory>
        <SharedMemory>0</SharedMemory>
        <AWEMemory>0</AWEMemory>
        <PagesMemory>4975656</PagesMemory>   
   </MemoryNode>   
   <MemoryRecord>
        <MemoryUtilization>100</MemoryUtilization>
        <TotalPhysicalMemory>8387608</TotalPhysicalMemory>
        <AvailablePhysicalMemory>1048452</AvailablePhysicalMemory>
        <TotalPageFile>11142348</TotalPageFile>
        <AvailablePageFile>2887916</AvailablePageFile>
        <TotalVirtualAddressSpace>137438953344</TotalVirtualAddressSpace>
        <AvailableVirtualAddressSpace>137371168056</AvailableVirtualAddressSpace>
        <AvailableExtendedVirtualAddressSpace>0</AvailableExtendedVirtualAddressSpace
   </MemoryRecord> 
</Record>

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

Відповіді:


3

Для початку потрібно сказати, що ви встановили максимальну пам'ять сервера в 6 ГБ, а загальна пам’ять - 8 ГБ, тому ви лише залишили 2 ГБ для ОС, що в багатьох випадках, навіть якщо нічого не встановлено крім SQL Server на машині Windows , занадто мало оперативної пам'яті. Щоб нормально функціонувати, у системі із встановленим антивірусом ОС потрібно мати мінімум 4 Гб. Я залишаю відразу 2 Гб для ОС і 1,5 Г для AV.

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

Цільова пам’ять сервера означає, скільки пам’яті потрібно SQL серверу, щоб нормально функціонувати в ідеальному випадку. Цільова пам’ять сервера намагається скласти 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 серверу більше оперативної пам’яті, щоб дізнатись, скільки потрібно оперативної пам’яті SQL серверу та чи стикається SQL Server із тиском пам'яті. З того, що ви згадали, якщо ви впевнені, що сторінки видаляються з буферного пулу, то так, SQL Server вважає, що сторінки потрібно перемістити, оскільки для розміщення нових сторінок йому потрібен простір. Я не впевнений, як ви обчислили 700 Мб безкоштовно.

Ще одне, не дивіться диспетчера завдань щодо споживання пам'яті SQL Server. Це не завжди дає вам правильне значення, особливо коли в обліковому записі служби SQL Server є заблоковані сторінки в привілеї пам'яті . У вашому випадку, навіть якщо SQL Server має максимальну пам'ять сервера в 6 ГБ, ОС отримує лише 2 ГБ, що змушує SQL Server не збільшувати його споживання, оскільки 2 ГБ для SQL Server мало. Чи є щось, крім SQL Server, що працює в системі?

Якщо ви хочете обчислити споживання пам'яті SQL Server, будь ласка, використовуйте:

select
(physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 ) Locked_pages_used_Sqlserver_MB,
(virtual_address_space_committed_kb/1024 ) Total_Memory_in_MB,--RAM+ Pagefile
process_physical_memory_low,
process_virtual_memory_low
from sys.dm_os_process_memory

Що я не розумію, це те, чому 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 .

ПРИМІТКА. Загальна використана пам'ять була б більшою, ніж фізична пам'ять.


5

SQL Server використовує багато інших кешів, крім буферного кешу, хоча це далеко не найбільше (очевидний приклад - кеш плану). Ви можете більш детально ознайомитись з пам'яттю DBCC MEMORYSTATUSта різноманітними DMV. Цільова пам'ять і загальна пам'ять стосуються спеціально буферного пулу / кешу.

Витяг із семінару Крістіана Болтона " Професійні внутрішні системи та усунення несправностей" :

  • MSSQL$<instance >:Memory Manager\Total Server Memory (KB):
    Це вказує на поточний розмір буферного пулу.
  • MSSQL$<instance >:Memory Manager\Target Server Memory (KB):
    Це вказує на ідеальний розмір для буферного пулу. Total і Target мають бути майже однаковими на сервері без тиску пам'яті, який працює деякий час. Якщо загальний показник значно менший, ніж цільовий , то ймовірно, що SQL Server не може наростити буферний пул через тиск пам’яті, і в цьому випадку ви можете далі дослідити.

Для додавання, навіть якщо загальна та цільова пам'ять сервера однакові, ми не можемо бути на 100% впевнені, що немає тиску в пам'яті. У цьому випадку нам потрібно запустити ще кілька лічильників пам’яті та отримати їхні дані, щоб дійти висновку.
Шанкі

"Загальне та цільове значення повинні бути майже однаковими на сервері без тиску пам'яті, який працює деякий час." Давайте подумаємо над цим. Я підтримую новий SQL Server із 128 ГБ оперативної пам’яті та створюю єдину базу даних 1 Гб. Нехай він працює протягом місяця. Чи я справді вірю, що підсумковий і цільовий показники будуть майже однаковими наприкінці цього місяця? Якщо їх немає, чи варто вважати, що сервер знаходиться під тиском пам'яті? Мені важко повірити.
Майк Шеррілл 'Відкликання котів'
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.