Pemanfaatan CPU yang tinggi pada instans ApsaraDB for MongoDB dapat memperlambat kueri dan, jika tidak ditangani, menyebabkan instans berhenti melayani permintaan. Topik ini menjelaskan penyebab umum serta memberikan panduan langkah demi langkah, mulai dari penanganan darurat hingga solusi permanen.
Cara mengukur pemanfaatan CPU
Pantau pemanfaatan CPU dari halaman Monitoring Data di Konsol ApsaraDB for MongoDB. Untuk detail mengenai interval pemantauan dan cara mengakses halaman tersebut, lihat Pemantauan dasar.
Setiap jenis node dalam suatu instans memiliki metrik pemanfaatan CPU-nya sendiri:
Instans set replika — terdiri dari satu node primary, satu atau lebih node secondary, satu node hidden, dan opsional node read-only.
Instans kluster sharded — terdiri dari satu atau lebih komponen shard, komponen ConfigServer, dan satu atau lebih komponen mongos. Perilaku CPU komponen shard sama seperti instans set replika. ConfigServer hanya menyimpan metadata konfigurasi dan umumnya bukan bottleneck CPU. Pemanfaatan CPU mongos meningkat seiring dengan ukuran result-set agregasi dan jumlah permintaan konkuren.
Pemanfaatan CPU selalu ditampilkan sebagai persentase dari total core instans. Instans 8-core yang berjalan pada 100% berarti semua 8 core telah habis digunakan — metrik ini tidak pernah melebihi 100%.
Penyebab umum
Terlalu banyak dokumen dipindai
ApsaraDB for MongoDB menggunakan multi-threading. Ketika satu kueri memindai jumlah dokumen yang besar, thread-nya memegang sumber daya CPU lebih lama. Dalam kondisi konkurensi tinggi, hal ini menumpuk dan mendorong pemanfaatan CPU secara keseluruhan naik. Beban CPU total pada instans berkorelasi langsung dengan jumlah total dokumen yang dipindai oleh semua kueri.
Dua pola yang menyebabkan pemindaian dokumen berlebihan:
Pemindaian koleksi penuh (COLLSCAN)
Kemunculan COLLSCAN dalam log kueri lambat atau dalam koleksi system.profile berarti kueri tersebut membaca setiap dokumen dalam koleksi. Koleksi system.profile hanya dibuat ketika Anda mengaktifkan profiling database. Lihat Explain Results dan Cursor Methods untuk memahami rencana eksekusi kueri.
Penggunaan indeks tidak efisien (nilai `docsExamined` tinggi)
Ketika docsExamined melebihi 1.000 pada kueri yang sering dieksekusi, kueri tersebut perlu diperhatikan. Penyebab umum:
Banyak kondisi filter tanpa indeks gabungan atau tanpa memenuhi aturan awalan indeks.
Kueri kompleks atau pipeline agregasi berat yang menghambat penggunaan indeks secara efektif.
Bidang dengan distribusi data tidak merata (selektivitas rendah) digunakan sebagai filter kueri.
Konkurensi tinggi
Ketika jumlah permintaan konkuren memang tinggi dan tidak ada masalah kueri, kapasitas CPU tambahan diperlukan. Lihat Tambah kapasitas CPU.
Penyebab lainnya
Badai koneksi singkat
Pada versi MongoDB setelah 3.X, mekanisme autentikasi bawaan adalah SCRAM-SHA-1, yang memerlukan komputasi hash intensif-CPU per koneksi. Ketika banyak koneksi singkat dibuat secara bersamaan, beban hash bertambah dan dapat menghabiskan seluruh sumber daya CPU. Log operasional berisi banyak pesan error saslStart dalam skenario ini. ApsaraDB for MongoDB mengurangi beban tersebut di lapisan kernel dengan mengoptimalkan fungsi acak bawaannya.
Pemutaran ulang oplog indeks TTL pada node secondary
Ketika Anda menggunakan indeks time-to-live (TTL) untuk menghapus data, MongoDB mengubah operasi penghapusan tersebut menjadi beberapa entri oplog. Node secondary memutar ulang oplog ini menggunakan replikasi multi-threaded (dikendalikan oleh parameter replWriterThreadCount, yang bernilai default 16 pada MongoDB 3.2 dan versi setelahnya). Node secondary tidak menangani beban kerja write yang kritis bagi bisnis. Namun, pemutaran ulang oplog kurang efisien dibandingkan write aslinya, sehingga CPU node secondary bisa lebih tinggi daripada node primary. Dalam kasus ini, kami menyarankan agar Anda mengabaikan pemanfaatan CPU tinggi pada node tersebut.
Mengatasi pemanfaatan CPU tinggi
Gunakan tabel berikut untuk memilih alat yang tepat sesuai situasi Anda.
| Tujuan | Tool |
|---|---|
| Hentikan kueri lambat yang sedang berjalan | CloudDBA > Sessions di konsol, atau db.killOp() |
| Identifikasi kueri lambat setelah kejadian | Logs > Slow Query Logs |
| Audit semua permintaan (termasuk yang tidak lambat) | Data Security > Audit Logs |
Hentikan sesi aktif
Jika pemanfaatan CPU mendekati 100%, hentikan sesi yang menyebabkan lonjakan sebelum menyelidiki akar permasalahannya.
Opsi 1 — Konsol ApsaraDB for MongoDB (disarankan)
Di Konsol ApsaraDB for MongoDB, klik ID instans.
Di panel navigasi kiri, pilih CloudDBA > Sessions.
Tinjau sesi aktif, identifikasi operasi yang berjalan lebih lama dari yang diharapkan, lalu hentikan.
Halaman Sessions memungkinkan Anda melihat dan menghentikan operasi dalam antarmuka yang sama tanpa perlu akses shell. Ini merupakan opsi tercepat saat terjadi lonjakan CPU.
Opsi 2 — Shell MongoDB
Jalankan db.currentOp() untuk mencantumkan operasi aktif, lalu jalankan db.killOp() untuk menghentikan operasi tertentu. Untuk detail sintaksis, lihat db.currentOp() dan db.killOp().
Analisis log untuk menemukan akar permasalahan
Setelah menghentikan lonjakan langsung, identifikasi kueri yang memicunya.
Audit Logs
Di ApsaraDB for MongoDB console, pilih Data Security > Audit Logs untuk mengaktifkan pencatatan log audit. Untuk petunjuk penyiapan, lihat Aktifkan fitur log audit.
Slow Query Logs
Log kueri lambat disimpan selama tujuh hari. Jika instans Anda dibeli setelah 6 Juni 2021, aktifkan fitur log audit dan pilih tipe operasi admin dan slow sebelum Anda dapat melihat log kueri lambat. Hanya log yang dihasilkan setelah fitur diaktifkan yang tersedia.
Di konsol, pilih Parameters > Parameter List dan konfigurasikan parameter berikut: Kueri yang melebihi ambang batas akan dicatat dalam koleksi
system.profile. Untuk detail parameter, lihat Database Profiler.Parameter Deskripsi operationProfiling.modeMenetapkan level profiling: disabled (tidak ada data dikumpulkan), all requests (data direkam di system.profile), atau slow queries only (kueri yang melebihi ambang batas direkam di system.profile) operationProfiling.slowOpThresholdMsMenetapkan ambang batas dalam milidetik di atas mana kueri diklasifikasikan sebagai lambat Pilih Logs > Slow Query Logs untuk melihat log.
Dalam log, cari:
COLLSCAN— menunjukkan pemindaian koleksi penuh.Nilai
docsExaminedyang jauh lebih tinggi dari yang diharapkan — menunjukkan efisiensi indeks rendah.
Perbaiki pemanfaatan CPU tinggi
Optimalkan indeks
Optimalisasi indeks merupakan cara paling efektif untuk mengurangi jumlah dokumen yang dipindai per kueri. Mulailah dari kueri yang menunjukkan COLLSCAN atau nilai docsExamined tinggi.
Sumber daya untuk optimalisasi indeks:
Compound Indexes — untuk kueri dengan banyak kondisi filter
cursor.hint() — untuk memaksa penggunaan indeks tertentu
Buat Kueri yang Menjamin Selektivitas — untuk bidang dengan distribusi data tidak merata
Jika optimalisasi indeks saja tidak cukup, batasi volume data dalam koleksi yang terdampak atau kurangi frekuensi eksekusi pemindaian koleksi penuh.
Tambah kapasitas CPU
Jika kueri sudah dioptimalkan dengan baik dan CPU tetap tinggi karena volume traffic yang memang besar, lakukan scale up pada instans. Pendekatan umum:
Scale up instans untuk ruang headroom baca/tulis yang lebih besar.
Aktifkan pemisahan baca/tulis atau tambahkan node read-only pada instans set replika untuk mendistribusikan beban baca.
Upgrade ke instans kluster sharded untuk skala keluar linier di beberapa shard.
Tambahkan node mongos jika CPU habis pada tier mongos, dan konfigurasikan load balancing di antara node tersebut. Untuk detailnya, lihat bagian Balancer dalam pengenalan kluster sharded.
Untuk langkah-langkah mengubah konfigurasi instans, lihat:
Gunakan koneksi persisten
Koneksi singkat memicu autentikasi SCRAM-SHA-1 setiap kali terhubung, yang bersifat intensif-CPU dalam skala besar. Gunakan kolam koneksi dengan koneksi persisten untuk menghilangkan beban autentikasi per koneksi.