c24165b8bc
에이전트 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>
5.4 KiB
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 |
|
none | A | 0.9 | applied |
|
2026-05-10 | pending |
|
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_SIZEdefault 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.
매 응용
- Memory leak 의 추적 — heap snapshot diff.
- CPU bottleneck 의 식별 — flame graph.
- 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 반영 |