Deteksi Dan Profiling Memory Leak Pada Node.js: Menjaga Stabilitas Server Backend Long-Running

Anatomi Masalah Memori pada Server Long-Running

Node.js beroperasi di atas mesin Google V8 yang menggunakan arsitektur pemrosesan event-loop tunggal. Tidak seperti aplikasi skrip singkat yang mengosongkan alokasi memori setelah selesai dieksekusi, server backend berbasis Node.js merupakan proses long-running yang berjalan selama berhari-hari bahkan berbulan-bulan di lingkungan produksi.

Ketika objek di dalam memori tidak lagi dibutuhkan oleh aplikasi namun masih terikat oleh referensi aktif (referential graph), V8 Garbage Collector (GC) tidak akan mampu menyapu objek tersebut. Seiring bertambahnya jumlah permintaan HTTP, konsumsi RAM server akan merambat naik secara konstan hingga akhirnya menyentuh batas --max-old-space-size dan memicu kegagalan sistem total (OOM crash).

"Kebocoran memori pada Node.js adalah musuh tersembunyi server backend. Gejalanya sering kali tidak terlihat saat pengujian lokal, namun mematikan ketika mendapat beban traffic produksi yang tinggi."

MAYASTRA NAWALOKA, Lead Backend Performance Specialist

Penyebab Utama Kebocoran Memori (Anti-Patterns)

Sebagian besar kasus memory leak pada aplikasi Node.js disebabkan oleh tiga pola penulisan kode yang keliru:

• Variabel Global dan Cache In-Memory Tanpa Batas: Menyimpan data transaksi ke dalam variabel global atau objek JavaScript biasa tanpa mekanika pengosongan otomatis (TTL atau LRU eviction policy).
• Event Listener yang Tidak Dihapus: Memasang listener pada EventEmitter global atau objek process tanpa dipasangkan dengan method removeListener saat siklus permintaan selesai.
• Closure Referensial Terjebak: Fungsi dalam closure yang mempertahankan referensi ke objek konteks luar yang berukuran besar.

// ANTI-PATTERN 1: In-Memory Cache Tanpa Batas (Bocor Memori secara Bertahap)
const userCacheBad = {}; // Objek global yang terus tumbuh tanpa batasan ukuran

function cacheUserDataBad(userId, data) {
    userCacheBad[userId] = data; // Objek ini tidak pernah disapu oleh Garbage Collector!
}

// FIXED PATTERN 1: Menggunakan LRU Cache dengan Batas Ukuran & TTL
import { LRUCache } from 'lru-cache';

const userCacheFixed = new LRUCache({
    max: 5000, // Maksimal 5000 item dalam memori
    ttl: 1000 * 60 * 15, // Masa simpan 15 menit
});

function cacheUserDataFixed(userId, data) {
    userCacheFixed.set(userId, data); // Objek lama akan dibuang otomatis saat melebihi batas
}

// ANTI-PATTERN 2: Event Listener Bocor di Scope HTTP Request
app.get('/events', (req, res) => {
    // Memasang listener baru pada setiap HTTP request tanpa pernah mencopotnya
    globalEmitter.on('update', (data) => {
        res.write(JSON.stringify(data));
    });
});

// FIXED PATTERN 2: Pembersihan Event Listener Menggunakan Signal/Once
app.get('/events-clean', (req, res) => {
    const onUpdate = (data) => res.write(JSON.stringify(data));
    globalEmitter.on('update', onUpdate);

    // Pastikan listener dicopot saat koneksi HTTP ditutup oleh client
    req.on('close', () => {
        globalEmitter.removeListener('update', onUpdate);
    });
});

Metodologi Profiling Heap Snapshot

Untuk melacak sumber pasti dari kebocoran memori di lingkungan produksi atau pengujian beban (load testing), pengembang dapat mengambil potongan status memori (heap snapshot) menggunakan modul bawaan V8 atau koneksi inspector Node.js.

import v8 from 'node:v8';
import fs from 'node:fs';

// Mengambil Heap Snapshot secara Programatik saat Pengujian Beban
function takeHeapSnapshot(filename) {
    const snapshotStream = v8.getHeapSnapshot();
    const fileStream = fs.createWriteStream(filename);
    snapshotStream.pipe(fileStream);
    console.log(`Heap snapshot berhasil disimpan ke: ${filename}`);
}

// Contoh pemicu snapshot berkala untuk pembandingan
takeHeapSnapshot('./snapshots/heap-before-load.heapsnapshot');
// Jalankan load testing dengan k6 atau autocannon...
setTimeout(() => {
    takeHeapSnapshot('./snapshots/heap-after-load.heapsnapshot');
}, 60000);

Teknik Analisis Perbandingan pada Chrome DevTools

Setelah file .heapsnapshot diperoleh, langkah diagnostik dilakukan dengan mengunggah kedua file tersebut ke Chrome DevTools (Memory Tab):

1. Buka Chrome DevTools > pilih tab Memory > pilih opsi Load Snapshot.
2. Unggah file snapshot awal (sebelum load test) dan snapshot kedua (setelah load test).
3. Ubah tampilan analisis dari Summary menjadi Comparison.
4. Urutkan objek berdasarkan kolom Delta atau # Alloc untuk menemukan jenis objek yang jumlah alokasinya terus melonjak tanpa penurunan.
5. Periksa Retainers Tree di bagian bawah layar untuk melacak jalur referensi variabel yang menahan objek tersebut dari pembersihan Garbage Collector.

Matriks Komparasi Tools Profiling Memori Node.js

Tabel berikut menyajikan perbandingan perangkat analisis memori yang tersedia dalam ekosistem Node.js:

MAYASTRA NAWALOKA

Software Engineering & System Architecture Expert

Spesialis rekayasa perangkat lunak berdedikasi tinggi dalam membangun platform web berkinerja tinggi, sistem terdistribusi, dan arsitektur backend yang scalable untuk perusahaan modern.