Database Query Performansı Nasıl Monitor Edilir: Yavaş Sorguları Kullanıcılarınızı Etkilemeden Bulun

Yavaş bir sayfa nadiren yavaş bir sayfadır. Çoğu zaman arkasında yavaş bir sorgu vardır. Uygulamanız iyi tasarlanmış, cache'iniz sıcak ve frontend'iniz hızlı olabilir — ama tek bir eksik index veya optimize edilmemiş tek bir sorgu, 50 milisaniyelik bir isteği 5 saniyelik bir timeout'a dönüştürebilir. Sert bir crash'in aksine yavaş sorgu nadiren error log'da görünür. Kullanıcılar ayrılana kadar deneyimi sessizce kötüleştirir.

Database query performansını monitor etmek, veritabanınızın ayakta olup olmadığını izlemekten farklıdır. İkisi de önemlidir ama farklı soruları yanıtlar. Bu rehber, yavaş sorguları ortaya çıkaran metrikleri, bunları PostgreSQL ve MySQL'de bulan SQL'i ve 7/24 nasıl göz önünde tutacağınızı anlatıyor.

İki Farklı Soru: Ayakta mı, Hızlı mı?

Database monitoring iki katmana ayrılır. Availability monitoring basit bir soruyu yanıtlar: uygulamanız veritabanına hâlâ ulaşabiliyor mu ve makul bir sürede yanıt alıyor mu? Query performance monitoring daha zor bir soruyu yanıtlar: hangi sorgular yavaş, neden yavaşlar ve veri büyüdükçe kötüleşiyorlar mı? İkisine de ihtiyacınız var — veritabanı tamamen erişilebilirken tek bir kontrolden çıkmış sorgu uygulamanızı diz çöktürebilir.

Gerçekten Önemli Olan Metrikler

Yavaş sorgu avına çıkmadan önce neyi ölçtüğünüze karar verin. Sağlıklı bir veritabanını, incident yaratmak üzere olan bir veritabanından ayıran sayılar şunlar:

• Query latency — bir sorgunun çalışması için geçen süre; p50, p95 ve p99 olarak raporlanır. p50'nin 10 ms, p99'un 3 saniye olması çoğu kullanıcının sorunsuz ama birkaçının beklediği anlamına gelir.
• Throughput (QPS) — saniyedeki sorgu sayısı. Ani bir artış, yeni bir özelliği veya paylaşılan altyapıdaki gürültülü bir komşuyu ele verebilir.
• Slow query rate — eşiğinizi (örneğin 500 ms) aşan sorguların payı. Sizi ilk uyarması gereken sayı budur.
• Connection pool saturation — tüm bağlantılar meşgulken yeni istekler bekler. Yüksek bekleme süresi çoğu zaman bağlantı eksikliğinin değil, yavaş sorguların belirtisidir.
• Lock ve deadlock olayları — uzun süren tek bir transaction, arkasındaki her şeyi bloke edebilir.

PostgreSQL'de Yavaş Sorguları Bulun

PostgreSQL, işin çoğunu sizin yerinize yapan tek bir araca sahiptir: pg_stat_statements eklentisi. Çalışan her sorgu için toplam süre, ortalama süre ve çağrı sayısı dahil olmak üzere toplu istatistikler kaydeder. Bir kez etkinleştirin ve en yavaş sorgularınızın kalıcı bir sıralamasını elde edin.

• Eklentiyi etkinleştirin: CREATE EXTENSION IF NOT EXISTS pg_stat_statements; çalıştırın, shared_preload_libraries'e ekleyin ve sunucuyu yeniden başlatın.
• En yavaş sorgularınızı ortalama süreye göre sıralayın: SELECT query, calls, mean_exec_time, max_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
• Tek bir sorguya EXPLAIN ANALYZE ile yakınlaşın. Sorguyu gerçekten çalıştırır ve planı gösterir; böylece index kullanıp kullanmadığını veya full table scan yapıp yapmadığını görürsünüz.
• Büyük bir tabloda Seq Scan, tahmin edilen ile gerçek satır sayısı arasındaki büyük fark ve pahalı sort işlemlerine dikkat edin — bunlar yavaş PostgreSQL sorgularının en yaygın üç nedenidir.

MySQL'de Yavaş Sorguları Bulun

MySQL, birkaç ayarla etkinleştirebileceğiniz bir slow query log tutar. long_query_time değerinden uzun süren her sorguyu yakalar; bu da ek bir monitoring aracı eklemeden en kötü suçluları bulmanın en hızlı yoludur.

• Etkinleştirin: SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; ardından dosyayı SHOW VARIABLES LIKE 'slow_query_log_file'; ile bulun.
• Herhangi bir SELECT üzerinde EXPLAIN ile planı inceleyin. type sütununa bakın — ALL, genellikle düzeltilmesi gereken full table scan anlamına gelir.
• SHOW INDEX FROM your_table; ile index kapsamını kontrol edin ve eksik ya da kullanılmayan index'leri arayın.
• SHOW STATUS içinde Threads_running ve Threads_connected değerlerini izleyin; artan çalışan thread sayısı çoğu zaman yavaş sorguların bağlantıları açık tuttuğunu gösterir.

Belirtiyi Değil, Kök Nedeni Düzeltin

Yavaş sorguyu bulmak işin yalnızca yarısıdır. Düzeltmeler birkaç bilinen kategoriye ayrılır:

• Eksik index — en yaygın neden. WHERE ve JOIN sütunlarınıza eklenen bir index, full scan'i çoğu zaman birkaç milisaniyeye indirir.
• N+1 problemi — tüm küme için tek sorgu yerine her satır için bir sorgu çalıştıran ORM. Loglarınızda birbirine çok benzeyen çok sayıda küçük sorgu arayın.
• Aşırı veri çekme — hiç kullanmadığınız sütunları veya ihtiyacınız olmayan satırları seçmek. Sonuçları sınırlayın ve yalnızca gösterdiğinizi seçin.
• Connection pool yanlış yapılandırması — çok küçük bir pool istekleri kuyruğa sokar; çok büyük bir pool veritabanını boğabilir. Gerçek trafiğe göre ayarlayın.

Kullanıcılarınızdan Önce Siz Bilin

Query seviyesindeki araçlar, veritabanının içinde neyin yavaş olduğunu söyler. Ama veritabanınıza uygulamanızdan ulaşılıp ulaşılmadığını veya siz uyurken bir health-check sorgusunun hâlâ yanıt verip vermediğini söylemez. İşte burada dış monitoring devreye girer.

isthisthing.online, belirli bir aralıkla veritabanınıza bağlanan, bir check çalıştıran ve Response Time'ı ölçen bir MySQL veya PostgreSQL Monitor oluşturmanıza olanak tanır. Veritabanı yanıt vermeyi bırakırsa veya bir check Timeout değerini aşarsa, kullanıcılarınız bir error görmeden önce Email, Slack veya diğer kanallarınız üzerinden alert alırsınız. Incident timeline'ı ve public Status Page ile birlikte, "site yavaşladı" ifadesini almak yerine gönderdiğiniz bir mesaja dönüştürürsünüz.

Pratik Bir Checklist

• Slow query loglamayı açın (PostgreSQL: pg_stat_statements; MySQL: slow_query_log).
• En yavaş 10 sorgunuzu bulun ve her birinde EXPLAIN ANALYZE çalıştırın.
• Önce eksik index'leri ve N+1 problemini düzeltin — en büyük kazanımları bunlar sağlar.
• Bir latency eşiği belirleyin ve yalnızca error'larda değil, bu eşik aşıldığında alert alın.
• Dışarıdan availability ve Response Time'ı izlemek için isthisthing.online'da bir MySQL veya PostgreSQL Monitor ekleyin.
• Her deployment ve her schema değişikliğinden sonra query metriklerini gözden geçirin.

Yavaş sorgular kendilerini duyurmaz. Site yavaş hissedene, veritabanı doyana ve önleyebileceğiniz bir outage ile boğuşana kadar birikir. Veritabanınızı hem içeriden hem dışarıdan monitor edin ve ilk söyleyen isthisthing.online olsun.

Bugün ilk Monitor'ünüzü oluşturun. Ücretsiz hesabınızı açın ve yavaş sorguları kullanıcılarınızdan önce yakalayın.