Skip to main content

Cek Konsumsi CPU Mysql

Siap bro 🔥
Ini gue bikinkan versi Knowledge Base (KB) / SOP Managed Service yang bisa langsung lo pakai.

📘 Knowledge Base

Cara Mengidentifikasi Query yang Mengkonsumsi CPU di MySQL (Azure & On-Prem)

🎯 Objective

Mengidentifikasi query yang menyebabkan CPU usage tinggi pada MySQL server, baik:

  • Azure Database for MySQL (PaaS)

  • MySQL VM / On-Prem

🧠 Konsep Penting

CPU tinggi biasanya disebabkan oleh:

  • Long running query

  • Full table scan

  • Missing index

  • Query concurrency tinggi (query storm)

  • Temporary table besar

  • Sorting besar tanpa index

🔍 STEP 1 — Konfirmasi CPU Spike (Azure)

Jika Menggunakan Azure Database for MySQL

1️⃣ Login ke Azure Portal
2️⃣ Masuk ke resource Azure Database for MySQL
3️⃣ Klik Metrics
4️⃣ Tambahkan metric berikut:

  • CPU percent

  • Active connections

  • IO percent

  • Memory percent

📌 Perhatikan:

  • Apakah CPU spike terjadi tiba-tiba (burst)?

  • Apakah spike sejalan dengan kenaikan Active Connections?

🔎 STEP 2 — Cek Query Aktif (Real-Time)

Jalankan:

SHOW FULL PROCESSLIST;

Atau lebih fokus:

SELECT *
FROM information_schema.PROCESSLIST
WHERE COMMAND != 'Sleep'
ORDER BY TIME DESC;

Perhatikan:

  • Query dengan TIME > 10 detik

  • State seperti:

    • Sending data

    • Copying to tmp table

    • Locked

    • Sorting result

📌 Jika ada query dengan TIME besar → kemungkinan penyebab CPU.

🔥 STEP 3 — Cek Concurrency Level

Jalankan:

SHOW GLOBAL STATUS LIKE 'Threads_running';

Interpretasi umum:

Threads_running Kondisi
1–5 Normal
5–10 Medium
10–30 High
>30 Critical

Jika tinggi bersamaan dengan CPU spike → concurrency overload.

🔎 STEP 4 — Cek Jumlah Query per Detik (Detect Query Storm)

Jalankan:

SHOW GLOBAL STATUS LIKE 'Queries';

Catat nilai.

Tunggu 5 detik, jalankan lagi.

Hitung selisih:

(Query2 - Query1) / 5 = QPS (Queries Per Second)

Jika QPS sangat tinggi → kemungkinan query storm.

📊 STEP 5 — Gunakan Performance Schema (Paling Akurat)

Jalankan:

SELECT 
    DIGEST_TEXT,
    COUNT_STAR,
    ROUND(SUM_TIMER_WAIT/1000000000000,2) AS total_seconds,
    ROUND(AVG_TIMER_WAIT/1000000000000,4) AS avg_seconds
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

Ini akan menampilkan:

  • Query paling sering dijalankan

  • Query paling banyak menghabiskan waktu CPU

  • Total waktu eksekusi kumulatif

📌 Ini metode paling efektif untuk investigasi CPU.

🧨 STEP 6 — Cek Slow Query

Cek apakah slow query aktif:

SHOW VARIABLES LIKE 'slow_query_log';

Jika ON:

SHOW VARIABLES LIKE 'long_query_time';

Query yang lebih lama dari nilai tersebut akan masuk slow log.

📈 STEP 7 — Cek Connection Pressure

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';

Jika Max_used_connections mendekati max_connections → connection pressure.

🧠 STEP 8 — Interpretasi Hasil

Kondisi 1 — CPU Tinggi + Threads_running Tinggi

👉 Query concurrency overload.

Kondisi 2 — CPU Tinggi + Query TIME besar

👉 Ada long-running query.

Kondisi 3 — CPU Tinggi + QPS Tinggi

👉 Query storm.

Kondisi 4 — CPU Tinggi + IO tinggi

👉 Disk bottleneck.

Kondisi 5 — Semua normal tapi CPU spike

👉 Burst query singkat atau background maintenance.

📌 Checklist Investigasi Cepat (Ringkas)

Saat CPU spike terjadi:

  1. SHOW FULL PROCESSLIST

  2. SHOW GLOBAL STATUS LIKE 'Threads_running';

  3. Cek QPS

  4. Query Performance Schema digest

  5. Cek Azure Metrics

🧾 Kesimpulan Standar Managed Service

CPU spike investigation should focus on active queries, concurrency level, and query execution summary from Performance Schema.
Snapshot analysis must be performed during the spike window to accurately identify the root cause


No Comments
Back to top