Files
2nd/10_Wiki/Topics/Domain_Programming/Programming & Language/Nodejs 성능 최적화 및 디버깅.md
T
Antigravity Agent c24165b8bc refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-11 11:05:56 +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 반영