宝塔监控数据写入太勤拖垮磁盘io，需关闭系统监控并调采集周期至30秒，再执行vacuum和设history_num.pl为3天，以将system.db控制在20–50mb。
宝塔监控数据写入太勤，直接拖垮磁盘IO
宝塔面板默认每3秒采集一次系统指标（CPU、内存、磁盘IO、网络等），并写入 SQLite 数据库 /www/server/panel/data/system.db。在低配机器或 SSD 性能一般的云服务器上，高频小写入极易触发 I/O 队列堆积，iotop -oP 中常能看到 /usr/bin/python（即面板主进程）持续占满 w/s 和 wkB/s。这不是“监控有用”，而是它在反复刷盘。
停掉实时监控 + 调低采集频率（最有效两步）
别只调“保存天数”——那只是删旧数据，不解决写入压力源头。必须先砍采集频次：
- 登录宝塔面板 → 左侧【监控】→ 关闭「系统监控」开关（这是最关键的一步，立刻停止所有采集）
- 如需保留基础监控，进终端执行：
sed -i "s/'cycle': 3,/'cycle': 30,/g" /www/server/panel/class/system.py
把采集周期从 3 秒拉长到 30 秒（注意：改完需重启面板bt restart） - 确认修改生效：
grep cycle /www/server/panel/class/system.py应输出含'cycle': 30的行
清理历史监控数据 + 限制保存天数
已写入的监控数据会不断膨胀 system.db，即使停采，SQLite 自动 vacuum 不够及时，仍可能引发后台 IO 毛刺：
- 进终端执行：
sqlite3 /www/server/panel/data/system.db "VACUUM;"
手动触发数据库空间回收 - 限制保留时长（非默认的 30 天）：
echo '3' > /www/server/panel/data/history_num.pl
设为仅存最近 3 天（数字可改，单位：天） - 该文件不存在时，面板会 fallback 到 30 天；存在则严格按数值清理，每天凌晨自动执行
rm旧记录
为什么不能只调保存天数？
很多人只改 history_num.pl，发现 IO 还是高——因为删除动作本身也是磁盘写操作，尤其当 system.db 已超 200MB 时，每天一次大删会瞬间拉高 %util。真正省 IO 的逻辑是：少写比多删更治本。30 秒采集 + 3 天保留，能让 system.db 稳定在 20–50MB 区间，iotop 里几乎看不到它的 IO 波动。
