数据库与空间维护
Komari Lite 默认使用两类 SQLite 数据：主数据库保存账号、服务器、任务和设置；监控数据库保存指标、延迟、丢包和分层摘要。
文件组成
SQLite 运行时通常包含：
*.db：主数据库文件。*-wal：已经提交但尚未检查点回主文件的页。*-shm：WAL 协调共享内存文件。
页面中的“总占用”应包含数据库文件、WAL 和 SHM。只看 .db 文件会漏掉运行时占用。
为什么主库会变大
WAL 检查点把数据页写回 .db 后，主文件变大、WAL 变小是正常现象，总占用才是应观察的指标。网页上 WAL 保持不变也不能证明没有写入主库。
SQLite 删除记录后会形成可复用空闲页，文件不会自动按删除量缩小。后续写入会优先复用这些页。
数据压缩与接力
2.1.12 使用更紧凑的无损摘要编码，并统一同一探测任务的延迟与丢包存储。分层接力按批次运行，避免在单核、ARM64 和慢速磁盘上长时间占用写锁。
同一份已填满约 7 天的实测数据库从 21.84 MiB 降至 18.81 MiB，减少约 13.9%。这是特定样本的实测结果，不代表所有实例都按同一比例缩小。
2.2.1 历史数据安全修复
启动时的指标清理只处理真正失效的数据，不再删除 memory.total、swap.total、temperature 和 disk.total 等仍在使用的系统指标定义及其历史记录。升级或重启后，这些曲线应继续保留在原有时间范围内。
仪表盘和公开主题的历史查询改为按可共享条件批量读取并在扫描过程中聚合。接口只缓存有界的最终结果，不缓存原始指标，也不写回聚合数据，因此不会因打开仪表盘额外增大数据库文件。
WAL 维护
WAL 截断失败不会删除尚未安全落盘的数据。系统会保留 WAL 并在后续条件合适时重试。页面显示的“预计下次截断”应随真实执行结果更新。
如果日志持续出现 context deadline exceeded，应同时检查：
- CPU 和磁盘是否长期饱和。
- 是否有大量 1 秒或 5 秒探测任务。
- 是否正在执行迁移、回收空间或长周期查询。
- 容器卷是否位于性能较差的网络盘。
回收空间
“回收空间”会整理 SQLite 文件并尝试把空闲页归还给磁盘。它适合以下情况：
- 刚完成大版本迁移或大量历史数据清理。
- 已经确认业务低峰且磁盘有临时工作空间。
- 需要立即释放空间，而不是等待后续数据复用空闲页。
不要把回收空间设为高频定时任务。数据库繁忙时等待或失败并不意味着数据损坏。
资源自适应
缓存和查询并发会结合容器内存限制、可用内存和 CPU 核心数自动调整。单核或内存较小的环境会限制重型历史扫描并发；多核、内存充足时允许有限的独立批次并行。单次批量扫描保持流式处理，不按节点无限创建并发任务。
节点数量增加主要影响数据规模和查询时间，不会按节点数为每个连接固定分配一整份大缓存。相同请求会合并计算，百分位摘要等额外状态只在实际请求时创建。