Pemanfaatan CPU tinggi pada cluster PolarDB untuk MySQL -

Sumber daya CPU sangat penting bagi database dan menjadi pertimbangan utama dalam operasi pemeliharaan harian. Pemanfaatan CPU tinggi dapat menyebabkan waktu respons aplikasi yang tinggi, performa tersendat, bahkan hang cluster dan pergantian HA. Hal ini dapat berdampak serius pada bisnis. Oleh karena itu, ambang batas harus ditetapkan untuk pemantauan CPU, dan tindakan segera harus diambil ketika ambang tersebut tercapai guna menghindari konsekuensi serius.

Langkah-langkah penanggulangan terhadap pemanfaatan CPU tinggi

Seiring dengan pertumbuhan bisnis, cluster Anda mungkin tidak lagi memenuhi persyaratan. Lalu lintas jaringan yang meningkat mendorong naiknya penggunaan cluster dan pemanfaatan CPU. Dalam kurva performa, data deret waktu (QPS atau IOPS) menunjukkan tren naik, sesuai dengan tren kenaikan pemanfaatan CPU.

Jika CPU mencapai titik hambatan, spesifikasi cluster saat ini tidak cukup. Anda harus menambahkan node baca-saja ke cluster atau meningkatkan skala cluster.

Catatan

Jika cluster Anda tidak dapat dihubungkan atau pernyataan DML yang sedang berjalan gagal, periksa apakah sumber daya CPU cluster mencukupi. Jika tidak, tingkatkan skala cluster untuk memastikan stabilitas sistem.

Jika sebagian besar skenario bisnis melibatkan permintaan baca, Anda dapat menambahkan node baca-saja untuk mendistribusikan permintaan baca. Untuk informasi lebih lanjut, lihat Tambah atau Hapus Node Baca-Saja.
Jika sebagian besar skenario bisnis melibatkan permintaan tulis, menambahkan node baca-saja tidak akan meningkatkan performa. Anda harus meningkatkan skala cluster, misalnya, mengubah spesifikasi dari 4-core menjadi 8-core. Untuk informasi lebih lanjut, lihat Ubah Spesifikasi Cluster secara Manual.

Peningkatan tak terduga dalam pemanfaatan CPU

Banyak alasan dapat menyebabkan peningkatan tak terduga dalam pemanfaatan CPU. Topik ini berfokus pada kueri lambat, banyak thread aktif, konfigurasi kernel yang tidak tepat, dan bug sistem.

Slow queries
Peningkatan pemanfaatan CPU umumnya disebabkan oleh pernyataan SQL yang tidak optimal, yang mengakibatkan kueri lambat dan ledakan thread aktif. Namun, Anda harus membedakan apakah pemanfaatan CPU tinggi adalah hasil dari kueri lambat atau apakah sumber daya lain yang tidak mencukupi menyebabkan kueri lambat dan pemanfaatan CPU tinggi.
Di halaman Slow SQL Query pada PolarDB console, lihat informasi tentang kueri lambat. Untuk informasi lebih lanjut, lihat Kueri SQL Lambat.
Jika data kueri lambat ditampilkan, Anda dapat menganalisis kueri lambat. Jika nilai kolom Scanned Rows di tab Slow Log Details jauh lebih besar daripada nilai kolom Returned Rows, pemanfaatan CPU tinggi disebabkan oleh kueri lambat.
Catatan
Anda terutama menganalisis kueri TP dan harus mengecualikan kueri count. Beberapa kueri AP memiliki nilai besar di kolom Scanned Rows.
Hanya sejumlah kecil data yang dibaca dan ditulis dalam kueri TP. Jika kueri memindai sejumlah besar data, kemungkinan besar tidak ada indeks yang dibuat. Misalnya, jika jumlah baris yang dipindai lebih dari 10.000 dan jumlah baris yang dikembalikan adalah 1 setelah Anda menjalankan pernyataan kueri berikut, indeks hilang untuk kolom name.
```
SELECT * FROM table1 WHERE name='testname';
```
Anda dapat menjalankan pernyataan berikut untuk memeriksa apakah indeks dibuat untuk kolom name:
```
SHOW index FROM table1;
```
- Jika kolom name tidak memiliki indeks, Anda dapat menjalankan pernyataan berikut untuk menambahkan kolom kunci indeks dan menghilangkan kueri lambat yang disebabkan oleh pemindaian data tinggi:
```
ALTER TABLE table1 ADD KEY ix_name (name);
```
- Jika kolom name memiliki indeks, Anda dapat menjalankan pernyataan berikut untuk melihat rencana eksekusi pernyataan SQL dan memeriksa apakah indeks digunakan:
```
EXPLAIN SELECT * FROM table1 WHERE name='testname';
```
  Jika kolom name memiliki indeks tetapi indeks tidak digunakan, kemungkinan alasannya adalah bahwa rencana eksekusi yang salah dihasilkan karena statistik yang tidak akurat. Anda dapat menjalankan pernyataan berikut untuk meregenerasi statistik pada tabel dan memperbaiki rencana eksekusi:
```
ANALYZE TABLE table1;
```
  Setelah pernyataan di atas dijalankan, jalankan pernyataan berikut untuk memeriksa apakah indeks yang benar digunakan:
```
EXPLAIN SELECT * FROM table1 WHERE name='testname';
```
Lots of active threads
Sejumlah besar thread aktif pasti menyebabkan pemanfaatan CPU tinggi. Dalam implementasi MySQL, setiap CPU hanya dapat memproses satu permintaan pada satu waktu. Misalnya, cluster dengan spesifikasi 16-core dapat memproses hingga 16 permintaan pada satu waktu. Perlu dicatat bahwa permintaan di sini berada pada level kernel, bukan dalam hal konkurensi aplikasi. Lihat detail sesi di halaman Diagnostics and Optimization > Quick Diagnostics > Session Management di PolarDB console.
Kecuali permintaan luar biasa yang disebabkan oleh kueri lambat, thread aktif melonjak dengan meningkatnya lalu lintas jaringan. Jika tren lalu lintas keseluruhan dan permintaan konsisten dengan tren akumulasi thread aktif, semua sumber daya cluster telah digunakan. Dalam hal ini, Anda harus menambahkan node baca-saja ke cluster atau meningkatkan skala cluster.
Ketika thread aktif mencapai tingkat kritis, terjadi perebutan CPU. Sejumlah besar mutex lock dihasilkan di kernel. Dalam hal ini, kurva performa ditandai dengan pemanfaatan CPU tinggi, thread aktif tinggi, dan I/O rendah atau QPS rendah. Puncak bisnis juga dapat terjadi. Koneksi dibentuk dengan kecepatan sangat tinggi. Perebutan CPU mengakibatkan akumulasi permintaan. Anda dapat mengaktifkan fitur thread_pool untuk cluster untuk mengurangi masalah ini. Untuk informasi lebih lanjut, lihat Thread Pool. Jika jumlah thread aktif berkurang, periksa apakah permintaan menumpuk di sisi aplikasi. Jika beban CPU tinggi bertepatan dengan lonjakan thread aktif, Anda harus mempertimbangkan apakah akan meningkatkan skala cluster.
Jika badai koneksi di frontend menyebabkan akumulasi permintaan mendadak di sisi cluster, terjadi lalu lintas luar biasa. Ini umumnya berasal dari crawling data. Dalam hal ini, Anda dapat mengaktifkan Pembatasan SQL untuk menolak permintaan. Untuk informasi lebih lanjut, lihat Manajemen Sesi.
Inappropriate kernel configurations
Nilai default parameter PolarDB dirancang untuk skenario umum. Mereka mungkin tidak cocok untuk bisnis khusus. Anda dapat mengubah nilai parameter PolarDB. Beberapa masalah mungkin tidak terjadi pada tahap awal ketika hanya sejumlah kecil data terlibat, tetapi muncul seiring dengan peningkatan volume data.
Masalah umum adalah perebutan memori. Di MySQL, memori terutama digunakan untuk caching data. Data di memori terus diiterasi. Secara umum, buffer pool dan innodb_adaptive_hash_index menggunakan memori. Di seluruh sistem database, area cache menangani pertukaran data yang paling sering. Memori yang tidak mencukupi dan perebutan halaman memori dapat mengakibatkan akumulasi data dan kueri lambat. Gejala khasnya adalah CPU habis dan terjadi kueri lambat. Jika masalah ini tidak disebabkan oleh indeks yang hilang, itu disebabkan oleh perebutan memori.
Sebagai contoh, ketika Anda menjalankan pernyataan truncate table, MySQL memindai buffer pool untuk mengeluarkan semua halaman data dari tabel yang akan dipotong. Dalam cluster dengan spesifikasi tinggi, jika parameter the innodb_buffer_pool_instances diatur ke 1 dan konkurensi relatif tinggi, perebutan mungkin terjadi. Masalah ini mungkin ditemukan pada tahap awal. Solusi termasuk mengatur parameter innodb_buffer_pool_instances ke jumlah core CPU dan membagi buffer pool menjadi bucket.
Skenario lain adalah perebutan memori untuk innodb_adaptive_hash_index. Gejalanya adalah sejumlah besar hash0hash.cc menunggu terjadi ketika Anda menjalankan pernyataan berikut:
```
SHOW ENGINE innodb STATUS;
```
Di bidang AHI, skew data yang jelas terjadi.
Untuk masalah ini, Anda dapat mengatur parameter innodb_adaptive_hash_index ke off untuk menonaktifkan fitur AHI. Fitur AHI juga dapat menurunkan performa dalam skenario baca dan tulis. Menonaktifkan fitur AHI memiliki sedikit dampak pada bisnis secara keseluruhan.
System bugs
Bug sistem sangat jarang. Misalnya, deadlock proses dan pemindaian tabel penuh yang disebabkan oleh reset statistik tabel dapat menyebabkan pemanfaatan CPU tinggi. Dengan iterasi cepat layanan, masalah CPU yang disebabkan oleh bug sistem menjadi semakin jarang. Anda mungkin mengalami kesulitan dalam pemecahan masalah karena informasi kernel terlibat. Kami sarankan Anda Submit a ticket untuk menghubungi dukungan teknis Alibaba Cloud untuk pemecahan masalah.