MySQL Yüksek Threads_running ve CPU: Sorgu mu Kilit mi?
Eşzamanlı çalışan thread artışının CPU yoğun sorgulardan mı yoksa kilit ve I/O beklemelerinden mi kaynaklandığını ayırır; güvenli triyaj ve kalıcı çözümü açıklar.
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.
1. Belirti / Symptom
- M14 (`Threads_running`) baz çizgisinin ve CPU çekirdek sayısının üzerinde kalıyor; sorgu gecikmeleri artıyor. CPU'nun da yüksek olup olmadığını işletim sisteminden **ayrıca** doğrulayın.
- `Too many connections` da varsa `mysql-too-many-connections` runbook'una bakın.
2. Etki / Impact
Sorgular kuyruklanır ve uygulamada zaman aşımı görülür. Threads_running yüksekliği tek başına yüksek CPU demek değildir; kilit veya disk beklemesi de olabilir.
3. Teşhis / Diagnosis
SHOW GLOBAL STATUS WHERE Variable_name IN ('Threads_running','Threads_connected','Questions','Slow_queries');
SELECT id, user, host, db, time AS seconds, state, LEFT(info,200) AS sql_text
FROM information_schema.processlist
WHERE command <> 'Sleep' ORDER BY time DESC LIMIT 30;SELECT schema_name, LEFT(digest_text,160) AS query_pattern, count_star,
ROUND(sum_timer_wait/1e12,2) AS total_seconds,
ROUND(sum_timer_wait/NULLIF(count_star,0)/1e9,2) AS avg_ms,
sum_rows_examined, sum_no_index_used
FROM performance_schema.events_statements_summary_by_digest
WHERE schema_name IS NOT NULL ORDER BY sum_timer_wait DESC LIMIT 15;4. Müdahale / Response
5. Doğrulama / Verification
- M14, CPU ve p95 sorgu gecikmesi baz çizgiye iner; aktif oturum kuyruğu çözülür.
- Değişen sorgunun `EXPLAIN` planı, okunan satır sayısı ve uygulama hataları yeniden ölçülür.
6. Geri Alma / Rollback
- Durdurulan batch'i kontrollü hızda yeniden başlatın; uygulama eşzamanlılık ayarını eski değerine döndürün.
- İndeks değişikliğini geri almadan önce sorgu planını ve diğer sorgulara etkisini doğrulayın. İptal edilen sorgu otomatik devam etmez.