:Utilisasi CPU tinggi di PolarDB for MySQL

Slow queries

Utilisasi CPU tinggi sering disebabkan oleh pernyataan SQL yang tidak efisien sehingga menghasilkan slow query dan penumpukan thread aktif. Namun, Anda harus terlebih dahulu menentukan apakah slow query merupakan akar penyebab utilisasi CPU tinggi atau justru bottleneck sumber daya lain yang memperlambat query dan secara tidak langsung meningkatkan utilisasi CPU.

Anda dapat melihat slow query di PolarDB console dengan menavigasi ke Diagnostics and Optimization > Slow SQL. Pada tab Slow Log Details, jika nilai Scanned Rows jauh lebih tinggi daripada nilai Returned Rows, hal ini mengindikasikan bahwa slow query menyebabkan utilisasi CPU tinggi.

Kueri TP melibatkan jumlah baca dan tulis data yang sangat kecil. Jika suatu kueri memindai data dalam jumlah besar, kemungkinan besar indeks tidak tersedia. Misalnya, jika kueri dalam daftar slow query menunjukkan bahwa lebih dari 10.000 baris dipindai tetapi hanya satu baris yang dikembalikan, ini merupakan indikasi jelas bahwa tidak ada indeks pada kolom name.

SELECT * FROM table1 WHERE name='testname';

Anda dapat menggunakan pernyataan berikut untuk memeriksa apakah indeks sudah ada pada kolom name.

SHOW index FROM table1;

• Jika kolom name tidak memiliki indeks, Anda dapat menambahkan indeks dengan pernyataan berikut untuk menghilangkan slow query yang disebabkan oleh pemindaian data skala besar.

  ALTER TABLE table1 ADD KEY ix_name (name);

• Jika kolom name sudah memiliki indeks, Anda dapat menggunakan pernyataan berikut untuk melihat rencana eksekusi pernyataan SQL dan memastikan apakah indeks yang benar digunakan.

  EXPLAIN SELECT * FROM table1 WHERE name='testname';

  Jika Anda menemukan bahwa indeks sudah ada pada kolom name tetapi tidak digunakan, hal ini mungkin disebabkan oleh statistik yang tidak akurat sehingga menghasilkan rencana eksekusi yang salah. Anda dapat menjalankan pernyataan berikut untuk meregenerasi statistik pada tabel guna memperbaiki rencana tersebut.

  ANALYZE TABLE table1;

  Setelah perintah selesai, periksa kembali rencana eksekusi untuk memastikan bahwa indeks yang benar kini digunakan:

  EXPLAIN SELECT * FROM table1 WHERE name='testname';

High active thread count

Jumlah thread aktif yang tinggi selalu meningkatkan utilisasi CPU. Di MySQL, setiap core CPU hanya dapat memproses satu permintaan dalam satu waktu. Sebagai contoh, kluster 16-core dapat menangani maksimal 16 permintaan konkuren pada level kernel, yang berbeda dari konkurensi tingkat aplikasi. Anda dapat melihat informasi sesi di PolarDB console dengan menavigasi ke Diagnostics and Optimization > One-click diagnosis > Sessions.

Jika Anda telah menyingkirkan slow query sebagai penyebab kegagalan pemrosesan permintaan, penumpukan thread aktif biasanya disebabkan oleh peningkatan lalu lintas produksi. Anda dapat melihat kurva performa untuk memverifikasi hal ini. Jika tren lalu lintas dan permintaan secara keseluruhan konsisten dengan tren penumpukan thread aktif, hal ini menunjukkan bahwa sumber daya kluster telah mencapai batasnya. Untuk mengatasi masalah ini, Anda harus menambahkan node read-only ke kluster database atau melakukan scale up spesifikasi kluster.

Ketika jumlah thread aktif mencapai titik kritis, contention CPU dapat terjadi, menghasilkan banyak mutex lock di kernel. Grafik performa biasanya akan menunjukkan utilisasi CPU tinggi, jumlah thread aktif tinggi, serta IOPS atau QPS rendah. Penyebab lain adalah lonjakan lalu lintas mendadak, di mana laju koneksi baru yang tinggi juga menyebabkan contention CPU dan backlog permintaan. Anda sering kali dapat mengurangi masalah ini dengan mengaktifkan fitur thread pool kluster untuk kontrol aliran. Jika jumlah thread aktif berkurang, periksa apakah tugas masih tertunda di sisi aplikasi. Jika beban CPU dan jumlah thread aktif tetap tinggi, Anda juga harus mempertimbangkan untuk melakukan scale up kluster.

Frontend connection storm juga dapat menyebabkan lonjakan lalu lintas instan pada kluster. Ini merupakan lalu lintas abnormal, sering kali disebabkan oleh web crawler. Anda dapat menggunakan SQL throttling untuk menolak permintaan. Untuk informasi lebih lanjut, lihat Session Management.

Improper kernel configuration

Parameter default untuk instans MySQL yang dikelola sendiri dikonfigurasi untuk skenario penggunaan umum dan mungkin tidak optimal untuk semua beban kerja serta memerlukan fine-tuning. Beberapa masalah mungkin tidak muncul pada tahap awal aplikasi ketika volume data masih kecil, tetapi dapat muncul seiring pertumbuhan data dan terpenuhinya kondisi tertentu.

Contention memori merupakan masalah umum. Dalam arsitektur MySQL, memori terutama digunakan untuk caching data. Area memori yang paling sering digunakan adalah buffer pool dan innodb_adaptive_hash_index. Area cache untuk seluruh sistem database merupakan tempat pertukaran data paling intensif. Jika memori tidak mencukupi atau terjadi contention halaman memori, berbagai exception dan slow query dapat menumpuk. Gejala khasnya adalah lonjakan tiba-tiba utilisasi CPU hingga mencapai level maksimum, disertai slow query. Jika investigasi menunjukkan bahwa masalah bukan disebabkan oleh indeks yang hilang, maka kemungkinan besar masalah terletak pada sistem memori.

Sebagai contoh, ketika operasi truncate table dilakukan, MySQL melakukan traversal pada buffer pool untuk menghapus semua halaman data dari tabel yang sedang truncated. Pada kluster berskala besar, jika innodb_buffer_pool_instances diatur ke 1 dan konkurensi relatif tinggi, masalah contention dapat terjadi. Masalah ini dapat terdeteksi sejak dini dalam siklus hidup layanan, dan biasanya dapat dihindari dengan menyelaraskan nilai innodb_buffer_pool_instances dengan jumlah core CPU serta mempartisi buffer pool ke dalam bucket.

Skenario lain adalah contention pada innodb_adaptive_hash_index. Gejala yang jelas adalah banyaknya wait hash0hash.cc.

SHOW ENGINE innodb STATUS;

Pada bagian AHI dari output, Anda akan melihat kesenjangan data yang signifikan.

insert 0, delete mark 0, delete 0
Hash table size 25499819, node heap has 20720 buffer(s)
Hash table size 25499819, node heap has 25111 buffer(s)
Hash table size 25499819, node heap has 23884 buffer(s)
Hash table size 25499819, node heap has 16835 buffer(s)
Hash table size 25499819, node heap has 23132 buffer(s)
Hash table size 25499819, node heap has 189284 buffer(s)
Hash table size 25499819, node heap has 38864 buffer(s)
Hash table size 25499819, node heap has 49094 buffer(s)
5469.32 hash searches/s, 5282.36 non-hash searches/s

Untuk jenis masalah ini, Anda dapat menonaktifkan parameter innodb_adaptive_hash_index, yang secara otomatis menonaktifkan fitur AHI. Data menunjukkan bahwa dalam skenario campuran baca-tulis, AHI dapat berdampak negatif pada performa, tetapi menonaktifkannya tidak secara signifikan memengaruhi bisnis secara keseluruhan.

System bugs

Bug sistem merupakan penyebab yang relatif jarang terjadi untuk masalah CPU tinggi. Contoh dari versi-versi sebelumnya termasuk deadlock proses dan full table scan yang disebabkan oleh statistik tabel yang di-reset ke nol. Seiring perkembangan produk, masalah CPU akibat bug sistem semakin jarang terjadi. Namun, troubleshooting masalah ini sering kali memerlukan informasi tingkat kernel yang mendalam dan sulit diselesaikan sendiri. Kami menyarankan Anda untuk menghubungi kami untuk dukungan teknis.