pg_stat_statements ile Yavaş Sorgular

Yavaş sorguları toplam süre, çağrı ve ortalamayla önceliklendirin. Sorgu davranışını sürekli ve düşük yükle izleyin.

2026-10-03 · 2 dakika okuma

Problem neden önemlidir?

Tek bir yavaş sorgu örneği, toplam sistem yükünün en büyük kaynağı olmayabilir. Sık çalışan orta maliyetli ifadeler, nadir uç değerlerden daha fazla kaynak tüketebilir.

Nasıl teşhis edilir?

pg_stat_statements içindeki çağrı, toplam yürütme süresi, ortalama süre ve satır sayılarını birlikte inceleyin. Normalize edilmiş sorgular parametre değerlerini gizler ve sayaçlar sıfırlanabilir.

Sorgu, pg_stat_statements uzantısı kurulu ve çağıran rol için erişilebilir olduğunda çalışır. Kümülatif süreleri istatistik toplama dönemi bağlamında yorumlayın.

SELECT queryid, calls, total_exec_time, mean_exec_time, rows,
       left(query, 300) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

Güvenli çözüm yaklaşımı

Önce toplam etkisi yüksek ve iş açısından önemli sorguları seçin. İndeks, SQL veya şema değişikliklerini gerçek parametre dağılımları ve EXPLAIN planlarıyla doğrulayın.

Sürekli monitoring neden gerekir?

moon, PostgreSQL sorgu eğilimlerinin sürekli ve düşük ek yükle izlenmesine yardımcı olur. Slack, PagerDuty veya webhook uyarıları yeni sorgu gerilemelerini ekibe yönlendirebilir.

Sık sorulan sorular

En yüksek mean_exec_time her zaman ilk öncelik midir?

Hayır, az çağrılan bir sorgunun toplam etkisi düşük olabilir. Ortalama süreyi çağrı, toplam süre ve iş önemine göre değerlendirin.

moon bu konuda nasıl yardımcı olur?

moon, SQL Server, PostgreSQL ve MongoDB sinyallerini sürekli izleyerek problemi anlık bir kontrolden ziyade zaman içindeki davranışıyla değerlendirmeye yardımcı olur.