All Products
Search

This Product

    ApsaraDB for MongoDB:Pemanfaatan CPU tinggi pada instans ApsaraDB for MongoDB

    Document Center

    ApsaraDB for MongoDB:Pemanfaatan CPU tinggi pada instans ApsaraDB for MongoDB

    Last Updated:Aug 25, 2026

    Pemanfaatan CPU merupakan metrik pemantauan kritis untuk instans ApsaraDB for MongoDB. Pemanfaatan CPU yang terlalu tinggi memperlambat respons MongoDB dan bahkan dapat menyebabkan layanan tidak tersedia. Topik ini menjelaskan cara melihat pemanfaatan CPU suatu instans, penyebab umum pemanfaatan CPU tinggi, serta strategi optimasinya.

    Cara melihat pemanfaatan CPU

    Lihat grafik pemantauan: Di halaman Monitoring Information pada Konsol ApsaraDB for MongoDB, Anda dapat melihat pemanfaatan CPU instans ApsaraDB for MongoDB Anda. Untuk informasi lebih lanjut mengenai granularitas pengumpulan dan prosedurnya, lihat pemantauan dasar.

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

    • Instans set replika: terdiri dari satu node primary, satu atau beberapa node secondary, satu node hidden, dan satu atau beberapa node read-only opsional.

    • Pada arsitektur kluster sharded, penggunaan CPU setiap shard mirip dengan set replika. Configserver hanya menyimpan metadata konfigurasi dan jarang menyebabkan bottleneck CPU, sehingga umumnya dapat diabaikan. Pemanfaatan CPU pada node routing Mongos biasanya bergantung pada agregasi set hasil dan jumlah permintaan konkuren.

    Catatan

    Pemanfaatan CPU juga bergantung pada spesifikasi instans. Misalnya, jika suatu instans dilengkapi 8 core CPU dan memori 16 GB serta memiliki pemanfaatan CPU 100%, artinya ke-8 core CPU tersebut telah sepenuhnya digunakan. Dalam contoh ini, pemanfaatan CPU ditampilkan sebagai 100%, bukan 800%.

    Penyebab umum

    Dokumen yang dipindai berlebihan

    ApsaraDB for MongoDB mendukung multi-threading. Jika satu kueri perlu memindai jumlah dokumen yang besar, thread yang mengeksekusi kueri tersebut menggunakan sumber daya CPU dalam waktu lebih lama. Jika permintaan tertunda atau kueri yang memindai banyak dokumen bersifat sangat konkuren, maka terjadi pemanfaatan CPU tinggi pada instans tempat kueri tersebut dieksekusi. Pemanfaatan CPU suatu instans berkorelasi positif dengan total jumlah dokumen yang dipindai di instans tersebut. Kueri yang sering memindai banyak dokumen umumnya terjadi dalam skenario berikut:

    • Pemindaian koleksi lengkap

      Jika Anda menemukan kata kunci COLLSCAN di log kueri lambat atau koleksi system.profile, berarti suatu kueri melakukan pemindaian koleksi penuh. Anda harus mengaktifkan profiler database untuk menggunakan koleksi system.profile. Untuk informasi lebih lanjut tentang cara melihat log kueri lambat dan penggunaan profiler database, lihat Log kueri lambat.

      Untuk informasi lebih lanjut tentang cara menafsirkan rencana eksekusi kueri, lihat Explain Results dan Cursor Methods.

    • Desain dan Penggunaan Indeks yang Tidak Optimal

      Berikan perhatian khusus pada kueri yang sering dieksekusi dengan nilai docsExamined (jumlah dokumen yang dipindai) melebihi 1.000. Selain pemindaian koleksi penuh, situasi berikut juga dapat menyebabkan nilai docsExamined tinggi:

      • Saat menggunakan beberapa kondisi filter, indeks gabungan tidak digunakan atau prinsip pencocokan awalan (prefix matching) tidak terpenuhi.

      • Kueri bersifat kompleks atau melibatkan banyak operasi agregasi, yang dapat menghasilkan kebijakan parsing tidak valid atau indeks yang tidak dapat dioptimalkan.

      • Selektivitas data suatu bidang dan frekuensi eksekusinya salah dinilai, sehingga tidak mencapai kompromi terbaik.

    Konkurensi berlebihan

    Jika sejumlah besar permintaan layanan dikirim dan tingkat konkurensinya terlalu tinggi, maka pemanfaatan CPU akan tinggi. Untuk mengatasi masalah pemanfaatan CPU tinggi ini, Anda dapat menambahkan core CPU setelah memastikan tidak ada masalah pada kueri.

    Penyebab lainnya

    • Banyak koneksi singkat dibuat. Pada versi MongoDB 3.X ke atas, mekanisme otentikasi identitas bawaan adalah SCRAM-SHA1 yang memerlukan operasi intensif CPU seperti perhitungan hash. Jika koneksi singkat bersifat sangat konkuren, perhitungan hash akan menghabiskan sumber daya CPU berlipat ganda hingga menguras seluruh kapasitas CPU. Dalam kasus ini, log operasional berisi banyak pesan error saslStart. Untuk mengoptimalkan koneksi singkat PHP dalam skenario konkurensi tinggi, ApsaraDB for MongoDB mengoptimalkan metode dengan menulis ulang fungsi acak bawaan di lapisan kernel. Hal ini membantu mengurangi pemanfaatan CPU pada instans.

    • Indeks Time-to-live (TTL) menyebabkan pemanfaatan CPU node secondary lebih tinggi daripada node primary. Dalam kasus ini, kami menyarankan agar Anda mengabaikan pemanfaatan CPU tinggi pada node tersebut.

      MongoDB 3.2 ke atas mendukung replikasi multi-threaded. Konkurensi replay oplog ditentukan oleh parameter replWriterThreadCount. Nilai default parameter ini adalah 16. Node secondary tidak menangani operasi tulis layanan apa pun. Namun, dalam beberapa skenario pemanfaatan CPU node secondary dapat melebihi node primary. Misalnya, jika Anda mengonfigurasi penghapusan otomatis berbasis TTL untuk suatu koleksi di node primary, sistem akan menghapus data secara batch berdasarkan indeks pada kolom waktu, yang efisien. Sistem mengubah operasi tersebut menjadi banyak operasi hapus tunggal dan mengirimkannya ke node secondary. Di node secondary, replay oplog kurang efisien, sehingga replay multi-threaded dapat dengan mudah meningkatkan pemanfaatan CPU node tersebut.

    Metode pemecahan masalah

    Lihat dan hentikan sesi aktif

    Jika sesi instans yang berjalan normal tiba-tiba melonjak hingga 100%, penyebabnya biasanya perubahan di sisi aplikasi. Penyebab umum meliputi pemindaian dokumen berlebihan, pengurutan dan agregasi data, serta lonjakan lalu lintas layanan. Anda dapat memecahkan masalah tersebut sebagai berikut:

    • Di Konsol ApsaraDB for MongoDB, buka halaman CloudDBA > Instance Sessions untuk melihat sesi aktif. Analisis kueri yang memakan waktu lebih lama dari yang diharapkan dan hentikan sesi aktif tersebut atau ambil tindakan korektif lainnya.

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

    Catat dan lihat log

    Saat pemanfaatan CPU meningkat secara tidak normal, Anda dapat menganalisis log kueri lambat atau log audit untuk mengidentifikasi permintaan bermasalah. Periksa kata kunci seperti COLLSCAN dan docsExamined untuk memastikan apakah jumlah dokumen yang dipindai berlebihan.

    • Log audit

      Di Konsol ApsaraDB for MongoDB, buka halaman Data Security > Audit Log untuk mengaktifkan dan melihat log audit. Untuk informasi lebih lanjut tentang cara mengaktifkan dan menggunakan fitur ini, lihat Aktifkan fitur log audit.

    • Log kueri lambat

      Penting

      • Anda hanya dapat melihat log kueri lambat tujuh hari terakhir.

      • Untuk instans yang dibeli setelah 6 Juni 2021, Anda harus terlebih dahulu mengaktifkan fitur log audit dan mengatur jenis operasi yang diaudit agar mencakup admin dan slow. Setelah itu, Anda dapat melihat log kueri lambat. Hanya kueri lambat yang terjadi setelah log audit diaktifkan yang dicatat.

      1. Di Konsol ApsaraDB for MongoDB, buka halaman Parameter Settings > Parameter List. Konfigurasikan parameter operationProfiling.mode (mode kueri lambat) dan operationProfiling.slowOpThresholdMs (ambang batas kueri lambat) sesuai kebutuhan bisnis Anda.

        MongoDB menyediakan tiga mode profiling:

        • Profiling dinonaktifkan dan tidak ada data yang dikumpulkan.

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

        • Profiling diaktifkan untuk kueri lambat. Kueri 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. Di halaman Log Management > Slow log, lihat log kueri lambat.

    Strategi optimasi

    Optimalkan indeks

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

    Untuk informasi lebih lanjut tentang cara membuat dan menggunakan indeks, lihat Praktik terbaik pembuatan indeks di ApsaraDB for MongoDB atau dokumen resmi berikut:

    Tambahkan core CPU

    Jika Anda memastikan tidak ada masalah pada kueri, pemanfaatan CPU tinggi disebabkan oleh volume permintaan layanan dan tingkat konkurensi yang tinggi. Anda dapat menambahkan core CPU untuk mengatasi masalah pemanfaatan CPU tinggi tersebut. Dalam kebanyakan kasus, Anda dapat menggunakan salah satu metode berikut untuk menambahkan core CPU:

    • Scale up instans tunggal untuk beban kerja baca/tulis yang lebih besar.

    • Konfigurasikan pemisahan baca/tulis di tingkat set replika, atau tambahkan instans hanya baca ke set replika.

    • Upgrade instans bermasalah ke instans kluster sharded untuk skala keluar linier.

    • Jika CPU pada node routing Mongos habis, tambahkan node Mongos dan konfigurasikan load balancing untuk node tersebut. Untuk informasi lebih lanjut tentang load balancing node Mongos, lihat Load balancing.

    Untuk informasi lebih lanjut tentang cara mengubah konfigurasi instans ApsaraDB for MongoDB, lihat Ubah konfigurasi instans mandiri, Ubah konfigurasi instans set replika, dan Ubah konfigurasi instans kluster sharded.

    Kendalikan jumlah koleksi dan frekuensi eksekusi

    Kami menyarankan agar Anda terlebih dahulu menambahkan indeks untuk mengoptimalkan pemindaian koleksi penuh. Jika metode ini tidak lagi membantu, kendalikan volume data koleksi dan frekuensi eksekusi di sisi aplikasi.

    Hindari koneksi singkat yang sering

    Kami menyarankan agar Anda sedapat mungkin menggunakan koneksi persisten.