Memperbaiki masalah pemanfaatan memori tinggi pada instans - ApsaraDB for MongoDB

Pemanfaatan memori adalah metrik kunci untuk memantau sebuah ApsaraDB for MongoDB instans. Topik ini menjelaskan cara melihat detail pemanfaatan memori dari sebuah ApsaraDB for MongoDB instans dan memperbaiki masalah pemanfaatan memori tinggi.

Informasi latar belakang

ApsaraDB for MongoDB memuat file biner dan file perpustakaan sistem ke dalam memori. Proses ApsaraDB for MongoDB juga mengalokasikan dan melepaskan memori dalam manajemen koneksi klien, pemrosesan permintaan, dan mesin penyimpanan WiredTiger. Secara default, ApsaraDB for MongoDB menggunakan TCMalloc yang disediakan oleh Google sebagai alokator memori. Sejumlah besar memori dikonsumsi oleh mesin penyimpanan WiredTiger, koneksi klien, dan pemrosesan permintaan.

Cara akses

Lihat Pemanfaatan Memori di Grafik Pemantauan
Di halaman Monitoring Data dari sebuah ApsaraDB for MongoDB instans di Konsol ApsaraDB for MongoDB, Anda dapat melihat pemanfaatan memori instans dalam grafik pemantauan. ApsaraDB for MongoDB menyediakan berbagai kombinasi node untuk arsitektur instans. Anda dapat memilih node untuk melihat pemanfaatan memorinya.
- Instans Set Replika terdiri dari node utama, satu atau lebih node sekunder, node tersembunyi, dan satu atau lebih node baca saja opsional.
- Instans Kluster Sharded terdiri dari satu atau lebih komponen shard, komponen ConfigServer yang menyimpan metadata konfigurasi, dan satu atau lebih komponen mongos. Konsumsi memori komponen shard sama dengan instans set replika. Pemanfaatan memori komponen mongos bergantung pada set hasil agregasi, jumlah koneksi, dan ukuran metadata.

Lihat Pemanfaatan Memori dengan Menjalankan Perintah
Untuk melihat dan menganalisis pemanfaatan memori sebuah instans, gunakan mongo shell untuk terhubung ke instans dan kemudian jalankan perintah db.serverStatus().mem. Contoh keluaran:

{ "bits" : 64, "resident" : 13116, "virtual" : 20706, "supported" : true }
// resident menunjukkan memori fisik yang dikonsumsi oleh node mongos. Unit: MB.
// virtual menunjukkan memori virtual yang dikonsumsi oleh node mongos. Unit: MB.

Catatan

Untuk informasi lebih lanjut tentang perintah serverStatus, lihat serverStatus.

Penyebab umum

Penggunaan memori tinggi oleh mesin penyimpanan WiredTiger

Mesin penyimpanan WiredTiger mengonsumsi jumlah memori terbesar dari sebuah ApsaraDB for MongoDB instans. Untuk memastikan kompatibilitas dan keamanan, ApsaraDB for MongoDB menetapkan parameter CacheSize menjadi 60% dari memori aktual sebuah instans. Untuk informasi lebih lanjut, lihat Spesifikasi.

Jika cache mesin penyimpanan mencapai 95% dari nilai CacheSize yang Anda tentukan, beban instans tinggi, dan thread yang digunakan untuk memproses permintaan pengguna akan mengeluarkan halaman bersih. Jika persentase data kotor di cache mesin penyimpanan melebihi 20%, thread pengguna akan mengeluarkan halaman kotor. Dalam proses ini, pengguna jelas melihat permintaan yang terblokir. Untuk informasi lebih lanjut, lihat Parameter Eviction.

Anda dapat menggunakan salah satu metode berikut untuk melihat penggunaan memori mesin penyimpanan WiredTiger:

Lihat Penggunaan Memori Mesin WiredTiger

Jalankan perintah db.serverStatus().wiredTiger.cache di mongo shell. Nilai parameter bytes currently in the cache adalah ukuran memori. Contoh hasil:

{
   ......
   "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 Persentase Data Kotor di Cache WiredTiger
- Di halaman Pemantauan Real-time dari sebuah instans di Konsol DAS, lihat persentase data kotor di cache WiredTiger.
- Gunakan alat mongostat dari ApsaraDB for MongoDB untuk melihat persentase data kotor di cache WiredTiger. Untuk informasi lebih lanjut, lihat mongostat.

Penggunaan memori tinggi oleh koneksi dan permintaan

Jika sejumlah besar koneksi ke instans dibuat, sebagian memori mungkin dikonsumsi karena alasan berikut:

Overhead dump thread. Setiap koneksi memiliki thread yang menangani permintaan di latar belakang. Setiap thread dapat menempati hingga 1 MB ruang dump thread. Dalam banyak kasus, puluhan hingga ratusan KB ruang dump thread ditempati oleh sebuah thread.
Buffer koneksi TCP. Setiap koneksi TCP memiliki buffer baca/tulis di lapisan kernel. Ukuran buffer ditentukan oleh parameter kernel TCP seperti tcp_rmem dan tcp_wmem. Anda tidak perlu menentukan ukuran buffer. Namun, sejumlah besar koneksi konkuren menempati ruang cache soket yang lebih besar dan menghasilkan penggunaan memori TCP yang lebih tinggi.
Manajemen memori TCMalloc. Setiap permintaan memiliki konteks unik. Beberapa buffer sementara mungkin dialokasikan untuk paket permintaan, paket respons, dan proses pengurutan. Buffer sementara secara bertahap dilepaskan di akhir setiap permintaan. Buffer pertama-tama dilepaskan ke cache TCMalloc dan kemudian secara bertahap dilepaskan ke sistem operasi. Dalam banyak kasus, pemanfaatan memori tinggi karena TCMalloc gagal melepaskan memori yang dikonsumsi oleh permintaan tepat waktu. Permintaan mungkin mengonsumsi hingga puluhan GB memori sebelum dilepaskan ke sistem operasi.

Anda dapat menggunakan salah satu metode berikut untuk memperbaiki masalah pemanfaatan memori tinggi oleh koneksi dan permintaan:

Lihat Pemanfaatan Koneksi
- Di halaman Monitoring Data dari sebuah ApsaraDB for MongoDB instans di Konsol ApsaraDB for MongoDB, Anda dapat melihat penggunaan memori instans dalam grafik pemantauan.
- Gunakan mongo shell untuk meminta jumlah koneksi ke instans.
Lihat Ukuran Memori yang Belum Dilepaskan TCMalloc ke Sistem Operasi
Untuk meminta ukuran memori yang belum dilepaskan TCMalloc ke sistem operasi, jalankan perintah db.serverStatus().tcmalloc. Ukuran cache TCMalloc adalah jumlah dari nilai pageheap_free_bytes dan total_free_byte. Contoh hasil:
```
{
   ......
   "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.

Penggunaan memori tinggi oleh metadata

Sejumlah besar metadata di ApsaraDB for MongoDB, seperti database, koleksi, dan indeks, dapat mengonsumsi memori dalam jumlah besar. Masalah berikut mungkin muncul di instans ApsaraDB for MongoDB yang menjalankan versi sebelumnya:

Backup logis penuh dapat membuka sejumlah besar pegangan file di instans yang menjalankan versi sebelum MongoDB 4.0. Jika pegangan file tidak segera dikembalikan ke sistem operasi, penggunaan memori meningkat dengan cepat.
Pegangan file mungkin tidak dihapus setelah sejumlah besar koleksi di instans yang menjalankan MongoDB 4.0 atau lebih lama dihapus. Ini menghasilkan kebocoran memori.

Penggunaan memori tinggi oleh pembuatan indeks

Dalam penulisan data normal, node sekunder mempertahankan buffer sekitar 256 MB untuk pemutaran ulang data. Setelah indeks dibuat, node sekunder mungkin mengonsumsi lebih banyak memori untuk pemutaran ulang data.

Opsi background tersedia untuk instans yang menjalankan versi sebelum MongoDB 4.2 selama pembuatan indeks. Jika Anda mengonfigurasi {background:true}, indeks dibuat di latar belakang. Pembuatan indeks diputar ulang secara serial. Ini mengonsumsi hingga 500 MB memori.
Secara default, opsi background sudah tidak digunakan lagi untuk instans yang menjalankan MongoDB 4.2 dan yang lebih baru. Node sekunder dapat memutar ulang pembuatan indeks secara paralel, yang mengonsumsi lebih banyak memori. Kesalahan kehabisan memori mungkin muncul saat beberapa indeks dibuat.

Catatan

Untuk informasi lebih lanjut, lihat index-build-impact-on-database-performance dan index-build-process.

Penggunaan memori tinggi oleh PlanCache

Jika sebuah permintaan memiliki sejumlah besar rencana eksekusi, metode PlanCache dapat mengonsumsi sejumlah besar memori.

Lihat Penggunaan Memori PlanCache: Anda dapat menjalankan perintah db.serverStatus().metrics.query.planCacheTotalSizeEstimateBytes untuk melihat penggunaan memori PlanCache di instans yang menjalankan MongoDB 4.0 atau yang lebih baru.

Catatan

Jika instans Anda menjalankan MongoDB 4.0 tetapi perintah sebelumnya tidak berisi bidang terkait, versi minor instans terlalu rendah. Kami merekomendasikan agar Anda memperbarui versi minor instans.
Untuk informasi lebih lanjut tentang penggunaan memori PlanCache, lihat Secondary node memory arise while balancer doing work.

Kebijakan optimasi

Tujuan optimasi memori adalah untuk mencari keseimbangan antara konsumsi sumber daya dan kinerja, bukan meminimalkan penggunaan memori. Idealnya, memori tetap cukup dan stabil serta kinerja sistem tidak terpengaruh.

Anda tidak dapat mengubah nilai parameter CacheSize yang ditentukan oleh ApsaraDB for MongoDB. Anda dapat menggunakan kebijakan berikut untuk optimasi memori:

Kontrol jumlah koneksi konkuren. Berdasarkan hasil pengujian kinerja, 100 koneksi persisten dapat dibuat di database. Secara default, driver MongoDB dapat membuat hingga 100 kolam koneksi dengan backend. Jika terdapat sejumlah besar klien, kurangi ukuran kolam koneksi untuk setiap klien. Kami merekomendasikan agar Anda membuat tidak lebih dari 1.000 koneksi persisten di database. Jika tidak, overhead pada memori dan konteks multi-thread mungkin meningkat, menyebabkan latensi penanganan permintaan yang tinggi.
Kurangi overhead memori dari permintaan tunggal. Misalnya, untuk mengoptimalkan kinerja query, Anda dapat membuat indeks guna meminimalkan kebutuhan untuk pemindaian koleksi dan pengurutan dalam memori.
Tingkatkan konfigurasi memori. Jika jumlah koneksi sesuai tetapi penggunaan memori terus meningkat setelah Anda mengoptimalkan kinerja query, kami merekomendasikan agar Anda meningkatkan konfigurasi memori. Jika tidak, ketersediaan instans mungkin terpengaruh karena kesalahan kehabisan memori (OOM) dan pembersihan cache yang luas.
Percepat pelepasan memori TCMalloc. Jika pemanfaatan memori instans Anda melebihi 80%, Anda dapat menyesuaikan parameter TCMalloc di Konsol ApsaraDB for MongoDB.
1. Prioritaskan mengaktifkan parameter tcmallocAggressiveMemoryDecommit. Parameter ini telah diverifikasi melalui praktik yang kaya dan memiliki efek signifikan dalam menyelesaikan masalah memori.
2. Tingkatkan secara bertahap nilai parameter tcmallocReleaseRate. Jika Anda tidak memenuhi persyaratan setelah menyesuaikan parameter tcmallocAggressiveMemoryDecommit, tingkatkan secara bertahap nilai parameter tcmallocReleaseRate. Misalnya, Anda dapat meningkatkan nilai parameter dari 1 menjadi 3 dan kemudian menjadi 5.
Penting
Kami merekomendasikan agar Anda menyesuaikan nilai parameter tcmallocReleaseRate selama jam-jam sepi. Penyesuaian kedua parameter ini dapat menyebabkan penurunan kinerja. Jika bisnis Anda terpengaruh oleh penyesuaian, kembalikan nilai parameter secara tepat waktu.
Optimalkan jumlah database dan koleksi. Jika instans Anda berisi sejumlah besar database dan koleksi, Anda dapat menghapus koleksi dan indeks yang tidak perlu, mengintegrasikan data dari beberapa koleksi, membagi instans, atau memigrasikan data instans ke instans kluster sharded. Untuk informasi lebih lanjut, lihat Apa yang harus saya lakukan jika instans saya dalam keadaan tersendat atau mengalami pengecualian karena sejumlah besar database dan koleksi?

Catatan

Dalam skenario di mana kebocoran memori mungkin terjadi dalam penggunaan ApsaraDB for MongoDB, hubungi dukungan teknis Alibaba Cloud.

Referensi

Parameter Eviction

Parameter	Nilai default	Deskripsi
eviction_target	80%	Saat ukuran cache terpakai lebih besar dari nilai parameter eviction_target, thread eviction mengeluarkan halaman bersih di latar belakang.
eviction_trigger	95%	Saat ukuran cache terpakai lebih besar dari nilai parameter eviction_trigger, thread pengguna mengeluarkan halaman bersih di latar belakang.
eviction_dirty_target	5%	Saat ukuran data kotor di cache lebih besar dari nilai parameter eviction_dirty_target, thread eviction mengeluarkan halaman kotor di latar belakang.
eviction_dirty_trigger	20%	Saat ukuran data kotor di cache lebih besar dari nilai parameter eviction_dirty_trigger, thread pengguna mengeluarkan halaman kotor di latar belakang.
eviction_updates_target	2.5%	Jika rasio pembaruan cache melebihi nilai parameter eviction_updates_target, thread evict latar belakang mulai menghilangkan ruang fragmentasi memori yang terkait dengan objek kecil.
eviction_updates_trigger	10%	Jika rasio pembaruan cache melebihi nilai parameter eviction_updates_trigger, thread pengguna juga mulai mengeluarkan ruang fragmentasi memori yang terkait dengan objek kecil.

FAQ

Bagaimana cara menentukan batas atas memori yang dikonsumsi oleh operasi agregasi untuk ApsaraDB for MongoDB?

ApsaraDB for MongoDB tidak mengizinkan Anda secara langsung menentukan batas atas memori yang dikonsumsi oleh operasi agregasi. ApsaraDB for MongoDB memiliki batas memori 100 MB untuk setiap tahap operasi agregasi. Jika sebuah tahap melebihi batas ini, sistem melaporkan kesalahan. Untuk menyelesaikan masalah ini, Anda dapat menambahkan opsi yang menentukan nilai {allowDiskUse:true} dalam pernyataan agregasi. Untuk informasi lebih lanjut, lihat Pembatasan Memori. MongoDB 6.0 atau yang lebih baru mendukung parameter global default allowDiskUseByDefault. Saat operasi agregasi mengonsumsi memori berlebih, ApsaraDB for MongoDB sementara menggunakan beberapa ruang disk untuk menghindari penggunaan memori yang berlebih. Untuk informasi lebih lanjut tentang kebijakan lainnya untuk mengurangi penggunaan memori, lihat Kebijakan Optimasi.