:Utilisasi CPU tinggi di PolarDB for MySQL

Slow queries

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

Anda dapat melihat kueri lambat di PolarDB console dengan menavigasi ke Diagnostics and Optimization > Slow SQL. Pada tab Slow Log Details, jika nilai untuk Scanned Rows secara signifikan lebih tinggi dari nilai untuk Returned Rows, ini menunjukkan bahwa kueri lambat menyebabkan utilisasi CPU yang tinggi.

Kueri TP melibatkan volume baca/tulis data yang sangat kecil. Jika suatu kueri memindai volume data yang besar, kemungkinan besar indeks tidak tersedia. Misalnya, jika kueri dalam daftar kueri lambat 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 kueri lambat akibat 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';

FAQ: Mengapa pernyataan SQL identik dan volume pemindaian yang sama menghasilkan penggunaan CPU yang sangat berbeda di kluster PolarDB yang berbeda?

Kejenuhan CPU biasanya disebabkan oleh permintaan lambat. Meskipun teks SQL dan volume pemindaian teoretis tampak identik di kluster berbeda, perilaku eksekusi aktualnya mungkin berbeda. Selidiki area berikut:

1. Bandingkan detail log kueri lambat aktual: Tinjau dan bandingkan log kueri lambat kedua kluster untuk memastikan apakah jumlah baris yang dipindai, baris yang dikembalikan, dan waktu eksekusi berbeda. Pernyataan SQL yang sama dapat memiliki rencana eksekusi berbeda atau menghadapi distribusi data berbeda di kluster yang berbeda.

2. Periksa perbedaan arsitektur kluster: Verifikasi apakah kluster dengan beban tinggi memiliki lebih sedikit node read-only dibandingkan kluster dengan beban rendah. Jika permintaan baca tidak dialihkan ke node read-only, node primary menanggung beban lebih berat, sehingga menyebabkan penggunaan CPU lebih tinggi.

3. Rekomendasi optimasi: Untuk mencegah kejenuhan CPU, fokuslah pada optimasi permintaan lambat dan kurangi jumlah baris yang benar-benar dipindai oleh pernyataan SQL, bukan hanya memeriksa apakah teks SQL identik.

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 di level kernel, yang berbeda dari konkurensi di level aplikasi. Anda dapat melihat informasi session di PolarDB console dengan menavigasi ke Diagnostics and Optimization > One-click diagnosis > Sessions.

Jika Anda telah menyingkirkan kueri lambat sebagai penyebab kegagalan pemrosesan permintaan, akumulasi thread aktif biasanya disebabkan oleh peningkatan traffic produksi. Anda dapat melihat kurva performa untuk memverifikasi hal ini. Jika tren traffic keseluruhan dan permintaan konsisten dengan tren akumulasi 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 scaling up spesifikasi kluster.

Saat 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 traffic 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 perlu mempertimbangkan scaling up kluster.

Badai koneksi frontend juga dapat menyebabkan lonjakan traffic instan pada kluster. Ini merupakan traffic abnormal, sering kali disebabkan oleh perayap web. Anda dapat menggunakan Pembatasan SQL untuk menolak permintaan. Untuk informasi lebih lanjut, lihat Session Management.

Improper kernel configuration

Parameter default untuk instans MySQL yang dikelola sendiri dikonfigurasi untuk skenario umum dan mungkin tidak optimal untuk semua workload 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, akumulasi berbagai exception dan kueri lambat dapat terjadi. Gejala khasnya adalah lonjakan tiba-tiba pada penggunaan CPU hingga mencapai level maksimum, disertai kueri lambat. Jika investigasi menunjukkan bahwa masalah bukan karena indeks yang hilang, maka kemungkinan besar masalah terletak pada sistem memori.

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

Skenario lain adalah contention pada innodb_adaptive_hash_index. Gejala jelasnya 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 baca/tulis campuran, AHI dapat berdampak negatif pada performa, tetapi menonaktifkannya tidak secara signifikan memengaruhi bisnis secara keseluruhan.

Memory resource anomaly causing high CPU or primary/standby switchover

Anomali sumber daya memori dapat secara tidak langsung menyebabkan penggunaan CPU tinggi, crash instans, atau alih bencana primary/standby. Skenario berikut mencakup penyebab umum, termasuk memori mencapai 100%, event kehabisan memori (OOM), crash, alih bencana primary/standby, event HA, pernyataan Prepare yang tidak ditutup, pernyataan SQL panjang, Pemicu, dan masalah Query Parser.

Skenario 1: OOM (kehabisan memori) menyebabkan crash instans

Penyebab: Koneksi berlebihan (jumlah besar koneksi idle) dan pernyataan Prepare yang tidak segera ditutup menyebabkan penggunaan memori berlebihan, yang akhirnya memicu event OOM dan menyebabkan instans crash.

Solusi:

• Di sisi aplikasi, segera recycle koneksi idle.

• Tutup pernyataan Prepare tepat waktu dan selidiki akar penyebab inisiasi Prepare konkuren.

• Lakukan peningkatan ke versi mesin minor yang lebih baru selama jam sepi untuk memanfaatkan optimasi memori di level kernel.

• Coba kurangi nilai parameter innodb_buffer_pool_size dan amati apakah masalah membaik.

Skenario 2: Konsentrasi memori Query Parser menyebabkan pertumbuhan memori berkelanjutan atau alih bencana primary/standby

Penyebab: Pernyataan SQL panjang dan Pemicu besar menyebabkan konsumsi memori Parser yang tinggi. Perhatikan hal berikut:

• Meskipun pernyataan SQL tertentu telah dioptimalkan atau tidak diarahkan ke node tulis, pernyataan SQL panjang atau Pemicu lainnya masih dapat memicu masalah ini.

• Operasi DML harus dieksekusi di node primary, terlepas dari konfigurasi Pemisahan baca/tulis apa pun.

Solusi:

• Pecah pernyataan SQL panjang menjadi beberapa pernyataan yang lebih pendek.

• Optimalkan Pemicu atau kurangi panjangnya.

• Kontrol panjang SQL di level aplikasi.

• Jika perlu, tingkatkan spesifikasi instans atau sesuaikan parameter innodb_buffer_pool_size.

Skenario 3: SQL pemindaian besar menyebabkan memori mencapai 100% dan memicu alih bencana primary/standby (tidak tercermin dalam laporan diagnostik)

Penyebab: Pernyataan SQL pemindaian besar—seperti kueri dengan kondisi kompleks atau agregasi COUNT—mengonsumsi volume memori besar. Pernyataan ini mungkin tidak muncul dalam laporan diagnostik, sehingga lebih sulit dideteksi.

Solusi:

• Analisis log kueri lambat untuk mengidentifikasi pernyataan SQL pemindaian besar tertentu.

• Optimalkan pernyataan SQL yang teridentifikasi dengan menambahkan indeks yang sesuai atau menulis ulang kueri tersebut.

System bugs

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