Misteri Spike Warna Biru: Debugging High “IO Wait” di Google Cloud SQL

Image Generated by Gemini (Nano Banana)

Setelah hampir dua dekade berkecimpung di dunia infrastruktur dan database, rutinitas pagi saya — dan mungkin kita semua — tidak banyak berubah: menyeduh kopi, lalu mengecek dashboard monitoring.

Biasanya, kita berharap melihat grafik yang datar dan hijau (healthy state). Namun, terkadang mata kita tertuju pada satu anomali: sebuah lonjakan (spike) yang terjadi tepat di jam sibuk pagi hari.

Bukan lonjakan CPU (yang biasanya berwarna hijau), tapi lonjakan yang didominasi warna biru.

Baru-baru ini saya membedah kasus menarik di Google Cloud SQL (MySQL) di mana Database Load meningkat tajam. Uniknya, ini bukan disebabkan oleh kueri JOIN yang kompleks atau table scan raksasa tanpa index. Penyebabnya jauh lebih sederhana, namun sering luput dari perhatian kita: sebuah perintah COMMIT yang dijalankan secara agresif.

Mari kita bedah kasusnya bersama-sama, memahami apa arti “Warna Biru” tersebut, dan bagaimana kita bisa mengoptimalkannya agar sistem kita lebih efisien.

The Clues: Membaca Sinyal dari Query Insights

Google Cloud SQL memiliki fitur Query Insights yang sangat powerful jika kita tahu cara membacanya. Dari tangkapan layar dashboard di bawah ini, ada tiga petunjuk vital yang langsung menceritakan “kisah horor” di balik layar:

(Caption: Dashboard Cloud SQL menunjukkan dominasi warna biru pada Database Load)

• Dominasi Warna Biru (IO Wait): Perhatikan grafik Database Load. Area berwarna biru mewakili IO Wait. Ini adalah indikator bahwa thread database kita tidak sedang sibuk memproses data di CPU, melainkan sedang “menganggur” menunggu disk selesai menulis atau membaca data. CPU kita bosan, tapi Disk kita “berkeringat”.
• Top Query adalah COMMIT: Ketika di scroll kebawah tabel di bawah grafik ini. Kueri nomor satu bukanlah SELECT yang rumit, melainkan perintah COMMIT.
• Frekuensi yang Ekstrem: Perintah ini dipanggil sebanyak 2.120.069 kali (2,1 juta kali!) hanya dalam rentang waktu 6 jam.

Diagnosis: Mengapa COMMIT Mencekik I/O Kita?

Mungkin timbul pertanyaan di benak kita: “Mengapa perintah sesederhana COMMIT bisa menyebabkan antrian I/O yang begitu panjang?"

Di dalam database relasional seperti MySQL, konsep ACID (Atomicity, Consistency, Isolation, Durability) adalah harga mati. Huruf “D” (Durability) adalah kuncinya di sini.

Setiap kali aplikasi kita mengirimkan perintah COMMIT:

1. Database wajib menjamin bahwa data tersebut benar-benar tersimpan di tempat penyimpanan disk (persistent) dan tidak akan hilang jika listrik mati satu detik kemudian.
2. Demi garansi ini, MySQL harus melakukan flush (penulisan paksa) dari memori ke Transaction Logs (WAL/Redo Log) di disk fisik.
3. Proses penulisan ke disk fisik inilah yang memakan waktu (latency).

Masalahnya: Aplikasi kita melakukan pola yang sering saya sebut sebagai “Chatty Transactions”.

Bayangkan kita sedang belanja bulanan. Alih-alih membawa semua barang dari kasir ke mobil sekaligus dalam satu troli besar, kita mengambil satu butir telur, lari ke mobil, menaruhnya, lalu kembali ke kasir untuk mengambil satu buah apel, dan begitu seterusnya.

Aplikasi melakukan INSERT/UPDATE, lalu COMMIT. Diulang 2 juta kali. Akibatnya, disk dipaksa bekerja keras untuk menulis log transaksi kecil-kecil secara terus menerus. Inilah yang menyebabkan IO Wait melambung tinggi.

Realitas: Apakah Server Kita Sedang Sekarat?

Mari kita lihat grafiknya dengan kepala dingin. Apakah server ini akan down? Sebenarnya tidak.

Jika kita perhatikan sumbu Y pada grafik, Database Load hanya menyentuh angka 0.4. Sementara garis putus-putus (CPU Capacity) berada di angka 8 vCPU.

Artinya, server kita sebenarnya masih sangat santai. Kapasitas yang terpakai bahkan tidak sampai 10%. Namun, sebagai engineer yang berpengalaman, kita tahu bahwa ini adalah bentuk inefisiensi teknis.

Saat ini mungkin aman. Tapi jika trafik aplikasi naik 10x lipat? Pola ini akan dengan cepat menghabiskan jatah IOPS (Input/Output Operations Per Second) disk cloud kita. Saat IOPS mentok, aplikasi akan mulai terasa lambat (high latency), dan user akan mulai komplain. Kita tidak ingin menunggu momen itu terjadi.

Solusi: Batch Processing adalah Kunci

Solusi untuk masalah ini hampir selalu ada di sisi kode aplikasi (Application Logic), bukan dengan mengutak-atik konfigurasi database my.cnf.

Berikut adalah perbandingannya:

Cara Lama (Inefisien — The “Chatty” Way):

# Pola yang menyebabkan jutaan COMMIT dan high IO Wait
for data in dataset:
    cursor.execute("INSERT INTO table (col) VALUES (%s)", (data,))
    # Kita memaksa disk menulis log setiap kali satu baris data masuk
    connection.commit()

Cara Baru (Optimasi Batch — The Senior Way):

Kita harus mengelompokkan transaksi. Lakukan COMMIT hanya setelah sekumpulan data diproses, misalnya setiap 1.000 baris.

# Pola Batch Processing yang lebih sehat
batch_size = 1000
counter = 0

cursor.execute("START TRANSACTION") # Mulai transaksi besar
for data in dataset:
    cursor.execute("INSERT INTO table (col) VALUES (%s)", (data,))
    counter += 1

    # Cek apakah sudah waktunya commit
    if counter % batch_size == 0:
        connection.commit() # Hanya menulis ke disk sekali per 1000 data
        cursor.execute("START TRANSACTION") # Mulai lagi

connection.commit() # Jangan lupa commit sisa data terakhir

Dengan perubahan logika sederhana ini, dari 2.000.000 operasi I/O, kita bisa memangkasnya menjadi hanya 2.000 operasi I/O. Beban disk turun drastis, latensi membaik, dan spike warna biru itu akan menghilang.

Kesimpulan

Warna biru pada Query Insights adalah sinyal SOS dari disk storage kita. Meskipun kita memiliki CPU yang gahar (seperti 8 vCPU dalam kasus ini), performa database seringkali dibatasi oleh seberapa cepat disk bisa menulis data (Disk I/O Bound).

Pelajaran bagi kita: Jangan buru-buru melakukan vertical scaling (upgrade storage atau CPU) saat melihat load tinggi. Seringkali, masalahnya ada pada bagaimana aplikasi kita berbicara dengan database. Cek kode aplikasi, matikan autocommit pada proses bulk insert, dan mulailah membudayakan batching.

• Indikasi: Grafik Database Load didominasi warna biru (IO Wait) dengan “COMMIT” sebagai top query.
• Penyebab: Aplikasi melakukan COMMIT terlalu sering (misal: per satu baris data), memaksa disk melakukan penulisan log jutaan kali (Chatty Transactions).
• Dampak: Memboroskan IOPS disk dan meningkatkan latensi, meskipun CPU Usage terlihat rendah.
• Solusi: Ubah logika aplikasi menjadi Batch Processing. Lakukan COMMIT per 100-1000 baris data, bukan per satu baris.