SQL Server Lock Pages in Memory: Ne Zaman Açılır, Nasıl Verilir, Nasıl Doğrulanır?

Windows, sunucudaki her sürecin belleğini yönetir. Bellek sıkıştığında bir sürecin working set’ini kırpabilir ve belleğinin bir kısmını page file’a taşıyabilir. Çoğu uygulama için bu zararsızdır. Ancak buffer pool’u tam da disk I/O’sundan kaçınmak için var olan SQL Server için, bu belleğin diske yazılıp geri okunması performansın başına gelebilecek en kötü şeylerden biridir.

Lock Pages in Memory (LPIM), bunu engelleyen Windows kullanıcı hakkıdır. Bu rehberde LPIM’in ne yaptığını ve ne yapmadığını, ne zaman açmaya değdiğini, Group Policy tuzağı dahil nasıl doğru verileceğini, kullanımda olduğunun nasıl doğrulanacağını ve neden her zaman doğru boyutlandırılmış bir max server memory ile birlikte kullanılması gerektiğini anlatıyoruz.

Lock Pages in Memory Ne Yapar?

SQL Server servis hesabı Lock pages in memory hakkına (SeLockMemoryPrivilege ayrıcalığına) sahip olduğunda, SQL Server buffer pool belleğini Windows AWE API’leri üzerinden ayırır. Bu şekilde ayrılan bellek kilitlidir: Windows onu diske sayfalayamaz ya da süreçten kırpamaz; SQL Server kendisi bırakana kadar fiziksel RAM’de kalır.

LPIM’in yapmadıkları:

• SQL Server’ın daha fazla bellek kullanmasını sağlamaz ve max server memory’yi değiştirmez.
• SQL Server’ın dinamik bellek yönetimini kapatmaz. SQL Server cache’lerini yine büyütüp küçültür ve Windows’un düşük bellek bildirimlerine belleği kendisi bırakarak yanıt verir.
• Thread stack’leri ve linked server provider’ları gibi buffer pool dışındaki ayırmaları korumaz.
• RAM’i yetersiz bir sunucuyu hızlandırmaz. Yalnızca Windows’un SQL Server’dan habersiz bellek almasını engeller.

SQL Server 2012’den bu yana LPIM, herhangi bir trace flag gerekmeden Enterprise’ın yanı sıra Standard sürümde de çalışır. Standard sürüm için trace flag 845’ten bahseden eski rehberler güncel değildir.

Ne Zaman Açılmalı?

LPIM her yerde açılan bir performans ayarı değil, bir korumadır. Şu durumlarda değerlendirin:

• SQL Server belleği sayfalanıyorsa. En net işaret, SQL Server error log’daki 17890 numaralı hatadır (aşağıda); genellikle ani bir performans düşüşüyle birlikte görülür.
• Sunucudaki başka yazılımlar bellek dalgalanmalarına yol açıyorsa: yedekleme ajanları, antivirüs taramaları, büyük dosya kopyalamaları, sürücüler. LPIM, buffer pool’un bunların kurbanı olmasını önler.
• SQL Server, hypervisor’ın konuk belleğini geri alabildiği bir sanal makinede çalışıyorsa. Örneğin Microsoft’un Azure sanal makinelerinde SQL Server için best practice’leri LPIM’i açmayı da içerir.
• Kararlı bir buffer pool’un esneklikten daha önemli olduğu büyük, ayrılmış veritabanı sunucularında.

Hiç sayfalama belirtisi göstermemiş, doğru boyutlandırılmış ve ayrılmış bir sunucuda LPIM çoğu zaman ölçülebilir bir fark yaratmaz. max server memory ayarlı olduğu sürece production sunucuları için standart kurulumun makul bir parçasıdır.

Uyarı İşareti: 17890 Hatası

Windows, SQL Server belleğinin büyük bir kısmını sayfaladığında SQL Server error log’a şu mesajı yazar:

A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 1250000, committed (KB): 30500000, memory utilization: 4%.

Kritik değer memory utilization’dır: commit edilmiş belleğin hâlâ fiziksel RAM’de olan kısmı. Düşük bir değer, SQL Server belleğinin çoğunun az önce diske itildiği anlamına gelir. Aramak için:

EXEC sys.xp_readerrorlog 0, 1, N'significant part of sql server process memory';

Her Zaman Önce max server memory’yi Ayarlayın

LPIM, Windows’un SQL Server’dan bellek geri alma yeteneğini ortadan kaldırır. max server memory hâlâ varsayılan 2.147.483.647 MB değerindeyse SQL Server fiziksel belleğin neredeyse tamamını kilitleyebilir; işletim sistemi ve diğer tüm süreçler kalan için yarışır. Sonuç, oturum açması zor bir sunucu, başarısız yedekler ya da tamamen yanıt vermeyen bir makine olabilir.

Lock Pages in Memory Nasıl Açılır?

1. SQL Server servis hesabını bulun

SELECT servicename, service_account
FROM sys.dm_server_services
WHERE servicename LIKE N'SQL Server (%';

Virtual account ile kurulmuş varsayılan bir instance için bu NT Service\MSSQLSERVER, named instance için NT Service\MSSQL$InstanceAdı‘dır. Domain servis hesabı kullanılıyorsa o hesaptır.

2. Hakkı verin

1. secpol.msc‘yi (Local Security Policy) yönetici olarak çalıştırın.
2. Security Settings › Local Policies › User Rights Assignment bölümüne gidin.
3. Lock pages in memory‘yi açın ve Add User or Group‘a tıklayın.
4. 1. adımdaki servis hesabını ekleyin. Virtual account için NT Service\MSSQLSERVER yazın ve konumun yerel bilgisayar olduğundan emin olun.

3. SQL Server servisini yeniden başlatın

Ayrıcalık, servis başlarken okunur. Yeniden başlatmaya kadar SQL Server önceki bellek modeliyle çalışmaya devam eder. Yeniden başlatmayı bir bakım penceresinde planlayın; availability group ya da failover cluster’da hakkı her node’da verin ve node’ları sırayla yeniden başlatın.

Hakkı komut satırından kontrol edin

# Yerel güvenlik politikasını dışa aktarın ve ayrıcalığı arayın
secedit /export /cfg "$env:TEMP\secpol.cfg" /areas USER_RIGHTS | Out-Null
Select-String -Path "$env:TEMP\secpol.cfg" -Pattern 'SeLockMemoryPrivilege'

Çıktı hesapları SID olarak listeler (örneğin virtual service account için *S-1-5-80-...). Satır yoksa bu hak kimseye verilmemiştir.

Kullanımda Olduğunu Nasıl Doğrularsınız?

Yeniden başlatmadan sonra SQL Server’ın gerçekten kilitli sayfaları kullandığını doğrulayın:

-- CONVENTIONAL = kullanılmıyor, LOCK_PAGES = kullanılıyor, LARGE_PAGES = trace flag 834 ile kullanılıyor
SELECT sql_memory_model_desc
FROM sys.dm_os_sys_info;

-- NUMA node başına kilitli bellek
SELECT osn.node_id, omn.locked_page_allocations_kb / 1024 AS locked_mb
FROM sys.dm_os_memory_nodes AS omn
JOIN sys.dm_os_nodes        AS osn ON osn.memory_node_id = omn.memory_node_id
WHERE osn.node_state_desc <> N'ONLINE DAC';

LPIM etkin olduğunda error log’un açılış bölümünde “Using locked pages in the memory manager.” satırı da yer alır.

Large Pages ve Trace Flag 834

LPIM verildiğinde Enterprise sürüm, açılışta trace flag 834 etkinleştirilerek buffer pool’u large page’ler halinde de ayırabilir (sql_memory_model_desc bu durumda LARGE_PAGES gösterir). Microsoft bunu çoğu ortam için önerilmeyen ileri düzey bir yapılandırma olarak tanımlar: bellek açılışta tamamen ayrılır, bu da açılışı yavaşlatır ve instance’ı daha az esnek hale getirir; columnstore index’lerle birlikte de önerilmez. Belirli ve test edilmiş bir nedeniniz yoksa açmayın.

Sanal Makinelerde Lock Pages in Memory

• LPIM buffer pool’u konuk içindeki Windows’a karşı korur, hypervisor’a karşı değil. Host’ta VM’in belleğini rezerve edin ve overcommit’ten kaçının.
• LPIM’i dinamik bellekle (Hyper-V Dynamic Memory gibi) birlikte kullanmayın. SQL Server’ın kilitlediği bellek, hypervisor VM’i küçültmek istediğinde geri verilemez.
• Bellek baskısı oluşursa buffer pool’un bir tabanı korunsun diye min server memory’yi de ayarlayın.

Nasıl Kapatılır?

SQL Server servis hesabını Lock pages in memory hakkından (yerelde ya da GPO’da) çıkarın ve servisi yeniden başlatın. sql_memory_model_desc yeniden CONVENTIONAL değerine döner.

Lock Pages in Memory Kontrol Listesi

• max server memory ayarlı ve işletim sistemine ve diğer servislere yer bırakıyor.
• Hak, her node’da gerçek SQL Server servis hesabına verilmiş.
• Domain ortamında hak yalnızca yerelde değil, sunucunun OU’sunu yöneten GPO’da tanımlı.
• Servis yeniden başlatılmış ve sql_memory_model_desc LOCK_PAGES gösteriyor.
• Error log 17890 için izleniyor.
• VM’lerde bellek rezerve, dinamik bellek kapalı.
• Trace flag 834 belirli bir neden olmadan açık değil.