DBAtlas · Veritabanı operasyon atlası

Yüksek CPU

Sunucu CPU'su tavan yapmış. Önce gerçekten veritabanının mı yediğini doğrula, sonra dalları izleyerek kök nedeni bul: kötü planlı sorgular, plan regresyonu, aşırı eşzamanlılık ya da DB dışı bir süreç.

CPU'yu gerçekten veritabanı mı yiyor?

İşletim sistemi tarafında hangi sürecin CPU yaktığına bak. Yükün büyük kısmı DB süreçlerinde mi, yoksa komşu bir süreçte (yedek, antivirüs, başka uygulama) mi? Bu, aramayı ikiye ayırır.

-- OS tarafı: top -o %CPU  (ya da: top -c)
-- DB tarafı doğrulama:
SELECT ROUND(value,1) AS host_cpu_util_pct FROM v$sysmetric WHERE metric_name='Host CPU Utilization (%)' AND rownum=1;
  • Evet, CPU'yu DB süreçleri yiyor
  • Hayır, komşu bir süreç / yedek işi yiyor

Yük nasıl ortaya çıktı?

CPU'yu DB yiyorsa deseni belirle: birkaç ağır sorgu mu baskın, sorun bir değişiklikle mi aniden başladı, yoksa yüksek eşzamanlılık/bağlantı çekişmesi mi var?

  • Birkaç ağır sorgu CPU'yu yakıyor
  • Ani başladı — son deploy / parametre değişimi var
  • Çok sayıda bağlantı / eşzamanlılık çekişmesi

En çok CPU harcayan sorguları bul

CPU'yu toplamda en çok tüketen ilk sorguları çıkar. Sonra tek çağrı başına ağır mı (kötü plan), yoksa çağrı başına ucuz ama çok sık mı çağrılıyor buna karar ver.

SELECT sql_id, executions, ROUND(cpu_time/1e6,1) AS cpu_sec, ROUND(cpu_time/GREATEST(executions,1)/1000,2) AS cpu_ms_per_exec, sql_text
FROM v$sql ORDER BY cpu_time DESC FETCH FIRST 10 ROWS ONLY;
  • Çağrı başına ağır — kötü plan / full scan var
  • Çağrı başına ucuz ama çok sık çağrılıyor

Kök neden: Kötü planlı sorgu CPU yakıyor

Birkaç sorgu, full scan veya kötü join sırası yüzünden çağrı başına aşırı CPU harcıyor. Planlarını düzeltmek çekirdek çözümdür.

Kök neden: Aşırı çağrı sıklığı

Sorgular tek tek ucuz ama saniyede binlerce kez çağrılıyor; toplam CPU maliyeti buradan geliyor. Genelde N+1 deseni veya önbelleksiz sıcak yol.

Kök neden: Plan regresyonu / bayat istatistik

Sistem dün normaldi, bir deploy, parametre değişimi veya veri yüklemesinden sonra CPU fırladı. Optimizer daha kötü bir plana geçmiş olabilir.

Kök neden: Yüksek eşzamanlılık / bağlantı çekişmesi

Tek tek sorgular kabul edilebilir ama aynı anda çok fazla oturum çalışıyor; CPU çekirdek sayısını aşan aktif oturum sayısı context-switch ve latch/spin çekişmesi yaratıyor.

Kök neden: DB dışı süreç CPU yiyor

CPU'yu veritabanı değil komşu bir süreç yiyor: yedekleme/sıkıştırma işi, antivirüs taraması, log gönderici ya da aynı makinedeki başka bir uygulama.

DBAtlas'ta aç →