2nd/10_Wiki/Topics/Programming & Language/Nodejs 성능 최적화 및 디버깅.md

---
id: wiki-2026-0508-nodejs-성능-최적화-및-디버깅
title: Nodejs 성능 최적화 및 디버깅
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Nodejs 메모리 최적화, Nodejs 메모리 튜닝, Nodejs 성능 디버깅, Nodejs 프로세스 모니터링]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [nodejs, performance, debugging, memory, v8]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: javascript
  framework: nodejs
---

# Nodejs 성능 최적화 및 디버깅

## 매 한 줄
> **"매 production Node 의 성능 의 V8 heap + event loop + async I/O 의 3-축 의 governing"**. 매 2026 의 Node 22 LTS 의 default — 매 V8 12.x 의 Maglev/Turbofan tier 의 활용 + native diagnostic_channel + clinic.js 4.x 의 standard toolchain.

## 매 핵심

### 매 3-축 model
- **Heap**: 매 V8 의 Old/New Space 의 GC pressure.
- **Event Loop**: 매 microtask + macrotask + nextTick 의 priority.
- **Async I/O**: 매 libuv thread pool (`UV_THREADPOOL_SIZE` default 4).

### 매 진단 toolkit (2026)
- `node --inspect` + Chrome DevTools.
- `clinic.js doctor / flame / bubbleprof / heapprofiler`.
- `0x` (flamegraph generator).
- `node --prof` + `--prof-process`.
- `diagnostic_channel` (Node 16+) — 매 production-safe instrumentation.

### 매 응용
1. Memory leak 의 추적 — heap snapshot diff.
2. CPU bottleneck 의 식별 — flame graph.
3. Event loop lag 의 monitoring — `perf_hooks.monitorEventLoopDelay`.

## 💻 패턴

### Heap snapshot 비교
```javascript
const v8 = require('v8');
const fs = require('fs');

function snapshot(label) {
  const file = `/tmp/heap-${label}-${Date.now()}.heapsnapshot`;
  const stream = v8.getHeapSnapshot();
  stream.pipe(fs.createWriteStream(file));
  return file;
}

// usage
const before = snapshot('before');
runWorkload();
global.gc?.(); // --expose-gc
const after = snapshot('after');
// → load both into Chrome DevTools, compare retainers
```

### Event loop delay monitoring
```javascript
import { monitorEventLoopDelay } from 'node:perf_hooks';

const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();

setInterval(() => {
  const p99 = h.percentile(99) / 1e6; // ms
  if (p99 > 100) console.warn(`event loop p99 lag: ${p99.toFixed(1)}ms`);
  h.reset();
}, 5000);
```

### CPU profile (production-safe)
```javascript
import { Session } from 'node:inspector/promises';

const session = new Session();
session.connect();
await session.post('Profiler.enable');
await session.post('Profiler.start');
// ... run workload
const { profile } = await session.post('Profiler.stop');
fs.writeFileSync('cpu.cpuprofile', JSON.stringify(profile));
```

### Heap limit 설정
```bash
# 8GB heap
node --max-old-space-size=8192 server.js

# container-aware
node --max-old-space-size=$(echo "$(cat /sys/fs/cgroup/memory.max) * 0.75 / 1024 / 1024" | bc) server.js
```

### diagnostic_channel instrumentation
```javascript
import diagnostics_channel from 'node:diagnostics_channel';

const ch = diagnostics_channel.channel('app:slow-query');
ch.subscribe((msg) => {
  metrics.histogram('db.query.slow', msg.duration);
});

// publisher
ch.publish({ query, duration });
```

### Async resource tracking
```javascript
import { AsyncLocalStorage } from 'node:async_hooks';

const als = new AsyncLocalStorage();

app.use((req, res, next) => {
  als.run({ requestId: req.id }, next);
});

logger.info = (msg) => {
  const ctx = als.getStore();
  console.log(JSON.stringify({ msg, requestId: ctx?.requestId }));
};
```

### Worker thread offload
```javascript
import { Worker } from 'node:worker_threads';

function cpuHeavyTask(data) {
  return new Promise((resolve, reject) => {
    const w = new Worker('./worker.js', { workerData: data });
    w.on('message', resolve);
    w.on('error', reject);
  });
}
```

## 매 결정 기준
| 상황 | Approach |
|---|---|
| Memory leak 의심 | heap snapshot diff (3개 시점) |
| CPU spike | clinic flame / 0x flamegraph |
| Latency p99 ↑ | event loop delay monitor |
| OOM kill (container) | `--max-old-space-size` 의 container limit 의 75% |
| Async chain debugging | AsyncLocalStorage + diagnostic_channel |

**기본값**: clinic doctor 로 시작 → 매 specific tool (flame/bubbleprof) 의 narrowing.

## 🔗 Graph
- 부모: [[V8 엔진 힙 아키텍처]] · [[Garbage Collection]]
- 변형: [[Nodejs 메모리 최적화]] · [[Nodejs 메모리 튜닝]] · [[Nodejs 성능 디버깅]]
- 응용: [[Nodejs 프로세스 모니터링 및 메모리 분석]] · [[브라우저 및 Nodejs 메모리 튜닝]]
- Adjacent: [[Chrome DevTools(크롬 개발자 도구)]] · [[Flame Chart]] · [[할당 타임라인(Allocation Timeline)]]

## 🤖 LLM 활용
**언제**: production Node 의 성능 회귀 의 진단, heap leak 의 root cause analysis.
**언제 X**: synthetic benchmark — 매 real workload profile 만 의 trustworthy.

## ❌ 안티패턴
- **Premature optimization**: 매 profile 의 X — guess 의 X.
- **`global.gc()` 의 production 호출**: 매 stop-the-world — latency spike.
- **`UV_THREADPOOL_SIZE` 의 무분별 증가**: 매 context switch 의 overhead.
- **heap snapshot 의 production load 의 down**: 매 GB-scale 의 dump — disk + pause.

## 🧪 검증 / 중복
- Verified (Node.js 22 docs, V8 blog, Matteo Collina's perf talks).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — Node 22 / clinic 4.x / diagnostic_channel 반영 |