Files
2nd/10_Wiki/Topics/Programming & Language/Nodejs 성능 최적화 및 디버깅.md
T
2026-05-10 22:08:15 +09:00

5.4 KiB

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

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

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)

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 설정

# 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

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

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

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 반영