9148c358d0
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
5.3 KiB
5.3 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-chrome-v8-heap-analysis | Chrome V8 Heap Analysis | 10_Wiki/Topics | verified | self |
|
none | A | 0.9 | applied |
|
2026-05-10 | pending |
|
Chrome V8 Heap Analysis
매 한 줄
"매 heap snapshot 의 retain path". 매 V8 의 mark-sweep + generational GC 의 internal state 의 DevTools Memory tab 을 통한 introspection 의 production 의 leak 의 root cause 의 identification 의 enable. 매 2026 년 의 Chrome 132+ 의 trace-based + sampling allocator 의 < 5% overhead 의 production profiling 의 standard.
매 핵심
매 Snapshot 종류
- Heap snapshot: 매 모든 reachable object 의 graph 의 capture. 매 retainers 의 trace.
- Allocation timeline: 매 시간 에 따라 allocate 된 object 의 추적. 매 churn 의 detection.
- Allocation sampling: 매 lightweight (5% 이하 overhead). 매 production 의 OK.
매 V8 GC structure
- Young generation (Scavenger): 매 fast minor GC. 매 semi-space copying.
- Old generation (Mark-Sweep-Compact): 매 incremental mark + concurrent sweep.
- Code space, Map space, Large object space: 매 separate region.
매 응용
- Memory leak hunt — DOM detached node 의 detection.
- Bundle size 의 runtime impact analysis.
- Closure-induced retention 의 audit.
- Listener leak 의 trace.
💻 패턴
Programmatic snapshot (Node.js / Electron)
const v8 = require('v8');
const fs = require('fs');
function takeHeapSnapshot(label) {
const path = `./heap-${label}-${Date.now()}.heapsnapshot`;
const stream = v8.getHeapSnapshot();
stream.pipe(fs.createWriteStream(path));
return path;
}
// Usage: take 3 snapshots, compare in DevTools
takeHeapSnapshot('baseline');
runWorkload();
global.gc?.();
takeHeapSnapshot('after-gc');
Detached DOM detection
// In Console / Snapshot Comparison view
// Filter by "Detached HTMLDivElement"
// → retainer chain shows the closure / array holding it
class LeakyComponent {
constructor() {
this.handlers = [];
document.addEventListener('scroll', this.onScroll); // leak: never removed
}
onScroll = () => { /* ... */ }
}
// Fix: store bound ref, removeEventListener in destroy()
CDP (Chrome DevTools Protocol) automation
const CDP = require('chrome-remote-interface');
async function profileHeap() {
const client = await CDP();
const { HeapProfiler } = client;
await HeapProfiler.enable();
await HeapProfiler.collectGarbage();
const chunks = [];
HeapProfiler.on('addHeapSnapshotChunk', ({ chunk }) => chunks.push(chunk));
await HeapProfiler.takeHeapSnapshot({ reportProgress: false });
return chunks.join('');
}
Sampling allocation profiler
// V8 11+, ~512KB sample interval
const profiler = require('v8-profiler-next');
profiler.startSamplingHeapProfiler(512 * 1024, 64);
// ... workload ...
const profile = profiler.stopSamplingHeapProfiler();
fs.writeFileSync('alloc.heapprofile', JSON.stringify(profile));
--inspect + automated diff
node --inspect=0.0.0.0:9229 server.js
# Connect Chrome DevTools → Memory → take snapshot
# Run load test → take 2nd snapshot
# Comparison view → filter "Delta > 0" + sort by Retained Size
Constructor filter (find specific class instances)
// In DevTools heap viewer
// class: SomeBigBuffer → see all live instances + retainers
// Common pattern: a Map / Set holding stale references
--max-old-space-size tuning
node --max-old-space-size=4096 --expose-gc app.js
# or for Chrome:
chrome --js-flags="--max-old-space-size=8192"
매 결정 기준
| 상황 | Approach |
|---|---|
| Production leak (live) | Sampling allocation profiler (low overhead) |
| Dev / staging deep dive | Full heap snapshot diff (3-snapshot technique) |
| Allocation hotspot | Allocation timeline |
| Specific class instances | Constructor filter |
| CI regression check | Programmatic v8.getHeapSnapshot() + threshold |
기본값: 매 3-snapshot technique (baseline → workload → after-gc → diff).
🔗 Graph
- 부모: V8 Engine · Chrome DevTools Memory Profiling
- 변형: Electron V8 Memory Cage
- 응용: Memory Leak Detection · Performance Optimization
- Adjacent: Garbage Collection
🤖 LLM 활용
언제: 매 leak 의 reproducibility 의 OK 의 case. 매 retainer chain 의 interpretation 의 LLM 의 강점. 언제 X: 매 production 의 large heap (> 4GB) 의 snapshot 의 capture 의 비용 (multi-second pause).
❌ 안티패턴
- Snapshot before GC X: 매 항상
--expose-gc+global.gc()후 snapshot. 매 noise 의 reduction. - Single snapshot 의존: 매 항상 diff. 매 absolute size 의 less informative.
- Closures의 underestimate: 매 arrow function 의 lexical scope 의 모든 outer var 의 retain.
🧪 검증 / 중복
- Verified (V8 docs, Chrome DevTools docs, Node.js v8 module).
- 신뢰도 A.
🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — V8 heap snapshot / leak hunting workflow |