Memory Node.js Naik Terus? Ini Panduan Mencari dan Memperbaiki Memory Leak

Memory leak sering jadi penyebab aplikasi Node.js tiba-tiba kehabisan RAM dan crash. Panduan ini memberi langkah sistematis untuk mendeteksi, memverifikasi, dan memperbaiki leak. Mulai dari dari pemantauan awal, capture heap snapshot, profiling, sampai perubahan kode dan pattern pencegahan. Artikel ini ditulis agar bisa langsung dicoba pada production atau staging tanpa teori berlebihan.

Gimana Cara Sistematis Mendeteksi dan Memperbaiki Memory Leak di Node.js?

Tenang, kasus aplikasi Node.js yang tiba-tiba crash karena kehabisan RAM memang umum dan bisa diatasi secara sistematis. Kita mulai dengan konfirmasi ada kenaikan memory, lanjut ke capture snapshot dan profiling untuk menemukan objek yang tertahan, lalu perbaiki pattern di kode. Berikutnya chapter pertama menjelaskan apa itu memory leak dan ciri-ciri spesifik pada Node.js.

Memahami Memory Leak di Aplikasi Node.js

💻 Mulai Belajar Pemrograman

Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.

Daftar Sekarang

Memory leak di Node.js terjadi ketika objek tidak lagi dibutuhkan, tetapi masih direferensikan sehingga tidak pernah dibersihkan oleh V8 Garbage Collector. Efeknya tampak sebagai kenaikan heapUsed dan rss yang stabil dari waktu ke waktu, lalu muncul GC makin sering, thrashing, hingga out-of-memory. Ini penting di Node.js karena satu proses sering melayani banyak request sekaligus, sehingga kebocoran kecil pun akan terakumulasi.

V8 Garbage Collection bekerja dengan minor GC untuk generasi muda dan major GC untuk objek yang bertahan lama. Closure yang menyimpan referensi ke objek besar, event listener yang tidak pernah di-remove, timer yang tidak di-clear, global cache tanpa batas, atau native addon yang salah kelola memori dapat mencegah objek menjadi tidak terjangkau.

Contoh pola bocor yang klasik:

Listener tanpa remove: menambahkan event listener di setiap request tanpa off atau removeListener.
Timer dan interval yang tidak pernah di-clearTimeout/clearInterval.
Cache di objek global yang terus diisi tanpa eviction policy.

const cache = {};

function handler(req, res) {

const key = req.url;

if (!cache[key]) {

cache[key] = Buffer.alloc(1024 * 1024); // 1 MB per URL

}

res.end('ok');

}

Tanpa batasan ukuran atau mekanisme hapus, cache di atas akan membuat heapUsed dan rss terus naik. Kamu perlu mulai investigasi ketika tren memori naik konsisten meski beban stabil, GC makin sering dan durasi pause meningkat, atau proses sering mati karena OOM; di situ pemantauan metrik dan deteksi kenaikan memori yang sistematis jadi langkah berikutnya.

Langkah Sistematis untuk Mendeteksi Memory Usage yang Meningkat

Pertama, siapkan monitoring dasar di proses Node.js. Aktifkan process metrics seperti heapUsed, heapTotal, rss, dan event loop delay. Kamu bisa memakai PM2 dengan pm2 monit atau pm2-io, atau mengekspor metrik ke Prometheus lewat pustaka prom-client. Selain itu, tetapkan threshold peringatan, misalnya ketika heapUsed > 70% dari max_old_space_size secara konsisten.

Selanjutnya, ambil baseline pada kondisi normal. Jalankan beban kerja tipikal, lalu rekam pola penggunaan memori selama beberapa jam. Dengan cara ini, kamu bisa mengetahui seperti apa grafik memori yang sehat. Akibatnya, kenaikan yang tidak wajar dapat terlihat lebih cepat.

Kemudian, identifikasi apakah pola memori terus meningkat atau naik-turun secara alami. Jika heapUsed membentuk pola seperti “tangga” dan jarang turun setelah proses garbage collection, maka hal ini dapat menjadi indikasi adanya memory leak. Sebaliknya, jika terjadi lonjakan besar yang kemudian cepat turun kembali, biasanya itu hanya spike sementara. Sementara itu, jika pemakaian memori meningkat setelah fitur tertentu dijalankan atau setelah menggunakan dependency berat, kemungkinan terdapat memory pressure dari pustaka eksternal, bukan selalu bug di kode utama.

Terakhir, tentukan titik kapan perlu mengambil heap snapshot. Biasanya snapshot pertama diambil saat penggunaan memori masih rendah, kemudian snapshot berikutnya saat mendekati threshold. Setelah itu, ulangi proses ini beberapa kali agar dapat membandingkan selisih objek yang terus bertambah. Dengan demikian, snapshot tersebut dapat dianalisis lebih dalam menggunakan alat profiling seperti Chrome DevTools atau flamegraph.

Alat dan Teknik Profiling dengan Heap Snapshot dan Flamegraph

Setelah pola kenaikan memori terdeteksi, langkah berikutnya adalah profiling terarah. Di Node.js, kamu bisa mulai dengan flag –inspect lalu membuka Chrome DevTools tab Memory untuk mengambil heap snapshot. Di aplikasi produksi, sering dipakai modul node-heapdump agar bisa memicu snapshot lewat signal tanpa menghentikan proses.

Contoh sederhana pemakaian node-heapdump:

import heapdump from 'heapdump';

process.on('SIGUSR2', () => {

const file = `/tmp/heap-${Date.now()}.heapsnapshot`;

heapdump.writeSnapshot(file, (err, filename) => {

if (!err) console.log('Heap snapshot:', filename);

});

Kamu kirim kill -USR2 <pid>, file snapshot muncul, lalu dibuka di DevTools menu Memory > Load.

Di heap snapshot, fokus pada kolom Retained Size dan tampilan Dominator tree. Objek dengan retained size besar yang berasal dari closure, event listener, atau cache sering menjadi akar memory leak. Bandingkan dua snapshot, misalnya sebelum dan sesudah beban trafik, lalu cari kelas atau tipe objek yang terus bertambah jumlah instansinya.

Untuk CPU dan pola alokasi, alat seperti clinic flame atau clinic doctor membantu membuat flamegraph. Di sisi lain, pprof atau v8-profiler memberi profil berbasis sampling yang lebih ringan untuk produksi. Gunakan allocation profiling saat ingin tahu baris mana yang paling banyak membuat objek, dan gunakan sampling profiling saat kamu perlu gambaran global tanpa overhead besar.

Selalu isolasi kasus dengan skrip kecil yang bisa mereproduksi kenaikan memori sebelum mengubah kode utama. Pola umum yang perlu diwaspadai di flamegraph dan snapshot adalah listener yang tidak pernah dihapus, map atau cache yang tidak punya batas, dan closure yang memegang referensi ke objek besar. Dari sinilah perbaikan dan pattern pencegahan di Node.js bisa dirancang lebih tepat sasaran.

Perbaikan Praktis dan Patterns untuk Mencegah Leak

Setelah heap snapshot dan flamegraph mengarah ke satu area, fokus ke root cause-nya. Jika sumbernya event listener, pastikan kamu memanggil removeListener atau off saat objek tidak dipakai lagi, dan gunakan once bila hanya perlu satu kali eksekusi. Untuk timer dan interval, selalu simpan reference-nya dan panggil clearTimeout atau clearInterval ketika proses selesai.

Untuk data yang “menempel” pada objek hidup lama, pertimbangkan WeakMap atau WeakRef agar garbage collector bisa membebaskan memori. Misalnya, menyimpan metadata per socket tanpa mencegah socket dibersihkan:

const sessionData = new WeakMap();

function attachSession(socket, data) {

sessionData.set(socket, data);

}

function handleClose(socket) {

// tidak perlu manual delete, GC akan menghapus entry WeakMap

}

Jika profiling menunjukkan banyak objek dari cache, gunakan LRU cache dengan batas ukuran yang jelas. Untuk respons besar, gunakan streaming seperti fs.createReadStream atau pipeline, jangan menumpuk seluruh isi file di memori. Periksa juga closure yang tanpa sengaja menyimpan request atau response di scope luar, lalu pecah fungsi atau hanya kirim data minimal yang benar-benar dibutuhkan.

Setelah perbaikan, tambahkan regression test yang memanggil fungsi berkali-kali sambil memantau penggunaan memori lewat process.memoryUsage. Jalankan di staging dengan monitoring aktif, misalnya metrik RSS dan heapUsed, dan buat alert bila tren naik terus. Sebelum deploy ke produksi, gunakan checklist singkat: listener dibersihkan, timer di-clear, cache punya batas, stream dipakai untuk data besar, serta dashboard dan alert sudah dikonfigurasi.

Penutup

Artikel ini memberi alur kerja ringkas: pahami gejala, deteksi dengan monitoring, verifikasi lewat heap snapshot/profiling, lalu perbaiki dan uji di staging. Fokus pada root cause (closure, event listeners, cache) dan terapkan mitigasi berkelanjutan agar Node.js lebih stabil dan tidak sering crash karena penggunaan RAM yang terus meningkat.