Komari 1.2.6建议观望，尤其是小鸡性能差或者数据库太大的

Grok 2026-07-12 21:40 1

换个数据库是好事，数据库转换太费劲了

数据一多（监控数据久、频率高、机器多）或者小鸡超冒烟E5v2单核solo还是1G内存这种，建议别升，现在我的鸡2C2G已经死了，连SSH都费劲，上面跑的几个docker全掉了。即使勉强连上目前是内存跑满，一开始是CPU占满，要是在绿云估计已经一键三连清退了

建议留守1.2.5，等后续版本优化升级转换流程，🐔不多干脆直接重装。

最新回复 (31)

KUmaDev 07-12 21:41

1楼

发生了什么，我还在还在1.2.5
mioe 07-12 21:41

2楼

已经改用cf worker探针了
天道酬善 07-12 21:42

3楼

还是明天早上上班摸鱼重装吧。
akanotanin 07-12 21:42

4楼

“要是在绿云估计已经一键三连清退了”笑死hhhhhhhhh
coldsword 07-12 21:43

5楼

监控数据不重要的话其实可以删掉
Grok 楼主 07-12 21:44

6楼

VNC上来了，内存爆炸，进程全停了，2G内存吃不住，数据库大概190W条。
vono 07-12 21:45

7楼
1.2.6

2026/7/12 19:36:16

主要更新内容
- 新增数据库 vacuum 和大小查询 API 端点
- 完全重构 metrics 存储层：移至专用 metric store，支持 SQLite/MySQL/PostgreSQL 后端及数据迁移
- 重构服务端启动生命周期为显式阶段（Bootstrap → InitStores → InitProviders → StartBackground → BuildRouter → Run → Shutdown）
- 统一配置热重载管理（ReloadManager），隔离 handler panic
- 新增版本升级自动备份机制（./backup/upgrade-{time}.zip）
- 新增 metrics 保留策略管理与定时 rollup 压缩
- 新增 Ping 记录写入 metric store（指标 ping.latency_ms / ping.loss）
- 新增 metric store 存储大小查询与空间回收（VACUUM / OPTIMIZE TABLE / VACUUM FULL）
- 迁移旧记录表（records / records_long_term / gpu_records / ping_records）数据至 metric store（一次性迁移）
- 新增 EntityIDs API 用于批量查询实体
- 新增 DeleteOidcConfigByName 数据库方法
- RPC 层引入 Principal 身份模型，替代单一角色字符串
- Hot-reload metrics DB 配置，保存前执行连接测试
- metrics DB 驱动自动从 DSN 推断
- 支持迁移暂停/恢复、进度持久化与孤儿状态修复
- 新增 install-komari.sh 的 TUI 交互（whiptail/dialog）及 stable/snapshot 通道选择
- 编译安装脚本新增 Zig 工具链缓存
先观望一段时间 ^-^
xiaohong2 07-12 21:49

8楼

直接卡死了
joingonna 07-12 21:50

9楼

还好是1.2.5，先观望一会
哈哈雨来了 07-12 21:51

10楼

1欧小鸡面板端，更新完十分钟了，CPU还是100% ^-^
xixu520 07-12 21:54

11楼

目前还1.2.5。升级后怎么说？
梦影 07-12 21:57

12楼

^-^ 华为云上倒是挺快的，一分钟全好了
ssd 07-12 21:58

13楼

^-^ 我的探针还真在绿云上先不更了
卡拉彼丘 07-12 22:00

14楼

延迟数据保存时间改成1小时，再升级版本，这样少很多数据 ^-^ 1.2.6有个问题，默认保存90天数据，手动修改成7天，默认主题可以应用到，旧的第三方主题依旧显示90天选项卡
神秘人 07-12 22:02

15楼

服务端吗？

我是1.1.0 安装在zeabur上
春丽奶奶 07-12 22:02

16楼

@Grok #0 还好我部署在垃圾小鸡上 CPU95%+大概有15分钟
Wa1ter 07-12 22:04

17楼

^-^ 还行 5分钟内解决了，应该是我数据不多
huilang 07-12 22:07

18楼

试试CF探针，省一台小鸡 https://github.com/huilang-me/CF-Server-Monitor
tsubasa 07-12 22:09

19楼

我甲骨文AMD上的，不定时在崩……

原因不明……看日志也没看出啥问题，磁盘IO也不高
GitLab 07-12 22:10

20楼

只做基础信息监控，权限控制到位，能正常使用完全没必要升级
一袋猫粮 07-12 22:14

21楼

@tsubasa #19

我也是，过一会能打开，但网页特别卡
duya 07-12 22:34

22楼

一个小时左右了还没好
seamee 07-12 22:35

23楼

还好 bero 性能强，不然也难顶
Yannick 07-12 22:36

24楼

重新安装了哎 ^-^
jsdyhy 07-12 22:40

25楼

我是手工升级，没升级
seamee 07-12 22:43

26楼

完全处理完多了 7 个 g 的数据，emmm
zleywb 07-12 22:54

27楼

最近几天才装的1.2.5，直接命令升级了，数据不多很顺利
Xiuyixx 07-12 23:06

28楼

@KUmaDev #1 建议先别升级
railzen 07-13 00:21

29楼

@seamee #26 我看你就10台 7个G吗？
philsilver 07-13 01:08

30楼

还行，用的龟壳的ARM，只花了几十秒吧，刷新一下就正常了 ^-^
Nanami-Sama 07-13 04:02

31楼

1c1g的9950x,开了8GB以上的swap才勉强能跑起来，然而实时监测啥的都不行，感觉还是数据降采样那边的问题。。。跑够15分钟之后CPU内存占用掉下来了，一会儿又涨上去了..... ^-^ ^-^ ^-^

这个数据库迁移太灾难了 ^-^ ^-^ ^-^