存储与容量规划
ServerBee 常用部署场景的数据库容量计算公式和 30 天存储估算。
本页介绍 ServerBee 的 SQLite 数据库如何随时间增长，并为常见的 20 服务器部署场景提供 30 天存储估算。
这些数值于 2026 年 4 月通过临时 SQLite 数据库测量得出，采用当时的仓库数据库结构和默认保留策略。请将本页作为注明日期的容量规划基准，而不是对后续数据库结构或工作负载的保证。结果描述的是全新部署运行 30 天后的主数据库文件大小。在生产环境中，请额外预留 10% 到 20% 的空间作为 SQLite WAL（预写日志）和临时增长的缓冲。
假设条件
本页所有估算使用以下基线条件：
- 20 台服务器
- 从全新部署开始运行 30 天
- Agent 持续连接
- Agent 上报间隔为 3 秒
- 服务器原始指标写入器每 60 秒 为每台服务器写入一条记录
- 默认保留策略：
- 原始指标：7 天
- 小时聚合数据：90 天
- GPU 记录：7 天
- Ping 记录：7 天
- 网络探针原始记录：7 天
- 网络探针小时记录：90 天
- 服务监控记录：30 天
- 磁盘 I/O 和温度监控已启用
- 除非明确说明，否则不包含审计日志突发增长、大型任务输出或异常的 Docker 事件波动带来的额外增长
哪些功能会影响数据库大小
并非每个功能都会产生持续的数据库增长。
| 功能 | 默认频率 | 保留时间 | 主表 | 说明 |
|---|---|---|---|---|
| 基础监控 | Agent 每 3 秒上报，每 60 秒持久化 | 原始 7 天，小时 90 天 | records、records_hourly、traffic_*、uptime_daily | 连接的服务器始终存在 |
| Ping 任务 | 每任务 60 秒 | 7 天 | ping_records | 随任务数 × 服务器数扩展 |
| 网络探针 | 每目标 60 秒 | 原始 7 天，小时 90 天 | network_probe_record、network_probe_record_hourly | 随服务器-目标分配数扩展 |
| 服务监控 | 每监控 300 秒 | 30 天 | service_monitor_record | 随监控数扩展 |
| GPU 监控 | 每 GPU 设备 3 秒 | 7 天 | gpu_records | 这是最大的乘数之一 |
| Docker 事件 | 事件驱动 | 7 天 | docker_event | 除非容器频繁变更，否则占用很小 |
| 终端 / 执行 / 文件管理器 | 用户驱动 | 混合 | audit_logs、task_results | 通常比时序数据小得多 |
开启终端、执行、文件管理器或 Docker 管理等功能不会自动创建大型时序表。持续增长来自那些主动写入采样结果的功能。
30 天容量估算公式
基于上述假设，30 天数据库大小可通过以下公式估算：
S_30d =
70,541,312
+ 48,974,507 × P
+ 2,373,018 × T
+ 1,593,958 × M
+ 41,525,248 × G
+ 285 × E其中：
P= 应用于全部 20 台服务器的 60 秒 Ping 任务 数量T= 总的 服务器-目标网络探针分配数- 如果每台服务器目标数相同，则
T = 20 × 每台服务器目标数
- 如果每台服务器目标数相同，则
M= 总的 300 秒服务监控数G= 总的 GPU 设备数E= 30 天窗口期内写入的 Docker 事件总数
功能乘数
这些系数来自实际测量的 SQLite 文件，而非粗略估算：
| 组件 | 精确大小贡献 | 约等大小 |
|---|---|---|
| 20 台服务器的基础监控 | 70,541,312 B | 67.27 MiB |
| 1 个跨全部 20 台服务器的 Ping 任务 | 48,974,507 B | 46.71 MiB |
| 1 个网络探针分配 | 2,373,018 B | 2.26 MiB |
| 1 个服务监控 | 1,593,958 B | 1.52 MiB |
| 1 个 GPU 设备 | 41,525,248 B | 39.60 MiB |
| 1 个 Docker 事件 | 285 B | 0.28 KiB |
基础监控细目
在没有额外 Ping 任务、网络探针、服务监控或 GPU 的情况下，30 天占用空间主要来自原始指标表及其索引：
| 对象 | 精确大小 | 约等大小 |
|---|---|---|
records | 48,701,440 B | 46.45 MiB |
idx_records_server_id_time | 16,482,304 B | 15.72 MiB |
records_hourly | 3,485,696 B | 3.32 MiB |
idx_records_hourly_server_time | 1,163,264 B | 1.11 MiB |
traffic_hourly + 索引 | 512,000 B | 0.49 MiB |
traffic_daily + 索引 | 90,112 B | 0.09 MiB |
uptime_daily + 索引 | 86,016 B | 0.08 MiB |
场景目录
下表列出 20 台服务器部署的常见 30 天场景：
| 场景 | 假设条件 | 精确大小 | 约等大小 |
|---|---|---|---|
| 仅基础监控 | 无 Ping 任务、无网络探针、无服务监控、无 GPU | 70,541,312 B | 67.27 MiB |
| 基础 + 1 个 Ping 任务 | 1 个跨全部 20 台服务器的 60 秒 Ping 任务 | 119,515,819 B | 113.98 MiB |
| 基础 + 3 个 Ping 任务 | 全部 20 台服务器的 ICMP + TCP + HTTP | 217,464,833 B | 207.39 MiB |
| 基础 + 每台 1 个目标 | 共 20 个网络探针分配 | 118,001,672 B | 112.54 MiB |
| 基础 + 每台 5 个目标 | 共 100 个网络探针分配 | 307,843,112 B | 293.58 MiB |
| 基础 + 每台 20 个目标 | 共 400 个网络探针分配（当前上限） | 1,019,748,512 B | 972.51 MiB |
| 基础 + 每台 1 个监控 | 共 20 个 300 秒间隔的服务监控 | 102,420,472 B | 97.68 MiB |
| 基础 + 每台 5 个监控 | 共 100 个 300 秒间隔的服务监控 | 229,937,112 B | 219.29 MiB |
| 基础 + 每台 1 个 GPU | 共 20 个 GPU 设备 | 901,046,272 B | 859.30 MiB |
| 小型生产环境 | 3 个 Ping 任务 + 每台 1 个目标 + 每台 1 个监控 | 296,804,353 B | 283.05 MiB |
| 中型生产环境 | 3 个 Ping 任务 + 每台 5 个目标 + 每台 2 个监控 | 518,524,953 B | 494.50 MiB |
| 重型环境（无 GPU） | 3 个 Ping 任务 + 每台 20 个目标 + 每台 1 个监控 | 1,198,551,193 B | 1.12 GiB |
| 重型环境（含 GPU） | 重型环境（无 GPU）+ 每台 1 个 GPU | 2,029,056,153 B | 1.89 GiB |
| 最大实用环境 | 3 个 Ping 任务 + 每台 20 个目标 + 每台 5 个监控 + 每台 1 个 GPU | 2,156,572,793 B | 2.01 GiB |
磁盘预算建议
如果正在为实际部署进行容量规划，请预留比数据库文件本身更多的空间：
- 以上表作为基础数据库大小
- 增加 10% 到 20% 作为 WAL 增长和突发写入的缓冲
- 如果预期有以下情况，请额外增加空间：
- 大量 Docker 事件
task_results中保留的大型任务输出- 具有大型
detail_json负载的异常频繁的服务监控
示例：
- 一个
494.50 MiB的中型环境应预留约 550 MiB 到 600 MiB - 一个
1.89 GiB的含 GPU 重型环境应预留约 2.1 GiB 到 2.3 GiB - 一个
2.01 GiB的最大实用环境应预留约 2.2 GiB 到 2.5 GiB
注意事项和说明
- 这些估算针对全新部署的前 30 天。某些小时表保留长达 90 天，因此长期运行的部署会继续增长，超过此处显示的 30 天数值。
- 基础监控估算已包含
traffic_hourly、traffic_daily和uptime_daily。 - GPU 增长是按设备计算的，不是按服务器。一台有 4 个 GPU 的服务器会使 GPU 部分乘以 4。
- 网络探针增长是按分配计算的，不是按目标定义。一个被 20 台服务器共享的目标算作 20 个分配。
- Docker 增长是事件驱动的。静态的容器集群几乎不增加空间；容器繁忙的主机可能增加可观的量。