Codex Monitor：一键监控 logs_2.sqlite 写入、资源占用与日志来源

概要：

前面为了排查 Codex 的 logs_2.sqlite 写入，我分别使用过 Procmon、PerfMon、任务管理器和 SQLite 查询。手工流程能够解释每个指标，但每轮都要开始捕获、记起止值、导出文件和计算结果，确实比较繁琐。

所以我把常用步骤整理成了 Codex Monitor。第一次仍然需要准备 Procmon 和一份过滤配置；配置完成后，每轮只需要“开始监控”和“停止并分析”，工具会自动保存原始数据、生成 HTML 报告并列入历史记录。

关于应该监控哪些项目、每个数字怎么解释，以及如何手工做 30 分钟 A/B 测试，单独放在：

Codex 本地资源手工监控：磁盘、CPU、内存、GPU 与日志指标

本文只讲一键工具的下载、设置和使用。

概要：
1. 下载与前置条件
2. 第一次配置 Procmon
3. 一键开始与停止
4. 监控时能看到什么
5. 停止后会得到什么
6. 一键工具与手工监控项目的关系
7. 指标边界
8. 常见问题
结论

1. 下载与前置条件

下载 Codex Monitor（ZIP）

解压后会看到：

文件	用途
`Start-CodexMonitor.cmd`	双击启动监控器
`CodexMonitor.ps1`	WPF 界面、性能采样、Procmon 控制和报告生成
`sqlite_snapshot.py`	只读查询日志快照与新增 target
`README.md`	离线配置说明

当前版本默认按我本机的目录布局工作：

1
2
3

D:\ProcessMonitor\Procmon64.exe
D:\ProcessMonitor\CodexMonitor.pmc
D:\ProcessMonitor\CodexMonitorRecords\

因此需要先从微软 Sysinternals 下载 Process Monitor，并把 Procmon64.exe 放到 D:\ProcessMonitor。记录也默认保存在 D 盘，不会写进 C 盘的监控记录目录。

工具本身不需要安装。双击启动时会出现一次 UAC 提示，因为 Procmon 捕获文件事件需要管理员权限。

其他目录

PowerShell 脚本支持 -ProcmonRoot 和 -DataRoot 参数，但双击启动脚本使用上面的默认目录。想更换盘符时，可以修改 Start-CodexMonitor.cmd 中的启动命令，或直接带参数运行 CodexMonitor.ps1。

2. 第一次配置 Procmon

Codex Monitor 会优先加载 D:\ProcessMonitor\CodexMonitor.pmc。这份文件需要在 Procmon 中手工导出一次。

按 Ctrl + E 停止捕获、Ctrl + X 清空已有事件，然后依次添加：

Path       begins with  C:\Users\你的用户名\.codex\logs_2.sqlite  Include
Operation  is           WriteFile                            Include
Operation  is           FlushBuffersFile                     Include
Operation  is           SetEndOfFileInformationFile          Include

每一条都要点击 Add，确认出现在窗口下方的规则列表中。接着设置：

启用 Filter → Drop Filtered Events；
工具栏只保留 Show File System Activity；
打开 File → Backing Files，选择 Virtual Memory；
使用 File → Export Configuration，保存为 D:\ProcessMonitor\CodexMonitor.pmc。

不要添加 Result is SUCCESS

实测 Procmon 4.04 在 Result is SUCCESS 与 Drop Filtered Events 同时启用时，可能把目标事件全部丢弃。工具会在导出 CSV 后自行严格筛选 SUCCESS，所以 PMC 中不需要这条规则。

PMC 不只保存过滤条件，也会保存 Backing Files 等界面状态。如果导出配置时仍指向旧的 .pml，以后加载可能提示：

1	An error occurred opening the snapshot

因此导出前要切回 Virtual Memory。监控器也会检查固定 PMC 中的旧 snapshot 路径、缺失操作和已知有问题的 Result is SUCCESS，发现异常时给出明确提示。

3. 一键开始与停止

配置完成后，每轮只有三步：

双击 Start-CodexMonitor.cmd，同意管理员权限提示；
点击“开始监控”，正常使用 Codex；
点击“停止并分析”，等待 Procmon 导出完成并打开报告。

开始前不要保留其他 Procmon 窗口或捕获任务。监控器发现 Procmon 已经运行时会拒绝开始，避免停止本轮监控时误关掉你的其他记录。

关闭正在监控的窗口只会停止 Procmon，不会导出 CSV 或生成完整报告。正常结束应使用“停止并分析”。

4. 监控时能看到什么

应用会自动识别 Windows Codex 桌面端相关的 ChatGPT.exe、codex.exe 和 codex-code-mode-host.exe。

“实时监控”页每 5 秒刷新：

CPU，100% 表示占满一个逻辑处理器；
Private Working Set 和 Private Bytes；
Codex 相关进程总 I/O，作为实时辅助趋势；
Codex 相关进程的 GPU Engine；
logs_2.sqlite、WAL、SHM 文件大小；
当前识别到的相关进程数。

“日志 Top 5”页每 15 秒只读查询一次游标之后的新增行，并按插入行数列出前五个 target，同时显示：

新增行数与行占比；
estimated_bytes 内容规模估算；
TRACE、DEBUG、INFO、WARN、ERROR 级别分布；
“低级别噪声候选”或“含 WARN/ERROR，先保留”等过滤提示；
已捕获新增行相对 ID 增量的覆盖率。

本机实测一次增量查询约 76～84 ms，每 15 秒运行一次，通常不是主要资源负担。它不会创建 Trigger，也不会主动执行 checkpoint。

监控过程中暂时看不到 Procmon 的精确数据库写入总量。这个数字需要停止捕获后导出并解析全部事件，才会进入最终报告。

5. 停止后会得到什么

记录默认保存在：

1	D:\ProcessMonitor\CodexMonitorRecords\年月日-时分秒\

每轮通常包含：

文件	用途
`report.html`	关键指标、自动分析结论和需要留意的项目
`summary.json`	结构化汇总，便于脚本读取和多轮比较
`samples.csv`	每 5 秒一次的性能与文件大小采样
`procmon.pml`	Procmon 原始逐文件事件
`procmon.csv`	停止时自动导出的可读事件

最终报告会计算：

主库、WAL、SHM 成功 WriteFile 的字节数、次数、分项和每小时速率；
FlushBuffersFile 与 SetEndOfFileInformationFile 的总数和分文件数量；
checkpoint-like 主库写回批次、以 Flush 收尾的批次、伴随文件扩展的批次和约合 4 KiB 页数；
CPU、内存、GPU 和进程总 I/O 的平均值、峰值与起止变化；
主库、WAL、SHM 文件大小变化；
日志 ID 增量、净保留行变化与估算删除/淘汰量；
本轮 target Top 5、级别分布、覆盖率和过滤提示；
根据以上数据生成的中文分析结论。

“监控历史”页会列出已有轮次，双击即可重新打开报告，也可以直接打开记录目录。

6. 一键工具与手工监控项目的关系

一键工具没有发明另一套指标。它只是把手工监控篇中分散的工具串成同一轮自动采集：

一键工具中的项目	手工监控中的来源	关系与差别
数据库逻辑写入量、次数、主库/WAL/SHM 分项	Procmon	使用同一类文件事件；工具自动开始、停止、导出和汇总，原始 PML/CSV 仍可复核
Flush、SetEnd、checkpoint-like 批次	Procmon checkpoint 调查	从同一份事件近似归组，不是 SQLite 内部 checkpoint 的精确计数
CPU、Private Working Set、Private Bytes	PerfMon 进程计数器	适合日常短时趋势；长时间无人值守或独立验证仍可用 PerfMon
GPU Engine	任务管理器 / PerfMon GPU	工具按 Codex 相关进程汇总；手工检查更容易定位具体进程、引擎和窗口状态
日志 ID、保留行数、target Top 5	SQLite 查询	自动保存起止快照并做增量分组；手工 SQL 更便于自定义查询和检查原始行
主库、WAL、SHM 文件大小	文件大小快照	都只能表示净变化，不能代替累计逻辑写入量
任务时间和卡顿体验	人工记录	工具不能替人判断，A/B 测试仍需手工记录

所以日常复测可以只开 Codex Monitor；想修改过滤条件、调查异常数字、做长时间 PerfMon 记录或审计原始事件时，再回到手工流程。两篇不是两套需要同时运行的方案，也不要把一键报告与同一轮手工数据重复相加。

7. 指标边界

数据库写入主指标是目标文件成功 WriteFile 的 Length 合计，代表应用层逻辑写入请求；它不等于文件净增长，也不等于 SSD 的最终 NAND 写入。
FlushBuffersFile 是 Flush 请求。系统与设备缓存仍可能合并或延后物理落盘，Flush 次数不能直接当作刷盘完成次数。
checkpoint-like 批次按连续主库写入及后续 Flush/SetEnd 近似归组，不是 SQLite 暴露的精确 checkpoint 计数。
实时“进程 I/O”包含 Codex 对其他文件和设备的写入，只是辅助趋势，不参与数据库写入是否偏高的主要结论。
文件大小只表示监控起止时的净变化，看不到覆盖旧页、WAL 循环使用或写入后清理。
target Top 5 按新增行数排序，内容估算无法把 SQLite 页、WAL、索引与事务开销准确分摊到单个 target。被 Trigger 拦截的日志不会进入表中，也不会出现在排名里。
SQLite 快照依赖可用的 Python sqlite3。Codex 本机运行时通常已经包含它；找不到时只跳过日志行数与 target 分析，不影响 Procmon 和资源采样。

8. 常见问题

报告提示“未获取 SQL 起始快照”

这通常表示开始监控时没有找到可用的 Python/sqlite3、数据库被暂时锁定，或者只读查询启动失败。报告会保留具体原因；Procmon、CPU、内存、GPU 与文件大小数据仍然有效，但这一轮不能可靠计算日志 ID 增量和完整 target 覆盖率。

Procmon 打开 PMC 时提示 snapshot 错误

在 Procmon 中打开 File → Backing Files，切换到 Virtual Memory，再重新导出 CodexMonitor.pmc。捕获到的事件不会保存进 PMC；PMC 保存的是配置和状态，真正的事件位于 PML。

捕获结果是空的

先检查 PMC 中是否还存在 Result is SUCCESS，并确认每条 Path/Operation 规则都点过 Add。还要启用文件系统活动，并确认 Path 使用的是当前 Windows 用户的真实目录。

停止分析需要一段时间

停止时 Procmon 要关闭 PML、导出 CSV，再由监控器逐行汇总。如果捕获时间较长或事件很多，这一步会比平时更慢；不要在导出期间直接关闭窗口。

结论

Codex Monitor 解决的是重复操作问题：第一次配置好 Procmon，之后每轮只点击开始和停止，就能同时保留实时趋势、日志来源、逐文件写入和自动分析结论。

它并没有取代手工监控知识。报告中的每个核心数字仍然对应 Procmon、性能计数器、文件大小或 SQLite 查询；遇到异常时，可以沿着同一口径回到原始 PML、CSV 和 SQL 继续检查。