Diagnosis penyebab dan kurangi penggunaan memori tinggi - ApsaraDB for MongoDB

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

Ikhtisar

Ketika proses ApsaraDB for MongoDB dimulai, proses tersebut tidak hanya memuat file biner dan berbagai pustaka sistem ke dalam memori, tetapi juga mengelola alokasi dan dealokasi memori untuk koneksi client, pemrosesan permintaan, dan storage engine. Secara default, ApsaraDB for MongoDB menggunakan Google tcmalloc sebagai allocator memorinya. Storage engine WiredTiger dan koneksi client serta pemrosesan permintaan merupakan komponen utama yang mengonsumsi memori.

Lihat penggunaan memori

Grafik pemantauan
Pada halaman Monitoring Data di Konsol ApsaraDB for MongoDB, pilih node yang sesuai dengan arsitektur database Anda untuk melihat laju penggunaan memorinya.
- Arsitektur replica set: Terdiri dari satu node Primary, satu atau lebih node Secondary, satu node Hidden, dan opsional satu atau lebih node ReadOnly.
- Arsitektur sharded cluster: Penggunaan memori pada setiap shard mengikuti pola yang sama seperti replica set. Config Server menyimpan metadata konfigurasi. Penggunaan memori pada node routing Mongos bergantung pada ukuran set hasil agregasi, jumlah koneksi, dan ukuran metadata.

Command line
Hubungkan ke instans dengan MongoDB Shell dan jalankan perintah db.serverStatus().mem untuk melihat penggunaan memori. Berikut adalah contoh respons:

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

Catatan

Untuk informasi lebih lanjut tentang serverStatus, lihat serverStatus.

Penyebab umum

Penggunaan memori oleh storage engine

Cache storage engine mengonsumsi sebagian besar memori. Untuk alasan kompatibilitas dan keamanan, ApsaraDB for MongoDB menetapkan WiredTiger CacheSize sekitar 60% dari spesifikasi memori instans. Untuk detailnya, lihat Spesifikasi Produk.

Jika cache storage engine menggunakan 95% dari CacheSize yang dikonfigurasi, hal ini menunjukkan beban instans yang tinggi, dan thread yang menangani permintaan pengguna akan ikut serta dalam proses eviksi halaman bersih. Jika data kotor dalam cache storage engine melebihi 20% dari ukuran cache, thread pengguna juga akan ikut serta dalam proses eviksi halaman kotor. Selama proses ini, Anda mungkin akan melihat pemblokiran permintaan yang signifikan. Untuk aturan spesifiknya, lihat deskripsi parameter eviction.

Anda dapat menggunakan metode berikut untuk memeriksa penggunaan memori oleh engine:

Lihat penggunaan memori engine WiredTiger

Pada MongoDB Shell, jalankan perintah berikut:db.serverStatus().wiredTiger.cache. Dalam respons,bytes currently in the cache menunjukkan ukuran memori. Berikut adalah contoh respons:

{
   ......
   "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"),
   ......
}

Lihat rasio cache kotor engine WiredTiger
- Pada Konsol DAS, buka halaman Real-Time Monitoring Data untuk melihat rasio cache kotor saat ini.
- Gunakan tool mongostat yang disediakan bersama ApsaraDB for MongoDB untuk melihat rasio cache kotor saat ini.

Penggunaan memori oleh koneksi dan permintaan

Jumlah koneksi bersamaan yang tinggi ke instans dapat mengonsumsi memori secara signifikan karena alasan berikut:

Overhead stack thread: Setiap koneksi memiliki thread backend yang sesuai untuk memproses permintaan pada koneksi tersebut. Setiap thread dapat mengonsumsi hingga 1 MB ruang stack, meskipun biasanya berada dalam kisaran puluhan hingga ratusan KB.
Buffer kernel koneksi TCP: Pada level kernel, setiap koneksi TCP memiliki buffer baca dan tulis, yang ditentukan oleh parameter kernel seperti tcp_rmem dan tcp_wmem. Anda tidak perlu mengelola penggunaan memori ini. Namun, semakin banyak koneksi bersamaan dan semakin besar buffer socket default, maka konsumsi memori TCP akan semakin tinggi.
Manajemen memori tcmalloc: Saat permintaan diterima, konteks permintaan dibuat dan buffer sementara (seperti paket permintaan, paket respons, dan buffer sortir sementara) dialokasikan. Setelah permintaan selesai, buffer sementara ini dilepaskan kembali ke allocator memori tcmalloc. tcmalloc pertama-tama mengembalikannya ke cache internalnya sebelum secara bertahap melepaskannya kembali ke sistem operasi. Dalam banyak kasus, penggunaan memori tinggi terjadi karena tcmalloc tidak segera melepaskan memori kembali ke OS. Memori yang belum dilepaskan ini dapat menumpuk hingga puluhan gigabyte.

Anda dapat menggunakan metode berikut untuk memecahkan masalah:

Lihat penggunaan koneksi
- Pada halaman Monitoring Data di Konsol ApsaraDB for MongoDB, lihat penggunaan koneksi.
- Gunakan MongoDB Shell untuk menanyakan jumlah koneksi.

Lihat Memori yang Belum Dikembalikan oleh tcmalloc ke OS

Jalankan perintah db.serverStatus().tcmalloc untuk memeriksa jumlah memori yang dipegang oleh tcmalloc. Dalam konteks ini, cache tcmalloc = pageheap_free_bytes + total_free_byte. Berikut adalah contoh respons:

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

Penggunaan memori oleh metadata

Ketika instans ApsaraDB for MongoDB memiliki jumlah metadata database, koleksi, dan indeks yang sangat besar, hal ini dapat mengonsumsi memori secara signifikan. Versi lama ApsaraDB for MongoDB mungkin memiliki masalah berikut:

Pada ApsaraDB for MongoDB versi sebelum 4.0, backup logis penuh dapat membuka banyak handle file. Jika handle tersebut tidak segera dikembalikan ke sistem operasi, penggunaan memori dapat meningkat pesat.
Pada ApsaraDB for MongoDB 4.0 dan versi sebelumnya, penghapusan sejumlah besar koleksi mungkin tidak menghapus handle file yang sesuai secara tepat, yang dapat menyebabkan memory leak.

Penggunaan memori selama pembuatan indeks

Selama penulisan data normal, node Secondary mempertahankan buffer sekitar 256 MB untuk penerapan oplog data. Namun, saat membuat indeks, proses penerapan oplog pada node Secondary dapat mengonsumsi lebih banyak memori.

Pada ApsaraDB for MongoDB versi sebelum 4.2, pembuatan indeks mendukung opsi background. Ketika {background:true} ditentukan, indeks dibangun di latar belakang. Penerapan oplog untuk pembuatan indeks bersifat serial dan dapat mengonsumsi hingga 500 MB memori.
Versi ApsaraDB for MongoDB 4.2 dan yang lebih baru telah menghentikan penggunaan opsi background secara default. Node Secondary diizinkan menerapkan pembuatan indeks secara paralel, yang mengonsumsi lebih banyak memori. Membuat beberapa indeks secara bersamaan dapat menyebabkan error Out of Memory (OOM) pada instans.

Catatan

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

Penggunaan memori PlanCache

Dalam beberapa skenario, satu permintaan tunggal mungkin memiliki banyak rencana eksekusi potensial, sehingga menyebabkan PlanCache mengonsumsi memori secara signifikan.

Lihat penggunaan memori PlanCache: Pada ApsaraDB for MongoDB 4.0 dan versi yang lebih baru, jalankan perintah db.serverStatus().metrics.query.planCacheTotalSizeEstimateBytes untuk melihat ukurannya.

Catatan

Jika perintah di atas tidak mengembalikan field yang relevan pada instans ApsaraDB for MongoDB 4.0 Anda, berarti instans tersebut menjalankan versi minor yang lebih lama. Upgrade versi minor database untuk mengakses fungsionalitas ini.
Untuk informasi lebih lanjut tentang penggunaan memori PlanCache, lihat Secondary node memory arise while balancer doing work.

Strategi optimasi

Optimasi memori bukan berarti meminimalkan penggunaan memori secara mutlak. Sebaliknya, tujuannya adalah memastikan sistem memiliki memori yang cukup dan stabil untuk beroperasi secara normal, mencapai keseimbangan antara pemanfaatan resource dan performa.

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

Kendalikan jumlah koneksi bersamaan. Berdasarkan hasil pengujian performa, server database mendukung maksimal 100 koneksi bersamaan, dan ukuran kolam koneksi default driver MongoDB adalah 100. Saat terdapat banyak client, kurangi ukuran kolam koneksi untuk setiap client. Pertahankan jumlah total koneksi persisten ke instans di bawah 1.000 untuk menghindari peningkatan overhead memori dan context-switch multi-threading yang dapat memengaruhi latensi permintaan.
Untuk mengurangi overhead memori per permintaan, optimalkan performa kueri dengan membuat indeks guna mengurangi pemindaian koleksi dan sorting di memori.
Jika penggunaan memori tetap tinggi setelah Anda mengoptimalkan kueri dan mengonfigurasi jumlah koneksi yang sesuai, upgrade spesifikasi memori untuk mencegah potensi error Out of Memory (OOM) dan degradasi performa akibat eviksi cache berlebihan, serta memastikan ketersediaan instans.
Percepat pelepasan memori oleh tcmalloc. Jika penggunaan memori instans database Anda melebihi 80%, Anda dapat menyesuaikan parameter terkait tcmalloc pada halaman Parameters di konsol.
1. Pertama, aktifkan parameter tcmallocAggressiveMemoryDecommit. Parameter ini telah diuji secara ekstensif dan terbukti efektif dalam menyelesaikan masalah terkait memori.
2. Tingkatkan secara bertahap nilai parameter tcmallocReleaseRate. Jika penyesuaian parameter sebelumnya tidak memberikan hasil yang diharapkan, tingkatkan secara bertahap nilai tcmallocReleaseRate (misalnya, dari 1 ke 3, lalu ke 5).
Penting
Sesuaikan parameter ini selama jam sepi, karena modifikasi parameter tcmallocAggressiveMemoryDecommit dan tcmallocReleaseRate dapat menurunkan performa database. Jika bisnis Anda terpengaruh, segera kembalikan perubahan tersebut.
Optimalkan jumlah database dan koleksi. Jika instans database Anda memiliki terlalu banyak database dan koleksi, Anda dapat menghapus koleksi dan indeks yang tidak diperlukan, menggabungkan data dari beberapa tabel, membagi instans, atau migrasi ke sharded cluster. Untuk informasi lebih lanjut, lihat Degradasi Performa Akibat Terlalu Banyak Database atau Tabel.

Catatan

Jika Anda menghadapi skenario memory leak potensial lainnya saat menggunakan ApsaraDB for MongoDB, Anda dapat menghubungi dukungan teknis Alibaba Cloud untuk bantuan.

Referensi

deskripsi parameter eviction

Parameter	Nilai default	Deskripsi
eviction_target	80%	Ketika penggunaan cache melebihi eviction_target, thread latar belakang mulai mengevaksi halaman bersih.
eviction_trigger	95%	Ketika penggunaan cache melebihi eviction_trigger, thread pengguna juga mulai mengevaksi halaman bersih.
eviction_dirty_target	5%	Ketika rasio cache kotor melebihi eviction_dirty_target, thread latar belakang mulai mengevaksi halaman kotor.
eviction_dirty_trigger	20%	Ketika rasio cache kotor melebihi eviction_dirty_trigger, thread pengguna juga mulai mengevaksi halaman kotor.
eviction_updates_target	2.5%	Ketika rasio pembaruan cache melebihi eviction_updates_target, thread latar belakang mulai mengevaksi fragmen memori yang terkait dengan objek kecil.
eviction_updates_trigger	10%	Ketika rasio pembaruan cache melebihi eviction_updates_trigger, thread pengguna juga mulai mengevaksi fragmen memori yang terkait dengan objek kecil.

FAQ

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

A: ApsaraDB for MongoDB saat ini tidak mendukung peningkatan langsung batas memori untuk operasi agregasi. MongoDB menerapkan batas memori 100 MB per tahap pipeline agregasi. Jika suatu tahap melebihi batas ini, sistem akan mengembalikan error. Untuk mengatasi masalah ini, Anda dapat secara eksplisit menentukan opsi {allowDiskUse:true} dalam pipeline agregasi Anda. Mulai MongoDB 6.0, MongoDB memperkenalkan parameter global allowDiskUseByDefault. Ketika operasi agregasi memerlukan memori berlebihan, MongoDB secara otomatis menggunakan ruang disk sementara untuk mengurangi konsumsi memori. Untuk strategi tambahan dalam mengoptimalkan penggunaan memori, lihat Strategi optimasi.