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:Sep 10, 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: Pada halaman Monitoring Information di 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 tersembunyi (hidden), dan satu atau beberapa node read-only opsional.

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

    Catatan

    Pemanfaatan CPU juga bergantung pada spesifikasi instans. Misalnya, jika sebuah instans dilengkapi 8 core CPU dan memori 16 GB serta memiliki pemanfaatan CPU 100%, artinya ke-8 core CPU tersebut telah habis digunakan. Dalam contoh ini, pemanfaatan CPU ditampilkan sebagai 100% dan 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 yang lebih lama. Jika permintaan tertunda atau kueri yang perlu memindai banyak dokumen bersifat sangat konkuren, maka akan 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 penuh (full collection scan)

      Jika Anda menemukan kata kunci COLLSCAN di log kueri lambat atau koleksi system.profile, berarti kueri tersebut 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 di mana 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 dinilai secara keliru, sehingga tidak mencapai kompromi terbaik.

    Konkurensi berlebihan

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

    Meskipun sebuah instans mendukung jumlah total koneksi maksimum yang tinggi, kapasitasnya untuk memproses koneksi aktif dibatasi oleh jumlah core CPU-nya. Ketika jumlah koneksi aktif melebihi jumlah core CPU, konflik sumber daya CPU dapat menyebabkan antrian thread dan penumpukan tugas. Hal ini dapat mengakibatkan respons yang lambat meskipun pemantauan melaporkan pemanfaatan CPU keseluruhan yang rendah.

    Penyebab lainnya

    • Banyak koneksi singkat dibuat. Pada versi MongoDB setelah 3.X, mekanisme otentikasi identitas default 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 dapat menguras seluruh 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 pada 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, Anda dapat mengabaikan pemanfaatan CPU tinggi pada node tersebut.

      MongoDB 3.2 dan versi setelahnya mendukung replikasi multi-threaded. Konkurensi replay oplog ditentukan oleh parameter replWriterThreadCount. Nilai default parameter ini adalah 16. Node secondary tidak menangani operasi write layanan apa pun. Namun, dalam beberapa skenario, pemanfaatan CPU node secondary dapat melebihi node primary. Misalnya, jika Anda mengonfigurasi penghapusan otomatis berbasis TTL untuk sebuah koleksi pada node primary, sistem akan menghapus data secara batch berdasarkan indeks pada kolom waktu, yang efisien. Sistem mengubah operasi tersebut menjadi banyak operasi penghapusan 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.

      Penghapusan TTL dapat menghapus ribuan dokumen kedaluwarsa per detik. Kenaikan pemanfaatan CPU dan I/O disk yang diakibatkannya merupakan beban yang diharapkan. Lakukan scale-up instans ketika workload membutuhkan kapasitas lebih besar, atau tunggu hingga pembersihan data terfragmentasi selesai lalu aktifkan balancer untuk menyeimbangkan ulang data.

      Untuk kluster sharded, lakukan investigasi lebih lanjut jika pemanfaatan CPU tidak menurun dan performa insert tidak membaik setelah dokumen yatim (orphaned documents) dibersihkan. Di CloudDBA atau metrik pemantauan, bandingkan cache kotor (dirty cache) dan laju penghapusan TTL setiap shard. Cache kotor yang tinggi dapat menyebabkan thread aplikasi ikut serta dalam flushing halaman kotor, sedangkan laju penghapusan TTL yang tidak biasa tinggi pada satu shard menunjukkan workload penghapusan yang tidak seimbang.

    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 terlalu banyak dokumen, 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 tidak selesai dalam periode eksekusi yang diharapkan. Untuk informasi lebih lanjut, lihat db.currentOp() dan db.killOp().

    Rekam 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 terlalu banyak dokumen yang dipindai.

    • 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 direkam.

      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 direkam dalam koleksi system.profile.

        • Profiling diaktifkan untuk kueri lambat. Kueri yang memakan waktu lebih lama dari ambang batas yang ditentukan direkam 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. Pada arsitektur dasarnya, 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 jumlah permintaan layanan dan tingkat konkurensi yang tinggi. Anda dapat menambahkan core CPU untuk mengatasi masalah pemanfaatan CPU tinggi ini. Dalam kebanyakan kasus, Anda dapat menggunakan salah satu metode berikut untuk menambahkan core CPU:

    • Lakukan scale-up pada satu instans untuk menangani workload baca/tulis yang lebih besar.

    • Konfigurasikan pemisahan baca/tulis di tingkat set replika, atau tambahkan instansi read-only ke set replika.

    • Upgrade instans bermasalah menjadi instans kluster sharded untuk skala keluar secara linear.

    • Jika CPU 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.

    Kontrol jumlah koleksi dan frekuensi eksekusi

    Kami menyarankan 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 Anda menggunakan koneksi persisten kapan pun memungkinkan.

    FAQ

    Mengapa pemanfaatan CPU meningkat setelah upgrade versi MongoDB?

    Upgrade versi dapat meningkatkan pemanfaatan CPU ketika parameter default berubah atau rencana kueri berubah. Gunakan langkah-langkah berikut untuk mengidentifikasi operasi yang terpengaruh dan mengoptimalkannya.

    1. Jalankan db.currentOp() di mongosh untuk mengidentifikasi permintaan yang berjalan lama atau abnormal. Jika dikembalikan opid yang abnormal, jalankan db.killOp(opid) untuk menghentikan operasi tersebut.

    2. Di Konsol ApsaraDB for MongoDB, buka halaman CloudDBA > Instance Sessions untuk menganalisis sesi aktif dan menemukan permintaan dengan waktu eksekusi yang tidak diharapkan.

    3. Buka halaman Log Management > Slow log untuk mengidentifikasi pemindaian koleksi atau kueri yang tidak menggunakan indeks. Optimalkan indeks berdasarkan hasil log kueri lambat.