All Products
Search
Document Center

ApsaraDB for MongoDB:Memecahkan masalah penggunaan memori tinggi di ApsaraDB for MongoDB

Last Updated:May 15, 2026

Penggunaan memori merupakan metrik kritis untuk instans ApsaraDB for MongoDB. Topik ini menjelaskan cara memeriksa penggunaan memori instans ApsaraDB for MongoDB, merinci penyebab umum penggunaan memori tinggi, serta menyediakan strategi optimasi.

Informasi latar belakang

Saat proses ApsaraDB for MongoDB dimulai, file biner dan pustaka sistem dependen dimuat ke dalam memori serta mengelola alokasi dan dealokasi memori untuk tugas-tugas seperti manajemen koneksi client, pemrosesan permintaan, dan storage engine. Secara default, ApsaraDB for MongoDB menggunakan tcmalloc dari Google sebagai allocator memorinya. Memori terutama dikonsumsi oleh WiredTiger storage engine dan oleh koneksi client serta pemrosesan permintaan.

Periksa penggunaan memori

  • Analisis grafik pemantauan

    Anda dapat melihat penggunaan memori ApsaraDB for MongoDB pada halaman Monitoring Information di Konsol ApsaraDB for MongoDB. Komposisi node instans ApsaraDB for MongoDB bervariasi berdasarkan arsitektur instans. Anda dapat memilih node tertentu untuk melihat penggunaan memorinya.

    • Arsitektur replica set: Terdiri dari satu node primary, satu atau lebih node secondary, satu node hidden, dan opsional satu atau lebih node read-only.

    • Arsitektur sharded cluster: Penggunaan memori setiap shard mirip dengan replica set. Config Server menyimpan metadata konfigurasi. Penggunaan memori node routing mongos berkaitan dengan ukuran set hasil agregasi, jumlah koneksi, dan ukuran metadata.

  • Gunakan command line

    Hubungkan ke instans menggunakan mongo shell dan jalankan perintah db.serverStatus().mem untuk melihat dan menganalisis penggunaan memori. Kode berikut menunjukkan contoh output:

{ "bits" : 64, "resident" : 13116, "virtual" : 20706, "supported" : true }
// resident menunjukkan memori fisik yang digunakan oleh proses mongod, dalam MB.
// virtual menunjukkan memori virtual yang digunakan oleh proses mongod, dalam MB.
Catatan

Untuk informasi lebih lanjut tentang serverStatus, lihat serverStatus.

Penyebab umum

Memori engine

Sebagian besar memori pada instans ApsaraDB for MongoDB digunakan untuk cache storage engine. Untuk kompatibilitas dan keamanan, ApsaraDB for MongoDB mengatur WiredTiger CacheSize menjadi sekitar 60% dari total memori yang dialokasikan untuk instans. Untuk informasi lebih lanjut tentang spesifikasi, lihat Spesifikasi Produk.

Jika penggunaan cache storage engine mencapai 95% dari CacheSize yang dikonfigurasi, instans berada dalam beban tinggi, dan thread yang menangani permintaan pengguna mulai mengeluarkan halaman bersih (clean pages). Jika data kotor (dirty data) dalam cache storage engine melebihi 20% dari CacheSize, thread pengguna juga akan mengeluarkan halaman kotor (dirty pages). Selama proses ini, pengguna mungkin mengalami pemblokiran permintaan yang signifikan. Untuk informasi lebih lanjut tentang aturan tersebut, lihat deskripsi parameter eviction.

Anda dapat menggunakan metode berikut untuk memeriksa penggunaan memori engine:

  • Periksa penggunaan memori WiredTiger storage engine

    Di mongo shell, jalankan perintah db.serverStatus().wiredTiger.cache. Field output bytes currently in the cache menunjukkan jumlah memori yang digunakan oleh cache. Kode berikut menunjukkan contoh output:

    {
       ......
       "bytes belonging to page images in the cache":6511653424,
       "bytes belonging to the cache overflow table in the cache":65289,
       "bytes currently in the cache":8563140208,
       "bytes dirty in the cache cumulative":NumberLong("369249096605399"),
       ......
    }
  • Periksa rasio dirty cache engine WiredTiger

Memori koneksi dan permintaan

Jumlah koneksi tinggi pada suatu instans dapat mengonsumsi memori dalam jumlah signifikan karena alasan berikut:

  • Overhead stack thread: Setiap koneksi memiliki thread backend yang sesuai untuk memproses permintaannya. Setiap thread dapat mengonsumsi hingga 1 MB ruang stack, meskipun penggunaan tipikal berada dalam kisaran puluhan hingga ratusan kilobita.

  • Buffer kernel koneksi TCP: Pada level kernel, setiap koneksi TCP memiliki buffer baca dan tulis, yang ditentukan oleh parameter kernel TCP seperti tcp_rmem dan tcp_wmem. Anda tidak perlu mengelola memori ini. Namun, semakin banyak koneksi bersamaan dan semakin besar buffer socket default, maka konsumsi memori TCP akan meningkat.

  • Manajemen memori tcmalloc: Saat permintaan diterima, konteks permintaan dibuat dan buffer sementara dialokasikan untuk tugas-tugas seperti menangani paket permintaan, paket respons, dan sorting. Setelah permintaan selesai, buffer ini dilepaskan kembali ke allocator memori tcmalloc. tcmalloc memprioritaskan mengembalikan memori ini ke cache-nya sendiri sebelum secara bertahap melepaskannya ke sistem operasi. Dalam banyak kasus, penggunaan memori tinggi terjadi karena tcmalloc tidak segera mengembalikan memori ke OS, yang dapat menyebabkan akumulasi memori yang belum dilepas hingga puluhan gigabita.

Anda dapat menggunakan metode berikut untuk menyelidiki penyebabnya:

  • Periksa penggunaan koneksi

  • Periksa jumlah memori yang ditahan oleh tcmalloc

    Jalankan perintah db.serverStatus().tcmalloc untuk memeriksa jumlah memori yang belum dikembalikan tcmalloc ke sistem operasi. Ukuran cache tcmalloc dapat dihitung menggunakan rumus berikut: cache tcmalloc = pageheap_free_bytes + total_free_byte. Kode berikut menunjukkan contoh output:

    {
       ......
       "tcmalloc":{
               "pageheap_free_bytes":NumberLong("3048677376"),
               "pageheap_unmapped_bytes":NumberLong("544994184"),
               "current_total_thread_cache_bytes":95717224,
               "total_free_byte":NumberLong(1318185960),
               ......
       }
    }
    Catatan

    Untuk informasi lebih lanjut tentang tcmalloc, lihat tcmalloc.

Memori metadata

Jumlah database, koleksi, dan indeks yang besar pada instans ApsaraDB for MongoDB mengonsumsi memori signifikan karena metadata terkait. Versi lama ApsaraDB for MongoDB mungkin memiliki masalah berikut:

  • Pada versi ApsaraDB for MongoDB sebelum 4.0, cadangan logis penuh dapat membuka banyak handle file. Jika handle ini tidak segera dikembalikan ke sistem operasi, penggunaan memori dapat meningkat pesat.

  • Pada ApsaraDB for MongoDB 4.0 dan sebelumnya, menghapus banyak koleksi mungkin tidak menghapus handle file yang sesuai secara tepat, yang dapat menyebabkan memory leak.

Memori pembuatan indeks

Selama penulisan data normal, node secondary mempertahankan buffer hingga sekitar 256 MB untuk penerapan oplog. Namun, mereplikasi operasi pembuatan indeks pada node secondary dapat mengonsumsi lebih banyak memori.

  • Pada versi ApsaraDB for MongoDB sebelum 4.2, pembuatan indeks mendukung opsi background. Saat Anda menentukan {background:true}, indeks dibuat di latar belakang. Replikasi operasi ini bersifat serial dan dapat mengonsumsi hingga 500 MB memori.

  • Pada ApsaraDB for MongoDB 4.2 dan versi setelahnya, opsi background sudah tidak digunakan lagi (deprecated). Node secondary dapat mereplikasi operasi pembuatan indeks secara paralel, yang mengonsumsi lebih banyak memori. Membuat beberapa indeks secara bersamaan dapat menyebabkan error out of memory (OOM).

Catatan

Untuk informasi lebih lanjut tentang konsumsi memori selama pembuatan indeks, lihat Index Build Impact on Database Performance dan Index Build Process.

Penggunaan memori cache rencana

Dalam beberapa skenario, satu kueri dapat memiliki banyak rencana eksekusi kandidat, yang dapat menyebabkan cache rencana mengonsumsi memori dalam jumlah signifikan.

Periksa penggunaan memori cache rencana: Pada ApsaraDB for MongoDB 4.0 dan versi setelahnya, Anda dapat menjalankan perintah db.serverStatus().metrics.query.planCacheTotalSizeEstimateBytes untuk memeriksa penggunaan memorinya.

Catatan

Strategi optimasi

Optimasi memori bukanlah tentang meminimalkan penggunaan memori secara mutlak. Sebaliknya, tujuannya adalah memastikan sistem memiliki cukup memori untuk beroperasi secara stabil dan efisien, menyeimbangkan antara pemanfaatan resource dan performa.

ApsaraDB for MongoDB telah menentukan CacheSize, dan Anda tidak dapat mengubah nilai ini. Anda dapat menggunakan strategi berikut untuk mengoptimalkan penggunaan memori:

  • Kendalikan koneksi bersamaan. Uji performa menunjukkan bahwa database dapat mendukung 100 koneksi persisten, dan driver MongoDB default dapat membuat kolam koneksi sebanyak 100. Jika banyak client yang terhubung, Anda harus mengurangi ukuran kolam untuk setiap client. Kami menyarankan agar jumlah total koneksi persisten ke seluruh database tetap di bawah 1.000. Koneksi berlebihan meningkatkan overhead memori dan context-switching, yang dapat meningkatkan latensi permintaan.

  • Kurangi overhead memori per permintaan. Misalnya, optimalkan performa kueri dengan membuat indeks untuk mengurangi pemindaian koleksi dan sorting di memori.

  • Jika penggunaan memori terus meningkat setelah optimasi kueri dan koneksi, tingkatkan spesifikasi memori instans. Hal ini membantu mencegah potensi error out of memory (OOM) dan degradasi performa akibat eviction cache berlebihan.

  • Percepat pelepasan memori oleh tcmalloc. Jika penggunaan memori instans database Anda melebihi 80%, Anda dapat menyesuaikan parameter terkait tcmalloc pada halaman Parameter Settings di konsol.

    1. Pertama, aktifkan parameter tcmallocAggressiveMemoryDecommit. Parameter ini telah diuji secara ekstensif dan secara efektif menyelesaikan masalah retensi memori.

    2. Jika penyesuaian sebelumnya tidak memberikan hasil yang diharapkan, tingkatkan secara bertahap nilai parameter tcmallocReleaseRate. Misalnya, naikkan dari 1 ke 3, lalu ke 5.

    Penting
    • Lakukan penyesuaian parameter ini selama jam sepi. Mengubah parameter tcmallocAggressiveMemoryDecommit dan tcmallocReleaseRate dapat menurunkan performa database. Jika bisnis Anda terpengaruh, segera kembalikan perubahan tersebut.

    • Untuk menentukan dampak terhadap bisnis Anda dan apakah dampak tersebut dapat diterima, pantau metrik seperti penggunaan CPU, waktu respons (RT), dan opCounters sebelum dan sesudah penyesuaian.

  • Optimalkan jumlah database dan koleksi. Jika instans Anda memiliki terlalu banyak database dan koleksi, Anda dapat menghapus koleksi dan indeks yang tidak diperlukan, menggabungkan data dari beberapa tabel, membagi instans, atau melakukan migrasi ke sharded cluster. Untuk informasi lebih lanjut, lihat Performa instans melambat atau menjadi abnormal karena jumlah database dan tabel yang berlebihan.

Catatan

Jika Anda menghadapi skenario lain yang mungkin melibatkan ApsaraDB for MongoDB saat menggunakan ApsaraDB for MongoDB, hubungi dukungan teknis Alibaba Cloud.

Referensi

Parameter pengusiran

Parameter

Default

Deskripsi

eviction_target

80%

Saat penggunaan cache melebihi eviction_target, thread eviction latar belakang mulai mengeluarkan halaman bersih.

eviction_trigger

95%

Saat penggunaan cache melebihi eviction_trigger, thread pengguna juga mulai mengeluarkan halaman bersih.

eviction_dirty_target

5%

Saat rasio cache kotor melebihi eviction_dirty_target, thread eviction latar belakang mulai mengeluarkan halaman kotor.

eviction_dirty_trigger

20%

Saat rasio cache kotor melebihi eviction_dirty_trigger, thread pengguna juga mulai mengeluarkan halaman kotor.

eviction_updates_target

2,5%

Saat rasio pembaruan cache melebihi eviction_updates_target, thread eviction latar belakang mulai mengeluarkan fragmen memori yang terkait dengan objek kecil.

eviction_updates_trigger

10%

Saat rasio pembaruan cache melebihi eviction_updates_trigger, thread pengguna juga mulai mengeluarkan fragmen memori yang terkait dengan objek kecil.

FAQ

Q: Bagaimana cara meningkatkan batas memori untuk operasi agregasi di MongoDB?

A: ApsaraDB for MongoDB tidak mengizinkan Anda langsung meningkatkan batas memori untuk operasi agregasi. Setiap tahap dalam aggregation pipeline MongoDB memiliki batas memori 100 MB. Jika suatu tahap melebihi batas ini, sistem akan mengembalikan error. Anda dapat mengatasi masalah ini dengan secara eksplisit menentukan opsi {allowDiskUse:true} dalam aggregation pipeline Anda. MongoDB versi 6.0 dan setelahnya mendukung parameter global default allowDiskUseByDefault. Saat operasi agregasi memerlukan memori berlebihan, MongoDB secara otomatis menggunakan disk space sementara untuk menghindari konsumsi memori tinggi. Untuk strategi lain guna mengurangi penggunaan memori, lihat Strategi Optimasi.