PostgreSQL performansı nasıl iyileştirilir: önce ölç, sonra ayarla

Önce teşhis: yavaşlık nerede başlıyor?

PostgreSQL performans sorunları farklı katmanlardan gelir: tek bir kötü sorgu, eksik indeks, yetersiz bellek ayarı, şişmiş tablolar, bağlantı fazlalığı ya da disk darboğazı. Ayar yapmadan önce sorunun hangi katmanda olduğunu bulmak gerekir; aksi hâlde rastgele parametre değiştirmek zaman kaybettirir ve yeni sorunlar yaratır.

Teşhis için kullanılan temel araçlar şunlardır: • Yavaş sorgu günlüğü: Belirli bir süreyi aşan sorguların kayda alınması (log_min_duration_statement ayarı). • pg_stat_statements eklentisi: Hangi sorgunun toplamda ne kadar süre harcadığını ve kaç kez çalıştığını gösterir. Tek tek yavaş sorgu yerine toplam yük açısından en pahalı sorguyu bulmak için kullanılır. • pg_stat_activity görünümü: Şu anda çalışan, bekleyen ya da kilit bekleyen oturumları gösterir. • EXPLAIN ve EXPLAIN ANALYZE: Bir sorgunun yürütme planını ve gerçek çalışma süresini gösterir.

Ölçüm önce sistem düzeyinde yapılır: işlemci, bellek, disk giriş çıkışı ve bağlantı sayısı. Sorun veritabanı dışındaysa sorgu ayarı sonuç vermez.

Yürütme planı okuma: sorgu neden yavaş?

EXPLAIN çıktısı, sorgunun nasıl çalıştırılacağını düğümler hâlinde gösterir. Yorumlarken şunlara bakılır: tabloyu baştan sona tarayan ardışık tarama (sequential scan) büyük tablolarda sorun olabilir; indeks taraması ise seçici bir filtre için uygundur. Birleştirme yöntemi (nested loop, hash join, merge join) satır sayısına göre uygun mu? Sıralama ve gruplama diske taşıyor mu?

En önemli ipucu tahmin ile gerçek arasındaki farktır. EXPLAIN ANALYZE, planlayıcının tahmin ettiği satır sayısı ile gerçekte işlenen satır sayısını yan yana gösterir. Fark büyükse istatistikler eskidir, sütunlar arasında ilişki vardır ya da koşul planlayıcının anlayamayacağı biçimde yazılmıştır. Çözüm genellikle ANALYZE ile istatistikleri tazelemek, genişletilmiş istatistik tanımlamak ya da sorguyu yeniden yazmaktır.

EXPLAIN ANALYZE sorguyu gerçekten çalıştırır; veri değiştiren sorgularda dikkatli kullanılmalı, canlı ortamda ağır sorgular için önlem alınmalıdır.

İndeks stratejisi: doğru indeks, doğru yerde

İndeks, okumayı hızlandırır ama yazmayı yavaşlatır ve yer kaplar. Bu yüzden her sütuna indeks eklemek çözüm değildir. Sorguların filtre, birleştirme ve sıralama sütunlarına bakılarak seçici ve gerçekten kullanılan indeksler oluşturulur.

PostgreSQL farklı indeks türleri sunar: Varsayılan B-tree eşitlik ve aralık sorgularına uygundur. GIN indeksi dizi, JSONB ve tam metin aramada kullanılır. GiST ve benzeri türler coğrafi ve aralık verisinde işe yarar. Kısmi indeks yalnızca belirli koşulu sağlayan satırları kapsar; örneğin yalnız aktif kayıtları. Birden çok sütunlu indekste sütun sırası önemlidir; en çok filtrelenen ve eşitlik aranan sütun başa konur. Kapsayan indeks (INCLUDE), sorgunun gereksinim duyduğu ek sütunları taşıyarak tabloya gitmeyi azaltır.

Kullanılmayan ve tekrarlayan indeksleri belirlemek için istatistik görünümleri incelenir. İndeksi canlıda oluşturmak gerekiyorsa tabloyu kilitlemeyen eşzamanlı oluşturma seçeneği tercih edilir.

Yapılandırma ayarı: bellek ve bağlantı

Varsayılan yapılandırma düşük kaynaklı bir sunucu için ihtiyatlı seçilmiştir; üretim sunucusunda gözden geçirilmelidir. Ana parametreler: • shared_buffers: PostgreSQL'in kendi ön bellek alanı. Sunucu belleğinin makul bir kısmına ayarlanır. • work_mem: Sıralama ve hash işlemleri için işlem başına ayrılan bellek. Yüksek tutulursa çok sayıda eşzamanlı sorguda toplam bellek tüketimi hızla artar; bu yüzden dikkatli artırılır. • effective_cache_size: Planlayıcıya işletim sisteminin ön belleğinden ne kadar yararlanılabileceğini söyleyen tahmin değeri. • maintenance_work_mem: İndeks oluşturma ve vacuum gibi bakım işleri için. • max_connections: Bağlantı sayısı arttıkça bellek ve bağlam geçişi maliyeti büyür.

Çok sayıda istemci bağlantısı olan uygulamalarda her istemcinin ayrı veritabanı bağlantısı açması yerine PgBouncer gibi bir bağlantı havuzlayıcı kullanılır. Parametre değişiklikleri her seferinde tek tek yapılıp ölçülmeli, hangisinin fark yarattığı kayda alınmalıdır.

Vacuum, şişme ve MVCC

PostgreSQL, eşzamanlılığı MVCC ile sağlar: güncellenen veya silinen satırın eski sürümü hemen yok edilmez, yeni sürüm eklenir. Eski sürümler (ölü satırlar) vacuum tarafından temizlenmedikçe tablo ve indeks şişer, taramalar yavaşlar. Otomatik vacuum (autovacuum) bunu arka planda yapar, ancak çok yoğun yazılan tablolarda varsayılan ayarlar yetersiz kalabilir.

İzlenecek belirtiler: ölü satır oranı yüksek tablolar, uzun süredir vacuum görmemiş tablolar, uzun süren açık işlemler (eski sürümlerin temizlenmesini engeller) ve beklenmedik tablo büyümesi. Çözüm yolları: tablo bazında autovacuum eşiklerini daha erken tetiklenecek biçimde ayarlamak, uzun işlemleri sonlandırmak, şişmiş tablolar için planlı bakım ya da yeniden paketleme yapmak.

İstatistiklerin güncelliği de planlayıcı kararlarını etkiler; büyük veri yüklemesinden sonra ANALYZE çalıştırmak iyi bir alışkanlıktır.

Büyük tablolar: bölümleme ve okuma yükünün dağıtılması

Tablolar çok büyüdüğünde sorgular, bakım ve silme işlemleri zorlaşır. Bölümleme (partitioning), tabloyu tarih ya da anahtar aralığına göre alt tablolara ayırır. Planlayıcı gereksiz bölümleri atlayabildiği için zaman bazlı sorgular hızlanır; eski verinin silinmesi ise bölümü tamamen kaldırmakla yapılır, bu da büyük silme işlemlerinin yarattığı şişmeyi önler. Bölümleme anahtarı sorguların en sık filtrelediği sütun olmalıdır; aksi hâlde yarar sağlamaz.

Okuma yükü yüksek uygulamalarda replikasyon ile okuma kopyaları kurularak raporlama ve analitik sorgular birincil sunucudan ayrılabilir. Bu durumda kopyadaki gecikmeyi (replication lag) göz önünde bulundurmak gerekir: yazıdan hemen sonra okuma yapılan akışlar birincil sunucuya yönlendirilmelidir.

Donanım tarafında disk giriş çıkış hızı, bellek ve işlemci birbirini etkiler. Yazma günlüğü (WAL) ve veri dosyalarının farklı disklerde olması bazı iş yüklerinde fark yaratır; ölçmeden karar verilmemelidir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

PostgreSQL İleri Seviye: Performans ve Yönetim eğitimi, mimari, MVCC ve vacuum yönetimi; yapılandırma ve kaynak ayarı; bölümleme ve büyük tablo yönetimi; replikasyon ve yüksek erişilebilirlik; performans izleme ve sorun teşhisi; yedekleme, kurtarma ve sürüm yükseltme modüllerinden oluşur.

Bu modül sırası, bu sayfadaki teşhis ve ayar akışıyla örtüşür: önce mimariyi anlamak, sonra yapılandırmayı ve büyük tabloları yönetmek, ardından izleme ile sorunları teşhis etmek.