SQL Server için Windows Page File Ayarları: Ne Kadar Olmalı, Nerede Durmalı, Sayfalama Ne Zaman Sorundur?

İyi yapılandırılmış bir SQL Server sunucusunda SQL Server’ın belleği diske sayfalanmamalıdır; buffer pool tam da disk I/O’sundan kaçınmak için vardır. Bu yüzden page file sorusu çoğu zaman iki uca savrulur: ya “SQL Server sunucusunda page file’a gerek yok, kapatalım” denir ya da eski “RAM’in 1,5 katı” kuralı 512 GB belleği olan bir sunucuya da uygulanır. İkisi de yanlıştır.

Bu rehberde page file’ın bir SQL Server sunucusunda gerçekte ne işe yaradığını, boyutunun neye göre belirlenmesi gerektiğini, nereye konulacağını ve sayfalamanın sorun olup olmadığını nasıl anlayacağınızı anlatıyoruz.

Page File SQL Server Sunucusunda Ne İşe Yarar?

SQL Server’ın kendi belleği diske gitmemeli; ama page file yine de üç iş görür:

• Commit limiti: Windows’un tüm süreçlere verebileceği toplam sanal bellek, fiziksel RAM ile page file boyutunun toplamıdır. Page file çok küçükse ya da yoksa, fiziksel bellekte boş yer olsa bile süreçler bellek ayıramaz hale gelebilir.
• Bellek dökümleri (crash dump): Sunucu mavi ekranla çöktüğünde Windows bellek dökümünü page file aracılığıyla yazar. Uygun boyutta bir page file yoksa döküm oluşmaz ve çökmenin nedeni analiz edilemez.
• Diğer süreçler: Yedekleme ajanları, antivirüs, izleme araçları ve yönetim yazılımları da bellek kullanır. Bunların seyrek kullanılan sayfaları için page file bir güvenlik payıdır.

Boyut Neye Göre Belirlenir?

Eski “RAM’in 1,5 katı” kuralı, belleğin birkaç gigabayt olduğu dönemden kalmadır. Bugün page file boyutunu belirleyen asıl etken, hangi tür bellek dökümüne ihtiyaç duyduğunuzdur:

Yüzlerce gigabayt belleği olan bir veritabanı sunucusunda complete memory dump nadiren gerekir; hem çok büyük bir page file hem de dökümü yazmak için uzun bir süre ister. Çoğu ortam için pratik yaklaşım şudur:

• Döküm ayarını Kernel memory dump ya da Automatic memory dump olarak bırakın.
• Sistem sürücüsünde, döküm için yeterli boyutta bir page file tutun. Birçok sunucuda “System managed size” seçeneği bunu kendiliğinden sağlar.
• Destek ekibiniz ya da Microsoft özellikle complete dump isterse page file’ı o süre için büyütün.

Page File Nereye Konmalı?

• Bellek dökümü için page file’ın sistem sürücüsünde (genellikle C:) olması gerekir.
• SQL Server veri, log ve TempDB dosyalarının bulunduğu disklere page file koymayın. Sayfalama olduğunda bu diskler zaten en çok yük altındadır; iki iş yükünü aynı diske bindirmek gecikmeyi artırır.
• Ek bir page file gerekiyorsa SQL Server dosyalarından ayrı, hızlı bir diske yerleştirin.

Ayarlar System Properties › Advanced › Performance › Settings › Advanced › Virtual memory altındadır. Özel boyut vermek için “Automatically manage paging file size for all drives” seçeneğini kaldırıp sürücüyü seçin, Custom size ile başlangıç ve en büyük değeri girip Set‘e basın:

Mevcut durumu PowerShell ile görebilirsiniz:

# Page file konumu, ayrılan boyut ve şu anki / en yüksek kullanım (MB)
Get-CimInstance Win32_PageFileUsage |
    Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage

Sayfalama Gerçekten Bir Sorun mu?

Page file’ın kullanılıyor olması tek başına sorun değildir; önemli olan SQL Server’ın belleğinin diske gidip gitmediğidir. Bunu üç yerden anlarsınız:

-- İşletim sisteminin bellek durumu
SELECT total_physical_memory_kb / 1024     AS total_mb,
       available_physical_memory_kb / 1024 AS available_mb,
       system_memory_state_desc
FROM sys.dm_os_sys_memory;

-- SQL Server sürecinin bellek durumu
SELECT physical_memory_in_use_kb / 1024 AS physical_in_use_mb,
       locked_page_allocations_kb / 1024 AS locked_mb,
       memory_utilization_percentage,
       process_physical_memory_low
FROM sys.dm_os_process_memory;

-- SQL Server belleğinin sayfalandığını bildiren 17890 mesajı
EXEC sys.xp_readerrorlog 0, 1, N'significant part of sql server process memory';

system_memory_state_desc değerinin “Available physical memory is low” olması, process_physical_memory_low = 1 ve error log’daki 17890 mesajı, sorunun gerçek olduğunu gösterir. Bu durumda çözüm page file’ı büyütmek değil, belleğin nereye gittiğini bulmaktır: önce max server memory değerini doğru boyutlandırın, ardından gerekiyorsa Lock Pages in Memory ile SQL Server’ın belleğini koruma altına alın.

Page File Kontrol Listesi

• Page file kapalı değil; sistem sürücüsünde döküm için yeterli boyutta.
• Döküm türü kernel ya da automatic; complete dump yalnızca gerektiğinde.
• SQL Server veri, log ve TempDB disklerinde page file yok.
• max server memory, işletim sistemine ve diğer servislere pay bırakacak şekilde ayarlı.
• 17890 mesajı ve process_physical_memory_low izleniyor.