codebase-memory-mcp 代码智能 MCP 内存泄漏排查指南用 trajectory.ndjson 快速定位趋势【免费下载链接】codebase-memory-mcpHigh-performance code intelligence MCP server. Indexes codebases into a persistent knowledge graph — average repo in milliseconds. 158 languages, sub-ms queries, 99% fewer tokens. Single static binary, zero dependencies.项目地址: https://gitcode.com/GitHub_Trending/co/codebase-memory-mcpcodebase-memory-mcp 是一款高性能的代码智能 MCP 服务器它能把代码仓库索引成持久化知识图谱——158 种语言、亚毫秒级查询、单文件静态二进制。当你怀疑它后台驻留进程内存越吃越多时无需重启、无需猜内置的诊断机制会周期性把内存指标写成 trajectory.ndjson你只需要读出趋势曲线就能区分真泄漏还是分配器碎片。1. 什么时候该怀疑内存泄漏先给结论避免瞎忙长期驻留codebase-memory-mcp 以守护进程形式后台运行RSS 缓慢爬升数小时甚至数天后需要复现验证而不是看一次进程列表就下结论查询量与内存不成比例查询次数queries没怎么涨RSS 却持续上涨才值得深挖误报高发mimalloc 内部计数器在 Linux 上的 RSS 读数曾虚报出17 EB 泄漏必须以 /proc 的真实 RSS 为准实现上已修复见 src/foundation/diagnostics.c。所以第一步不是装 Valgrind而是让项目自己的诊断线程帮你记录趋势。2. 一键开启诊断CBM_DIAGNOSTICS 环境变量的最快配置方法只需要在启动时加一个环境变量配置详情见 docs/CONFIGURATION.mdexport CBM_DIAGNOSTICS1 # 然后正常启动 codebase-memory-mcp开启后会发生什么实现见 src/foundation/diagnostics.c在系统临时目录Linux 的$TMPDIR或/tmpWindows 的%TEMP%下创建仅属主可访问的随机目录cbm-diagnostics-pid-XXXXXX一个后台线程每 5 秒写一次snapshot.json并向trajectory.ndjson追加一行守护进程在${CBM_CACHE_DIR}/logs/cbm-daemon.log里写一条diagnostics.start发现记录单行 JSON里面就是这两个文件的随机路径——即使你把CBM_LOG_LEVEL设成none这条记录也一定会输出保证路径永远可被发现。 官方长稳测试 scripts/soak-test.sh 就是靠CBM_DIAGNOSTICS1跑出这些趋势数据的你可以照着它的方式做自己的复现。3. 快速找到 trajectory.ndjson三步定位路径步骤操作①找到缓存目录默认~/.cache/codebase-memory-mcp可被CBM_CACHE_DIR覆盖②打开logs/cbm-daemon.log搜索diagnostics.start③从该行 JSON 中读出trajectory字段的路径即是trajectory.ndjson文件本身有自动轮转写到 8 MB 上限时旧文件会被改名为trajectory.ndjson.1见 src/foundation/diagnostics.c。进程正常退出时会删掉实时的snapshot.json但trajectory 会保留专门留给事后分析。4. trajectory.ndjson 字段速查每一行代表 5 秒一个采样点每行是一条紧凑 JSON字段含义如下字段含义看什么uptime_s进程存活秒数横轴时间rss当前真实 RSSLinux 取自 /proc内存趋势主曲线peak_rss峰值 RSS是否被单次尖峰拉高committed分配器提交字节数与 RSS 对比判断碎片peak_committed提交峰值分配器历史高点page_faults缺页次数单调上涨内存页持续扩张fd打开的文件描述符数排查 fd 泄漏queries累计 MCP 工具调用次数内存增长是否与业务量相关5. 三种典型趋势判读核心干货① 真实泄漏rss与queries不相关地持续上涨、且永不回落包括空闲期。这是最需要修的形态。② 分配器碎片/保留页committed高企但rss平稳。mimalloc 把内存提交后未归还 OS属于持有空闲页而非泄漏。此时看分配器账本才有结论见下节CBM_MEM_STATS。③ 正常波动rss随索引/查询量阶跃空闲期回落peak_rss记录高点但曲线不单调——这是工作集变化不是泄漏。⚠️ 判读口诀rss 单调涨 queries 不涨 查代码committed 涨而 rss 平 查分配器两者随业务同步波动 正常。6. 用 snapshot.json 分配器账本进一步定位trajectory 是粗粒度趋势需要精确到哪块内存没还时再看每 5 秒重写的snapshot.json关键字段mem_live_bytes/mem_live_blocks分配器账本里的活块——持续增长才是真泄漏的铁证mem_residual_bytesOS 提交量减活块量的差值——持续变大指向碎片/保留页其定义见 src/foundation/mem.hquery_avg_us/query_max_us顺带确认慢查询是否伴随内存尖峰。开发者级深挖可选export CBM_MEM_STATS1 # 每次快照额外输出 cbm-allocator-stats-pid.txt该文件包含 mimalloc 的完整统计和 arena 图能区分提交后空闲碎片与仍被引用泄漏两种状态见 src/foundation/diagnostics.c。相关回归保障在 tests/test_diagnostics.c。7. 常见问题 FAQQ路径是随机的怎么防止自己找不到文件A永远从cbm-daemon.log的diagnostics.start记录里取路径不要手拼。Qtrajectory 会撑爆磁盘吗A不会。8 MB 自动轮转为trajectory.ndjson.1目录是属主私有的退出即清理父目录。QWindows 上能用吗A能。诊断目录落在%TEMP%路径记录机制完全一致。总结CBM_DIAGNOSTICS1一行开启 → 从 daemon 日志拿 trajectory 路径 → 按rss vs queries vs committed三条线判读是排查 codebase-memory-mcp 内存趋势最省时间的路径。【免费下载链接】codebase-memory-mcpHigh-performance code intelligence MCP server. Indexes codebases into a persistent knowledge graph — average repo in milliseconds. 158 languages, sub-ms queries, 99% fewer tokens. Single static binary, zero dependencies.项目地址: https://gitcode.com/GitHub_Trending/co/codebase-memory-mcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考