Cara Troubleshoot Database Load Tinggi di MariaDB — Panduan

Pendahuluan

Malam itu jam 2 pagi, alarm monitoring server nyala — CPU usage naik drastis, tapi bukan karena aplikasi web yang ramai. Setelah saya cek, ternyata load-nya datang dari database. MariaDB yang seharusnya light malah jadi heavyweight karena ada query yang jalan terus-terusan tanpa batas. Saya pernah handle kasus di mana satu query SELECT * tanpa WHERE yang benar bisa bikin seluruh shared hosting pada nge-downtime selama 45 menit. Waktu itu saya masih junior, dan lesson-nya bikin saya trauma sampai sekarang — selalu cek database load dulu sebelum ngapa-ngapain.

Kalau kamu pernah ngalamin server yang tiba-tiba lemot padahal CPU-nya cuma 20%, kemungkinan besar masalahnya bukan di CPU tapi di database. Load tinggi di MariaDB itu ibarat macet di janan tol — bukan karena mobilnya banyak, tapi karena ada satu truk yang mogok di tengah jalan dan bikin semua kendaraan di belakangnya berhenti. Query yang lambat atau stuck bisa bikin connection menumpuk, dan akhirnya server kamu ngangkang.

Di artikel ini saya akan tunjukkan urutan command yang selalu saya pakai saat troubleshoot database load tinggi di MariaDB — dari yang paling basic sampai yang advance. Semua command ini sudah saya pakai ratusan kali di lapangan dan terbukti work. Yuk, kita mulai dari yang pertama.

Command #1: Login ke MariaDB dan Cek Status Server

Sebelum kita masuk ke troubleshooting yang lebih dalam, langkah pertama yang selalu saya lakukan adalah login ke MariaDB dan cek status server secara keseluruhan. Ini kayak mau diagnosa orang sakit — sebelum periksa spesifik, kita cek dulu detak jantung dan tekanan darahnya.

mysql -u root -p

Setelah login, langsung jalankan:

SHOW GLOBAL STATUS;

Command ini menampilkan semua status variabel MariaDB — dari jumlah query yang sudah dijalankan, connection yang aktif, sampai buffer pool usage. Jangan panik kalau output-nya ratusan baris. Yang perlu kamu fokuskan di awal adalah tiga variabel ini:

• Threads_connected — berapa banyak koneksi yang aktif saat ini
• Threads_running — berapa banyak thread yang benar-benar sedang menjalankan query (ini lebih penting dari Threads_connected)
• Questions — total query yang sudah dijalankan sejak server terakhir restart

Kalau Threads_running tinggi (di atas 10 di server shared hosting), itu red flag. Biasanya di bawah 3-5 sudah normal untuk server kecil-menengah.

Command #2: SHOW PROCESSLIST — Siapa yang Bikin Macet?

Ini adalah command paling powerful untuk troubleshoot database load tinggi. SHOW PROCESSLIST menunjukkan semua query yang sedang berjalan di MariaDB saat ini — siapa yang jalankan, dari mana, dan sudah berapa lama.

SHOW FULL PROCESSLIST;

Saya pakai FULL karena tanpa itu, kolom Info akan dipotong di 100 karakter. Dengan FULL, kamu bisa lihat query lengkap. Output-nya kurang lebih seperti ini:

Id	User	Host	db	Command	Time	State	Info
14523	webapp	localhost	production	Query	847	Sorting result	SELECT * FROM orders WHERE …
14524	webapp	localhost	production	Query	234	Sending data	SELECT * FROM logs JOIN users …
14530	root	localhost	NULL	Sleep	12

Yang perlu kamu perhatikan:

• Kolom Time — kalau ada query yang Time-nya di atas 60 detik, itu sudah suspicious. Di atas 300 detik? itu pasti bermasalah.
• Kolom State — Sending data atau Sorting result yang berlama-lama biasanya menandakan query yang tidak di-index dengan baik.
• Kolom Info — baca query-nya. Cari SELECT *, LIKE '%...%', atau JOIN tanpa WHERE yang efektif.

Dari pengalaman saya, 80% kasus database load tinggi bisa diidentifikasi langsung dari SHOW FULL PROCESSLIST. Kalau kamu nemu query yang Time-nya di atas 300 detik, itu adalah kandidat utama penyebab masalah.

Command #3: Cek Koneksi dari Luar MariaDB dengan lsof

Kadang masalahnya bukan di query-nya, tapi di jumlah koneksi yang terlalu banyak. MariaDB punya batas koneksi (max_connections), dan kalau batas itu tercapai, koneksi baru akan ditolak. Untuk cek berapa banyak koneksi ke port MariaDB (default 3306) dari luar, saya pakai lsof:

lsof -i :3306 | grep LISTEN

Command ini menunjukkan semua proses yang terhubung ke port 3306. Kamu bisa lihat berapa banyak koneksi dari IP tertentu, dari user tertentu, atau dari aplikasi tertentu.

Untuk lebih spesifik, filter berdasarkan user:

lsof -i :3306 -u webapp

Atau hitung total koneksi:

lsof -i :3306 | wc -l

Kalau jumlahnya mendekati atau melebihi max_connections MariaDB kamu (biasanya 151 default), itu tanda ada connection leak di aplikasi. Aplikasi yang buka koneksi tapi tidak pernah close() adalah penyebab umum masalah ini.

Saya pernah handle kasus di mana satu aplikasi PHP membuka 50 koneksi database per request karena developer lupa pakai connection pooling. Hasilnya? Server langsung max connection dan semua user lain tidak bisa akses database. Lesson-learned: selalu pakai persistent connection atau connection pooling untuk aplikasi yang traffic-nya tinggi.

Command #4: Cek Open Tables dengan SHOW OPEN TABLES

Setiap kali MariaDB membuka sebuah tabel untuk dibaca atau ditulis, tabel tersebut masuk ke dalam “open tables cache.” Kalau cache-nya penuh, MariaDB harus menutup tabel lama sebelum membuka yang baru — ini menambah overhead dan bisa bikin performa menurun drastis.

SHOW OPEN TABLES WHERE In_use > 0;

Command ini menunjukkan tabel mana yang sedang di-lock atau sedang digunakan oleh query yang berjalan. Kolom In_use menunjukkan berapa banyak query yang sedang menggunakan tabel tersebut.

Kalau kamu lihat ada tabel dengan In_use di atas 5, itu red flag — berarti ada banyak query yang mengakses tabel yang sama secara bersamaan. Ini bisa menyebabkan lock contention, di mana query-query saling menunggu giliran untuk akses tabel yang sama.

Untuk cek apakah open tables cache cukup besar:

SHOW GLOBAL VARIABLES LIKE 'table_open_cache';

Di server shared hosting dengan traffic tinggi, saya biasanya set table_open_cache minimal 2000-4000. Default MariaDB adalah 400, dan itu sering tidak cukup untuk server yang handle banyak tabel.

Command #5: Cek LVE dan Resource Usage

Di server shared hosting yang pakai CloudLinux, setiap user punya Resource Limit (LVE) yang membatasi CPU, RAM, dan I/O usage. Kalau user tertentu menggunakan terlalu banyak resource database, dia bisa “makan jatah” user lain.

Untuk cek LVE usage:

lveinfo --usage --by-id

Atau untuk user spesifik:

lveinfo --usage --by-user webapp

Output-nya menunjukkan:

• CPU % — persentase CPU yang digunakan
• PMEM (MB) — memory yang digunakan
• IO — disk I/O usage
• EP (entries) — entry processes

Kalau kamu lihat user tertentu consistently menggunakan CPU di atas 80% atau I/O di atas 50%, itu bisa jadi penyebab server lambat untuk user lain. Di CloudLinux, kamu bisa sesuaikan LVE limit untuk user tersebut:

lvectl set-user webapp --cpu=50 --pmem=512 --io=20

Command ini membatasi user webapp menggunakan maksimal 50% CPU, 512MB RAM, dan 20 I/O. Ini membantu mencegah satu user menghabiskan semua resource server.

Command #6: Cek Slow Query Log

Salah satu cara paling efektif untuk menemukan query-query bermasalah adalah dengan mengaktifkan slow query log. Ini mencatat semua query yang lebih dari waktu tertentu (biasanya 1-2 detik).

Pertama, cek apakah slow query log sudah aktif:

SHOW GLOBAL VARIABLES LIKE 'slow_query_log';

Kalau OFF, aktifkan:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/lib/mysql/slow-queries.log';

Setelah aktif, biarkan beberapa menit lalu cek log-nya:

mysqldumpslow -s t -t 10 /var/lib/mysql/slow-queries.log

Command mysqldumpslow mengurutkan slow query berdasarkan waktu eksekusi dan menampilkan top 10 query terlambat. Ini sangat membantu untuk menemukan query yang perlu dioptimasi.

Dari pengalaman saya, biasanya ada pola: query yang masuk slow query log selalu involves JOIN antara tabel besar tanpa index yang memadai, atau LIKE '%...%' yang melakukan full table scan.

Command #7: Analisis Query dengan EXPLAIN

Setelah kamu menemukan query bermasalah dari SHOW PROCESSLIST atau slow query log, langkah selanjutnya adalah menganalisis query tersebut dengan EXPLAIN.

EXPLAIN SELECT * FROM orders JOIN users ON orders.user_id = users.id WHERE orders.status = 'pending';

EXPLAIN menunjukkan rencana eksekusi MariaDB untuk query tersebut. Yang perlu kamu perhatikan:

• Type — kalau ALL atau index, itu berarti full table scan (jelek). Idealnya ref, eq_ref, atau const.
• Key — kalau NULL, berarti tidak ada index yang digunakan (masalah besar).
• Rows — estimasi berapa baris yang harus diperiksa. Kalau angkanya sangat besar (jutaan), query-nya kemungkinan lambat.
• Extra — kalau ada Using filesort atau Using temporary, itu tanda query perlu dioptimasi.

Command #8: Cek Index yang Tidak Terpakai

Kadang masalahnya bukan index yang kurang, tapi index yang terlalu banyak. Index yang tidak terpakai tetap memakan resource saat INSERT/UPDATE/DELETE.

SELECT * FROM sys.schema_unused_indexes WHERE object_schema NOT IN ('mysql','sys','performance_schema','information_schema');

Atau tanpa sys schema:

SELECT * FROM information_schema.statistics WHERE index_name NOT IN ('PRIMARY','PRIMARY_KEY') GROUP BY table_schema, table_name HAVING COUNT(*) > 3;

Ini menunjukkan tabel yang punya lebih dari 3 index — biasanya kandidat untuk dibersihkan.

Pro Tips: Yang Sering Dilupakan

1. Restart MariaDB bukan solusi — itu hanya menunda masalah. Kalau ada query yang lambat, fix query-nya, bukan restart server.
2. KILL query yang stuck — kalau kamu nemu query yang Time-nya sudah ratusan detik, jangan ragu untuk KILL [ID];. Lebih baik satu query di-kill daripada seluruh server nge-downtime.
3. Monitor secara berkala — jangan hanya cek saat ada masalah. Saya biasanya set cron untuk log Threads_running setiap 5 menit, jadi kalau ada spike, saya punya data historis untuk analisis. Kalau server kamu pakai VPS, biasanya ada integrated monitoring seperti troubleshooting disk I/O yang bisa kasih gambaran I/O usage juga.
4. Perhatikan aborted_connects — kalau angkanya terus naik, berarti ada masalah koneksi yang perlu ditelusuri lebih lanjut.

FAQ

Bagaimana cara mengetahui apakah MariaDB saya mengalami load tinggi?

Command paling cepat adalah SHOW GLOBAL STATUS LIKE 'Threads_running'; — kalau angkanya di atas 10 di server kecil, kemungkinan ada masalah. Untuk gambaran lebih lengkap, jalankan SHOW GLOBAL STATUS; dan perhatikan Threads_connected, Threads_running, Slow_queries, dan Aborted_connects.

Apakah aman menjalankan KILL pada query yang sedang berjalan?

Ya, KILL [ID] hanya menghentikan query tersebut, bukan seluruh koneksi. MariaDB akan mengembalikan error Query execution was interrupted ke client, dan client biasanya akan retry. Yang tidak aman adalah KILL [ID] pada transaksi yang sedang berjalan — ini bisa menyebabkan rollback yang memakan waktu.

Kenapa SHOW PROCESSLIST tidak menunjukkan query dari aplikasi?

Karena query-nya sudah selesai dijalankan (terlalu cepat). Kalau kamu ingin menangkap query-query cepat, aktifkan general_log sesaat (jangan lama-lama karena bisa bikin disk penuh): SET GLOBAL general_log = 'ON'; lalu matikan setelah beberapa menit.

Berapa max_connections yang ideal untuk server shared hosting?

Untuk shared hosting dengan RAM 8-16GB, saya biasanya set max_connections antara 200-300. Tapi yang lebih penting adalah mengatur wait_timeout dan interactive_timeout agar koneksi idle langsung ditutup. Default 28800 detik (8 jam) terlalu lama — saya biasanya set 60-120 detik.

Related Issues

• Kenapa Perubahan DNS Memerlukan Waktu Tunggu? — sering terjadi bersamaan dengan database load issue ketika ada migrasi server
• Solusi GRUB Rescue Error Pasca Resize Disk — troubleshooting disk yang bisa mempengaruhi database I/O

Kesimpulan

Troubleshoot database load tinggi di MariaDB itu sebenarnya tidak serumit yang dibayangkan, asalkan kamu tahu urutan command yang tepat. Mulai dari SHOW GLOBAL STATUS untuk overview, SHOW FULL PROCESSLIST untuk identifikasi query bermasalah, lsof untuk cek koneksi, SHOW OPEN TABLES untuk cek cache, sampai EXPLAIN untuk optimasi query.

Kunci utamanya adalah: jangan asal restart. Setiap masalah pasti punya akar penyebab, dan tugas kita sebagai engineer adalah menemukan akar masalahnya, bukan sekadar menutupi gejalanya. Kalau kamu rutin monitor dan proaktif, insya Allah server kamu akan tetap stabil.

Ada pertanyaan atau pengalaman troubleshooting database sendiri? Jangan ragu untuk share di komentar — saya baca semua dan balas yang sempat saya balas. Semoga artikel ini membantu!