PostgreSQL 17 work_mem ve Linux OOM Killer Hesaplayıcı

PostgreSQL'de yaygın bir yanılgı olan 'work_mem sorgu başına harcanır' efsanesini sorgu düğümleri, hash_mem_multiplier ve paralel worker çarpanlarıyla simüle edin; sunucunuzu Linux OOM Killer çöküşünden koruyun.

Sunucu ve PostgreSQL Parametreleri

Sunucu Toplam RAM32 GB

shared_buffers8 GB

Kuresel work_mem32 MB

Her dugum ve her paralel worker icin ayri tahsis edilir.

hash_mem_multiplier (PG 13+)2x

Paralel Worker (Gather basina)2 Worker

Aktif Es-Zamanli Sorgu Sayisi40 Sorgu

Baglanti Mimarisi

Linux OOM Risk SeviyesiYuksek Risk%51 Cokme / Kill Ihtimali

Tek Sorgu Tepe Bellek432 MB3 dugum x 3 surec x 2x carpan

Tepe Veritabani RAM26.48 GB2.32 GB guvenli bos RAM

Onerilen Cerrahi Bellek Boyutlandirmasi (Surgical Sizing)

Kuresel Guvenli work_mem (postgresql.conf)24 MBTum baglantilar icin guvenli tavan deger; ani yukte sunucuyu korur.

Oturum Bazli Analitik work_mem (Session/Role)192 MBRaporlama kullanicisi veya gece ETL isleri icin cerrahi yukseltme.

Sistem ve Veritabani Onerileri

•Sistem bellek dengesi guvenlidir (2.32 GB guvenlik marji mevcut).
•Kuresel work_mem degerini 24 MB seviyesine cekin. Yalnizca agir raporlama yapan kullanicilar icin 'ALTER ROLE analytics_user SET work_mem = "192MB";' seklinde cerrahi tanimlama yapin.
•Linux OOM Killer'in ana PostgreSQL postmaster surecini oldurup tum veritabanini kurtarma (recovery) moduna sokmasini engellemek icin systemd uzerinde 'OOMScoreAdjust=-1000' tanimlayin.
•200 adet dogrudan baglanti backend basina yaklasik 8-10 MB taban bellek tuketir. PgBouncer Transaction Pooling ile baglanti sayisini 20-30 seviyesine indirerek hem RAM tasarrufu yapin hem de anlik pikleri dengeleyin.

Yapilandirma ve OOM Koruma Kodlari

postgresql.conf, systemd OOMScoreAdjust, sysctl ve canli bellek inceleme SQL'i.

# /etc/postgresql/17/main/postgresql.conf
# Guvenli Bellek ve OOM Onleme Yapilandirmasi

# Paylasilan bellek (RAM'in %25'i)
shared_buffers = 8GB

# Kuresel varsayilan work_mem (Dusuk tutulmali, OOM'u onler!)
work_mem = 24MB

# PostgreSQL 13+ Hash join katlayicisi (Varsayilan 2.0)
hash_mem_multiplier = 2.0

# Paralel is parcacigi basina limit
max_parallel_workers_per_gather = 2
max_parallel_maintenance_workers = 2

# Bakim ve indeksleme bellek limiti
maintenance_work_mem = 2048MB

PostgreSQL Bellek Mimarisi: work_mem Neden Sunucuları Çökertir?

"Sorgu Başına Değil, Düğüm ve Worker Başına" İlkesi

PostgreSQL yöneticilerinin yaptığı en tehlikeli hata, work_mem = 64MB ayarlandığında bir kullanıcı sorgusunun en fazla 64 MB RAM harcayacağını varsaymaktır. Gerçekte work_mem, yürütme planındaki (EXPLAIN plan) her bir Sort, Hash Join ve Hash Aggregate düğümüne ayrı ayrı tahsis edilir.

Üstelik PostgreSQL 13 ile gelen hash_mem_multiplier (varsayılan 2.0), hash işlemlerinin diske taşmadan (spill to disk) önce 2 kat daha fazla (128 MB) bellek kullanmasına izin verir. Sorguda 4 paralel worker (Gather) çalışıyorsa, 1 lider + 4 iş parçacığı olmak üzere 5 ayrı süreç bu belleği tüketir. Sonuç olarak tek bir karmaşık SQL sorgusu anında 1.5 - 2 GB RAM tüketebilir!

Cerrahi Boyutlandırma ve OOMScoreAdjust Korunması

Eş zamanlı 30-40 analitik sorgu çalıştığında Linux çekirdeğinin hafızası tükenir ve OOM Killer devreye girer. Linux varsayılan olarak en çok sanal bellek (VSS) tutan ana PostgreSQL postmaster sürecini hedef alır ve öldürür. Bu durum veritabanının aniden kapanmasına ve kurtarma (crash recovery) moduna girerek dakikalarca kesintiye uğramasına yol açar.

Çözüm iki adımdan oluşur:
1. Cerrahi Boyutlandırma (Surgical Sizing): Küresel work_mem 4-8 MB gibi muhafazakar bir değerde tutulmalı; büyük raporlama yapan kullanıcılar veya oturumlar için SET work_mem = '128MB' şeklinde özel artırılmalıdır.
2. systemd Koruması: OOMScoreAdjust=-1000 parametresi ile postmaster süreci Linux OOM Killer'a karşı dokunulmaz kılınmalıdır.