全部产品
Search

搜索本产品

    ApsaraDB for MongoDB：Memecahkan masalah penggunaan CPU tinggi pada instans

    文档中心

    ApsaraDB for MongoDB：Memecahkan masalah penggunaan CPU tinggi pada instans

    更新时间：Jul 02, 2025

    Penggunaan CPU merupakan metrik utama dalam memantau instans ApsaraDB untuk MongoDB. Jika penggunaan CPU terlalu tinggi, instans mungkin merespons lambat atau bahkan gagal menyediakan layanan. Topik ini menjelaskan cara melihat penggunaan CPU dari instans ApsaraDB untuk MongoDB dan menyelesaikan masalah penggunaan CPU tinggi.

    Metode akses

    Lihat Penggunaan CPU di Grafik Pemantauan: Di halaman Monitoring Data dari instans ApsaraDB untuk MongoDB di Konsol ApsaraDB untuk MongoDB, Anda dapat melihat penggunaan CPU instans dalam grafik pemantauan. Untuk informasi lebih lanjut tentang interval pemantauan dan prosedur, lihat Pemantauan Dasar.

    ApsaraDB untuk MongoDB menyediakan berbagai kombinasi node untuk arsitektur instans. Anda dapat memilih node untuk melihat penggunaan CPU-nya.

    • Instans Set Replika: Set replika terdiri dari node primer, satu atau lebih node sekunder, node tersembunyi, dan satu atau lebih node baca-saja opsional.

    • Instans Kluster Sharded: Kluster sharded terdiri dari satu atau lebih komponen shard, komponen ConfigServer, dan satu atau lebih komponen mongos. Konsumsi CPU komponen shard sama dengan instans set replika. Komponen ConfigServer kebal terhadap sebagian besar hambatan CPU karena hanya menyimpan metadata konfigurasi. Penggunaan CPU komponen mongos bergantung pada set hasil agregasi dan jumlah permintaan bersamaan.

    Catatan

    Penggunaan CPU juga bergantung pada spesifikasi instans. Misalnya, jika instans dilengkapi dengan 8 core CPU dan 16 GB memori serta memiliki penggunaan CPU 100%, maka semua 8 core CPU telah digunakan sepenuhnya. Dalam contoh ini, penggunaan CPU ditampilkan sebagai 100%, bukan 800%.

    Penyebab umum

    Dokumen yang dipindai berlebihan

    ApsaraDB untuk MongoDB mendukung multi-threading. Jika satu query perlu memindai sejumlah besar dokumen, thread yang mengeksekusi query tersebut akan menggunakan sumber daya CPU dalam waktu yang lebih lama. Jika permintaan tertunda atau query yang perlu memindai sejumlah besar dokumen berada dalam konkurensi tinggi, penggunaan CPU tinggi terjadi pada instans tempat query dieksekusi. Penggunaan CPU instans berkaitan positif dengan total jumlah dokumen yang dipindai dalam instans. Query yang sering perlu memindai sejumlah besar dokumen umum ditemukan dalam skenario berikut:

    • Pemindaian Koleksi Penuh

      Jika Anda menemukan kata kunci COLLSCAN dalam log query lambat atau koleksi bernama system.profile, pemindaian koleksi penuh dilakukan dalam sebuah query. Sistem secara otomatis membuat koleksi tersebut hanya jika Anda mengaktifkan profiling database. Untuk informasi lebih lanjut tentang cara melihat log query lambat dan mengonfigurasi profiling database, lihat Log Query Lambat.

      Untuk informasi lebih lanjut tentang cara memeriksa rencana eksekusi, lihat Hasil Penjelasan dan Metode Kursor.

    • Desain dan Penggunaan Indeks yang Tidak Optimal

      Jika nilai kata kunci docsExamined lebih besar dari 1.000 dalam sebuah query dan query tersebut sering dieksekusi, Anda harus fokus pada query tersebut. Kata kunci ini menunjukkan jumlah dokumen yang dipindai dalam sebuah query. Selain pemindaian koleksi penuh, skenario berikut menyebabkan nilai besar untuk kata kunci docsExamined:

      • Ketika beberapa kondisi filter digunakan, indeks gabungan tidak digunakan atau prinsip pencocokan awalan tidak dipenuhi.

      • Query kompleks atau melibatkan banyak operasi agregasi, yang dapat menghasilkan kebijakan penguraian yang tidak valid atau indeks yang tidak dapat dioptimalkan.

      • Selektivitas data dari suatu bidang data tidak seimbang dengan frekuensi pemilihan.

    Konkurensi berlebihan

    Jika sejumlah besar permintaan layanan dikirim dan konkurensi terlalu tinggi, penggunaan CPU menjadi tinggi. Untuk menyelesaikan masalah penggunaan CPU tinggi ini, Anda dapat menambah core CPU jika Anda yakin tidak ada masalah query.

    Penyebab lainnya

    • Sejumlah Besar Koneksi Singkat Dibuat

    • Indeks TTL menyebabkan penggunaan CPU lebih tinggi pada node sekunder dibandingkan node primer. Dalam situasi ini, kami menyarankan Anda untuk mengabaikan penggunaan CPU yang tinggi pada node tersebut.

      MongoDB 3.2 dan versi berikutnya mendukung replikasi multi-threaded. Konkurensi rollback oplog ditentukan oleh parameter replWriterThreadCount, dengan nilai default sebesar 16. Node sekunder tidak menangani beban kerja tulis yang krusial untuk bisnis, namun penggunaan CPU pada node sekunder bisa lebih tinggi dibandingkan node primer. Sebagai contoh, jika Anda menggunakan TTL untuk menghapus data dalam koleksi saat data kedaluwarsa, sistem dapat menghapus sejumlah besar data secara efisien berdasarkan indeks pada kolom waktu. Sistem mengonversi operasi hapus menjadi beberapa operasi hapus, lalu mengirimkannya ke node sekunder. Pada node sekunder, rollback oplog kurang efisien. Rollback multi-threaded oplog dapat meningkatkan penggunaan CPU pada node tersebut.

    Pemecahan masalah

    Lihat dan hentikan sesi aktif

    Sesi melonjak dari instans dalam status Running dapat mengonsumsi 100% sumber daya CPU. Dalam kasus ini, penggunaan CPU tinggi mungkin disebabkan oleh perubahan lalu lintas bisnis. Penyebab lain yang mungkin termasuk pemindaian yang melibatkan sejumlah besar dokumen, pengurutan dan agregasi data, serta lonjakan lalu lintas bisnis. Anda dapat menggunakan salah satu metode berikut untuk memecahkan masalah penggunaan CPU tinggi:

    • Di Konsol ApsaraDB untuk MongoDB, klik ID instans yang ingin Anda kelola. Di panel navigasi di sebelah kiri, pilih CloudDBA > Sessions. Di halaman yang muncul, lihat sesi aktif saat ini, analisis operasi query yang belum selesai dalam periode eksekusi yang diharapkan, dan kemudian hentikan sesi aktif yang abnormal. Anda juga dapat menggunakan metode tambahan untuk menyelesaikan masalah penggunaan CPU tinggi.

    • Untuk melihat dan menganalisis detail sesi aktif, jalankan perintah db.currentOp() yang disediakan oleh MongoDB. Jika perlu, jalankan perintah db.killOp() untuk secara aktif menghentikan query lambat yang belum selesai dalam periode eksekusi yang diharapkan. Untuk informasi lebih lanjut, lihat db.currentOp() dan db.killOp().

    Catat dan lihat log

    Jika penggunaan CPU meningkat secara tidak normal, Anda dapat menggunakan log audit atau log query lambat untuk menganalisis permintaan abnormal. Lihat kata kunci seperti COLLSCAN dan docsExamined untuk memeriksa apakah jumlah dokumen yang dipindai terlalu besar.

    • Log Audit

      Buka Konsol ApsaraDB untuk MongoDB dan kemudian pilih Data Security > Audit Logs untuk mengaktifkan fitur log audit. Untuk informasi lebih lanjut tentang cara mengaktifkan dan menggunakan fitur ini, lihat Aktifkan Fitur Log Audit.

    • Log Query Lambat

      Penting

      • Periode retensi log query lambat adalah tujuh hari.

      • Jika instans Anda dibeli setelah 6 Juni 2021 dan Anda ingin melihat log query lambat dari instans tersebut, Anda harus mengaktifkan fitur log audit dan memilih tipe operasi admin dan slow yang ingin Anda audit. Anda hanya dapat melihat log query lambat yang dihasilkan setelah fitur log audit diaktifkan.

      1. Buka Konsol ApsaraDB untuk MongoDB dan kemudian pilih Parameters > Parameter List. Anda dapat mengonfigurasi parameter operationProfiling.mode dan parameter operationProfiling.slowOpThresholdMs di tab Daftar Parameter. Parameter operationProfiling.mode menentukan level profiling. Parameter operationProfiling.slowOpThresholdMs menentukan ambang batas query lambat.

        ApsaraDB untuk MongoDB memungkinkan Anda menggunakan level profiling berikut:

        • Profiling dinonaktifkan dan tidak ada data yang dikumpulkan.

        • Profiling diaktifkan untuk semua permintaan. Data eksekusi dari semua permintaan dicatat dalam koleksi system.profile.

        • Profiling diaktifkan untuk query lambat. Query yang memakan waktu lebih lama dari ambang batas yang ditentukan dicatat dalam koleksi system.profile.

        Untuk informasi lebih lanjut tentang parameter profiling, lihat Database Profiler.

      2. Pilih Logs > Slow Query Logs untuk melihat log query lambat.

    Kebijakan optimasi

    Optimalkan indeks

    Optimasi indeks adalah solusi terbaik untuk mengurangi jumlah dokumen yang perlu dipindai oleh satu query. Di arsitektur dasar, ApsaraDB untuk MongoDB menggunakan desain indeks yang mirip dengan MySQL dan menyediakan kategori dan fitur yang lebih kaya daripada MySQL. Oleh karena itu, sebagian besar kebijakan optimasi indeks yang berlaku untuk MySQL juga berlaku untuk ApsaraDB untuk MongoDB.

    Untuk informasi lebih lanjut tentang cara membuat dan menggunakan indeks, lihat Praktik Terbaik untuk Membuat Indeks di ApsaraDB untuk MongoDB atau dokumen resmi berikut:

    Tambah core CPU

    Jika Anda yakin tidak ada masalah query, penggunaan CPU tinggi disebabkan oleh jumlah permintaan layanan yang tinggi dan konkurensi yang tinggi. Anda dapat menambah core CPU untuk menyelesaikan masalah penggunaan CPU tinggi. Dalam sebagian besar kasus, Anda dapat menggunakan salah satu metode berikut untuk menambah core CPU:

    • Tingkatkan instans tunggal untuk beban kerja baca dan tulis yang lebih besar.

    • Konfigurasikan pembagian baca/tulis untuk instans set replika atau tambahkan node baca-saja ke instans.

    • Tingkatkan instans bermasalah ke instans kluster sharded untuk penskalaan linear.

    • Jika sumber daya CPU pada node mongos habis, Anda harus menambah node mongos dan mengonfigurasi penyeimbangan beban untuk node tersebut. Untuk informasi lebih lanjut, lihat bagian Balancer dari topik "Pengenalan Instans Kluster Sharded ApsaraDB untuk MongoDB".

    Untuk informasi lebih lanjut tentang cara mengubah konfigurasi instans ApsaraDB untuk MongoDB, lihat Ubah Konfigurasi Instans Mandiri, Ubah Konfigurasi Instans Set Replika, dan Ubah Konfigurasi Instans Kluster Sharded.

    Batasi jumlah koleksi dan frekuensi eksekusi

    Kami sarankan Anda menambahkan indeks untuk mengoptimalkan pemindaian koleksi penuh. Jika metode ini tidak bekerja dengan baik, kami sarankan Anda membatasi volume data koleksi dan frekuensi eksekusi pemindaian koleksi penuh di sisi bisnis.

    Minimalkan jumlah koneksi singkat

    Kami sarankan Anda menggunakan koneksi persisten.