Runbook #11

postgresql

PerformanceSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL work_mem Taşması ve Geçici Dosyalar

Sort/hash işlemlerinin diske taşmasını metrik ve sorgu düzeyinde bulur; plan, indeks ve oturum bazlı bellek ayarıyla gecikmeyi azaltır.

İlişkili Metrik:M11

İlişkili Script:S16 S5

#work_mem#temp-files#sort#hash#pg_stat_statements

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M11 geçici dosya yazma hızı artar; sorgu süreleri ve temp disk kullanımında sıçrama görülür.

- `pg_stat_database.temp_bytes` artar, loglarda `temporary file: path ... size ...` bulunabilir.

2. Etki / Impact

Disk I/O ve sorgu gecikmesi artar; temp alanı dolarsa sorgular hata verir ve diğer iş yükleri etkilenir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. S16/S5 ile toplam diske taşan sorguları bulun (PG 13+ `pg_stat_statements` yüklü olmalı):

sql

SELECT calls, temp_blks_read, temp_blks_written,
       pg_size_pretty(temp_blks_written * current_setting('block_size')::int::bigint) AS temp_written,
       round(mean_exec_time::numeric, 2) AS mean_ms, left(query, 160) AS query
FROM pg_stat_statements
WHERE temp_blks_written > 0
ORDER BY temp_blks_written DESC LIMIT 20;

🟢 Salt Okunur2. `pg_stat_database.temp_bytes` kümülatiftir; 5 dakikalık iki örnek farkıyla hız ölçün. Gerekirse superuser ile kontrollü süre `log_temp_files = '64MB'` açın; çok düşük eşik log hacmini şişirir.

🟢 Salt Okunur3. Sorgu planında `Sort Method: external merge` veya hash batching olup olmadığını değerlendirin. `EXPLAIN (ANALYZE, BUFFERS)` sorguyu **yürütür**; yazan sorguları üretimde bu yolla test etmeyin.

🟢 Salt Okunur4. `SHOW work_mem; SHOW hash_mem_multiplier;` kontrol edin (hash_mem_multiplier PG 13+). Paralel işçiler ve birden fazla sort/hash düğümü `work_mem` sınırını katlayabilir.

4. Müdahale / Response

🟡 Geri Alınabilir1. En ağır sorguda gerekli satırları ve `ORDER BY`/`GROUP BY` desenini sadeleştirin; uygun indeks veya daha küçük batch'i deneyin.

🟡 Geri Alınabilir2. Testte fayda gösterdiyse bellek kapasitesi ve eşzamanlılık sınırı içinde yalnızca ilgili transaction'a bellek verin:

sql

BEGIN;
SET LOCAL work_mem = '128MB';
-- Burada test edilip onaylanmış, ilgili SELECT çalıştırılır.
COMMIT;

`SET LOCAL` transaction sonunda kalkar; uygulama havuzları için oturum ayarını kalıcı bırakmaz.

🟡 Geri Alınabilir3. Yalnızca gerekli rol için ve bellek bütçesiyle kademeli artış düşünün: `ALTER ROLE rapor_rolu SET work_mem = '32MB';` yeni oturumlarda etkinleşir.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. **Global `work_mem` değerini körlemesine artırmayın**. Her sort/hash düğümü ve paralel işçi bellek tüketebilir; OOM kill ve daha büyük kesinti yaşanabilir.

5. Doğrulama / Verification

- M11 hızı ve temp disk latency baz seviyeye dönüyor; sorgu p95 iyileşiyor.

- Kullandığınız bellek/swap ve eşzamanlı oturumlar güvenli sınırlarda kalıyor.

6. Geri Alma / Rollback

- `SET LOCAL` transaction bittiğinde otomatik geri alınır. Rol bazlı ayarı `ALTER ROLE rapor_rolu RESET work_mem;` ile kaldırın (önceki özel değeri not edin).

- Yeni indeks veya sorgu dağıtımı regresyon yaratıyorsa uygulama/DDL geri alma planına göre dönün.

Operasyonel Güvenlik ve Risk Uyarısı

1. Belirti / Symptom

2. Etki / Impact

3. Teşhis / Diagnosis

4. Müdahale / Response

5. Doğrulama / Verification

6. Geri Alma / Rollback

Diğer POSTGRESQL Runbook'ları

PostgreSQL 'too many connections' Hatası: Teşhis ve Acil Müdahale

PostgreSQL Transaction ID Wraparound Acil Durumu: Dondurma (Freeze) Planı

PostgreSQL Kilit Zinciri ve Bloklama: Kök Bloklayıcıyı Bulma ve Çözme

PostgreSQL Yavaşlama ve Yüksek Disk Okuma Triyajı