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().memuntuk 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.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 outputbytes currently in the cachemenunjukkan 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
Halaman Real-Time Monitoring Data di Konsol Database Autonomy Service (DAS) menampilkan rasio dirty cache real-time untuk engine WiredTiger.
Gunakan tool mongostat yang disertakan dengan ApsaraDB for MongoDB untuk memeriksa rasio dirty cache saat ini dari engine WiredTiger. Untuk informasi lebih lanjut, lihat mongostat.
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
Di halaman Monitoring Information di Konsol ApsaraDB for MongoDB, lihat penggunaan koneksi instans ApsaraDB for MongoDB Anda.
Di mongo shell, kueri jumlah koneksi.
Periksa jumlah memori yang ditahan oleh tcmalloc
Jalankan perintah
db.serverStatus().tcmallocuntuk 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), ...... } }CatatanUntuk 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
backgroundsudah 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).
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.
Jika instans Anda menjalankan ApsaraDB for MongoDB 4.0 tetapi perintah tersebut tidak mengembalikan field planCacheTotalSizeEstimateBytes, berarti versi minor instans Anda terlalu lama. Kami menyarankan Anda untuk meningkatkan versi minor instans Anda.
Untuk informasi lebih lanjut tentang penggunaan memori cache rencana, lihat Secondary node memory arise while balancer doing work.
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.
Pertama, aktifkan parameter tcmallocAggressiveMemoryDecommit. Parameter ini telah diuji secara ekstensif dan secara efektif menyelesaikan masalah retensi memori.
Jika penyesuaian sebelumnya tidak memberikan hasil yang diharapkan, tingkatkan secara bertahap nilai parameter tcmallocReleaseRate. Misalnya, naikkan dari 1 ke 3, lalu ke 5.
PentingLakukan 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.
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.