komari更新你给我更好了呀🥹🥹

还是1.2.5稳定啊

1.25养老吧

下午从1.2.6降级到了1.2.5fix2 不折腾了

Komari Monitor 报错排查

错误摘要：

failed to remove obsolete metric memory.total: context deadline exceeded

含义：程序启动时清理过期指标数据，SQLite数据库操作超时，数据库文件大概率过大、锁死、文件损坏。

当前使用 ./data/metrics.db SQLite 存储，这是轻量模式通病：指标数据累积后删除旧数据极易超时、数据库锁定。

方案1：优先尝试（保留历史数据）

1. 先停止 Komari 服务（Docker就stop容器，避免持续占用数据库文件）


2. 进入服务器，对 metrics.db 执行整理（VACUUM，清理碎片）

sqlite3 ./data/metrics.db "VACUUM;"



    

  

如果这条命令卡住，说明数据库严重损坏/磁盘IO满载，直接跳方案2。

3. 启动服务，尝试在页面重新提交DSN ./data/metrics.db 建立连接。

方案2：快速应急（丢失历史监控指标，最快恢复面板）

提示：面板设置、节点配置不会丢失，仅清除历史性能曲线数据

1. 停止 Komari


2. 直接删除指标数据库文件

rm ./data/metrics.db



    

  

3. 启动服务，页面填入原DSN：./data/metrics.db，提交恢复连接。
   
   程序会自动新建干净的 metrics.db，面板立刻恢复正常。

方案3：根治方案（强烈推荐，解决SQLite性能瓶颈）

页面提示已经写明：SQLite不适合长期大量指标存储。

后续迁移至 MySQL/MariaDB 或者 PostgreSQL，不会再出现删除指标超时、database locked 问题。

额外排查点（上面操作无效时检查）

1. 磁盘IO负载/磁盘已满
   
   查看磁盘使用率 df -h；如果磁盘100%占用，SQLite所有操作都会超时。


2. 权限问题
   
   程序进程没有读写 ./data/ 目录权限，导致文件操作缓慢/失败。


3. 如果你使用Docker部署
   
   确认挂载目录正确，不要同时多个容器挂载同一个metrics.db，SQLite不支持多进程并发读写。

操作顺序建议

1. 先停止服务 → 执行VACUUM


2. VACUUM卡住/执行完依旧报错 → 直接移走旧metrics.db重建（方案2）


3. 稳定运行后，抽空迁移到 MariaDB/PostgreSQL 彻底规避该类问题

1.2.5升级1.2.7没问题啊 一切都好 增加了降采样降低数据库压力

升级1分钟后打开komari然后手动迁移数据库就好了

你什么都不干就会出问题

@spaceET #6 确实什么都不干就会出问题，8条延迟，12台机，1d 6.5g数据库

看作者这更新频率我都懒得管了

@Doornail #5 老大推荐用什么数据库

mariadb@AlterEgo #9

别追新，能用就行！

1.2.5fix2养老吧

1.2.7我没遇到中断问题，就是数据库膨胀太快

@卡拉彼丘 #13 刚去修这个前一看，12台机 8条监控 1d的留存，6.5g的数据库

现在换MariaDB了但愿没问题

@Inklazy #14 我11台机设置1d留存，不到两天时间给我塞了快6g。现在搞了个定时每天凌晨4点自动删除数据库了

MariaDB开源还免费 ^-^