联犀开发者文档

服务器配置与容量评估

约 2573 字大约 9 分钟

性能容量规划部署压测

2026-10-19

设备规模上来之后，「为什么同样的程序，换台服务器就跑不动了」是最常见的问题。本文把设备属性上报链路的资源消耗拆开讲清楚：CPU、磁盘、内存、网络各自卡在哪，实测能跑到多少，以及如何按设备规模和上报频率估算服务器配置。

本文口径为单机 all-in-one 部署：应用、MQTT Broker（comqtt/EMQX）、PostgreSQL、Redis 等全部部署在同一台服务器上，文中的实测数据与配置建议（含 8C8G 的容量上限）均基于该形态。单机容量受 CPU、磁盘 IO、数据库连接池与网络共同约束；如果需要更大体量（超过单机约 150,000 msg/min），应通过集群化部署或多服务器拆分扩展——例如 Broker 独立、数据库独立、应用多实例/分片——而不是继续堆高单机配置。

一、容量评估

输入在线设备数、每设备每单位时间（分钟/小时/天可切换）消息数、入库消息占比与数据保留时长（按年 + 月填写），即可得到最低/推荐配置与最低/推荐磁盘容量建议。只统计需要入库的消息——心跳、实时转发等不入库消息不计入容量；计算公式与口径在下方「计算依据」中展开。评估结果为估算值，仅供参考，实际以压测与业务场景为准。

设备规模
在线设备数连接数约等于在线设备数
台
上报频率
每设备每天消息数按设备实际上报间隔填写
条
入库与存储
入库消息占比只统计需要入库的消息，心跳与实时转发不计入
%
数据保留时长历史数据保留周期，按年 + 月填写（1 年按 365 天、1 月按 30 天折算）
年月
计算依据
  • 每分钟消息数 = 在线设备数 × 每设备每单位时间消息数 × (60 ÷ 单位秒数)（单位秒数：分钟 60 / 小时 3600 / 天 86400）。
  • 入库 msg/min = 每分钟消息数 × 入库占比；CPU、内存与磁盘只按入库消息统计。
  • CPU 最低 = max(2, ⌈入库 msg/min ÷ 18,000⌉ + ⌈在线设备数 ÷ 20,000⌉)；推荐按目标负载的 1.5 倍预留余量并向上取 2 核台阶（max(最低 CPU, ⌈入库 msg/min × 1.5 ÷ 18,000⌉ + ⌈在线设备数 ÷ 10,000⌉)），小规模时与最低一致。
  • 内存最低 = 4GB 基础（含 1.5GB 轻量余量）+ max(0, ⌈(入库 msg/min ÷ 60,000 + 在线设备数 × 2KiB − 1.5GB) ÷ 4GB⌉) × 4GB；推荐按 1.5 倍目标速率、系数改为 ÷48,000 与 4KiB，且不低于最低内存。
  • 磁盘日增 = 入库 msg/min × 1,440 × 1,000B（每天 1,440 分钟；实测含索引约 1KB/条，按 1,000B 估算）。
  • 最低磁盘 = 日增 × 保留时长 + 20GB（系统、容器镜像与基础日志等固定占用）；保留时长 = 年 × 365 + 月 × 30 天。
  • 推荐磁盘 = 日增 × 保留时长 × 1.5 + 40GB，1.5 倍覆盖索引、WAL 与备份，40GB 覆盖日志轮转、备份与临时空间。
  • 本估算不含音视频与 AI：音视频需按「路数 × 码率 × 保留天数」单独计算磁盘并追加 CPU；AI 推理、向量库与 Token 缓存需追加内存与算力（GPU）。

二、四类资源与性能的关系

上报链路可以简化为：MQTT 接入 → 消息解析 → 入库队列 → 数据库批量写入。四类资源分别卡在不同环节：

资源主要消耗点不足时的典型表现
CPU消息解析、属性处理、入库事务构造队列消化变慢、p99 上升，但失败不一定是 CPU 打满
磁盘数据库 WAL 刷盘、数据文件写入入库事务变慢（单批 500ms+），队列打满、出现 tsdbQueueBusy
内存每连接缓冲、设备/产品缓存、数据库缓存连接数上不去、频繁 GC、OOM
网络设备连接与消息收发建连超时、心跳断连、跨网压测时吞吐上不去

1.1 CPU：不是「核越多越好」，而是看单核效率

实测 120,000 msg/min（10000 台设备、每 5 分钟上报一次）时：应用约 2.6 核、数据库约 1 核。也就是说，8 核机器跑 120,000 msg/min 时 CPU 只用了约 45%，剩余空间用于吸收突发和业务查询。

CPU 不足的典型表现是入库队列持续积压。但要注意：队列满不一定是 CPU 问题——连接池、批量大小、磁盘延迟都会让队列先满。排查时应先看数据库 CPU 与磁盘等待，再看应用 CPU。

1.2 磁盘：上报场景的第一瓶颈

属性上报是写密集型负载，数据库的 WAL 刷盘直接决定入库速度。实测对比：

  • 机械盘 / 共享虚拟盘（4K fsync 160~600ms）：入库消费能力只有 24,000~42,000 msg/min，120,000 msg/min 档失败率可达 60% 以上。
  • NVMe SSD（fsync < 10ms）：120,000~150,000 msg/min 稳定，失败率 0.000%~0.068%。

因此：上报型部署必须使用 SSD/NVMe。机械盘不是「慢一点」，而是会把稳定容量直接砍掉一半以上。

磁盘容量分为两档：最低磁盘 = 日增 × 保留时长 + 20GB（覆盖系统、容器镜像与基础日志等固定占用）；推荐磁盘 = 日增 × 保留时长 × 1.5 + 40GB（额外覆盖索引、WAL、备份与日志轮转余量）。

容量计算器不含音视频与 AI 能力。需要接入音视频（录像、直播、转码）时，按「路数 × 码率 × 保留天数」单独追加磁盘，并相应增加 CPU；需要接入 AI（模型推理、向量库、Token 缓存）时，需额外增加内存与算力（GPU），不能沿用本页的纯上报配置。

1.3 内存：连接数决定下限，缓存决定上限

内存由两部分构成：

  • 每连接开销：内置 MQTT broker（comqtt）每个连接约 2KiB 出站缓冲（3 万连接实测约 76MB）。
  • 业务基础内存：应用约 1GB、数据库约 1GB、系统与容器约 2GB，合计约 4GB。

最新版实测：1,000 台在线设备、60,000 msg/min 时整机 used 约 1.8~2.0GB（4C8G），此时 CPU 70~82%；旧版 1 万设备、120,000 msg/min 时 used 4~5GB。连接内存不是大头，超过 5 万连接时建议拆分 broker 或使用独立 MQTT 集群。

1.4 网络：压测机与服务端不要跨公网

压测时如果模拟器与服务端跨公网（例如经内网穿透），上行带宽会成为新瓶颈：实测上行 22Mbps 时，120,000 msg/min 档失败率从 0.000% 恶化到 1.96%。压测机应与服务端同机房或同机部署，否则测出的是网络上限，不是平台上限。

三、实测基线（4C8G / 8C8G + NVMe）

以下数据来自 1000~10000 台设备、每条上报 5 类属性（int/float/bool/string/struct）、record-mode 2（按变化入库）。为便于阅读，速率统一按每分钟消息数（msg/min）展示。

4C8G + 最新版（1000 台设备）

上报速率时长结果整机 used整机 CPU
6,000 msg/min10 分钟0 失败，p99 9.0ms1.26~1.39GB0.1~0.3 核
60,000 msg/min10 分钟0 失败（59.5 万条），p99 61ms1.81~1.97GB2.8~3.3 核（70~82%）
72,000 msg/min2 分钟0 失败，p99 82ms1.87~2.03GB3.1~3.9 核（78~98%，超限）

4C8G 的瓶颈是 CPU：60,000 msg/min 时内存只用了约 2GB，CPU 已到 70~82%；72,000 msg/min 时 CPU 峰值接近 100%。若内存限制在 1.6GB，最高约 6,000 msg/min。

8C8G + NVMe（10000 台设备）

上报速率失败率p50p95p99结论
120,000 msg/min0.000%（5/1,194,960）5.9ms156ms380ms稳定
150,000 msg/min0.068%（1,012/1,494,438）6.9ms126ms1.5s稳定（需连接池 150）
180,000 msg/min6.14%——1.7s超限

容量结论：

  • 4C8G + 最新版：CPU 上限约 60,000 msg/min（1000 msg/s），此时内存约 2GB；要求 CPU 严格不超过 80% 时建议按 54,000 msg/min 预留余量。
  • 8C8G + NVMe：稳定上限约 150,000 msg/min；日常 120,000 msg/min 建议 12 核 / 12GB 留余量。
  • 超过单机上限后需要横向扩展（多实例/分片）或降低单条上报的数据量。

四、优化方案（按收益排序）

配置项建议值说明
dbMaxOpenConns150最关键。入库 worker 上限会被数据库连接池夹取；60 时 2500 档失败率 1.576%，150 时降到 0.068%
TSDB_ASYNC_WORKERS128入库 worker 上限（8 核 × 16）；动态伸缩水位 ≥25% 扩容
TSDB_BATCH_MAX100单事务最多整包数。实测 250/500 会拉长事务持锁时间、挤压业务 API，不建议超过 200
REPORT_DEGRADEauto压力期自动降级热点日志、设备消息日志与在线对账
ConnNum（dm.rpc）1多个消费者会重复订阅同一下行 topic、造成重复处理；1 个连接足够
GOGC / GOMEMLIMIT100 / 内存的 70~80%降低 Go 堆保留；GOGC=200 更省 CPU 但内存占用更高
synchronous_commitoff时序遥测语义（设备重发兜底），显著降低 WAL 刷盘等待
shared_buffers1GB（8C8G）/ 256MB（4C8G 及以下）低配降到 256MB 可省约 450MB 内存，对 60,000 msg/min 以内足够
日志轮转单文件 100MB × 3避免设备消息日志无上限增长占满磁盘
wal_buffers / max_wal_size64MB / 8GB减少 checkpoint 频率与 WAL 等待
checkpoint_timeout30min避免周期性写入毛刺
random_page_cost1.1SSD 专用，提升索引扫描选择
预热先 30,000 msg/min 跑 2 分钟冷启动时设备缓存与数据库缓存未就绪，直接上高并发会误判为容量不足

此外：压测或高负载期间可暂停 TimescaleDB 的后台聚合作业，避免其与写入高峰相撞。

五、低配置部署调整建议

低配（2C4G / 4C8G 及以下）不是把容器启动起来就行，需要同步收紧内存和日志。

2C4G（约 6,000 msg/min 以内）

  • PostgreSQL：shared_buffers=256MB、effective_cache_size=1GB
  • edge：GOGC=100、GOMEMLIMIT=2GiB
  • REPORT_DEGRADE=auto，Docker 日志限制为单文件 100MB × 3
  • ConnNum=1；关闭 TimescaleDB 后台聚合作业
  • 磁盘使用 NVMe，保留周期按需缩短
  • 实测：1,000 台、6,000 msg/min，整机 used 1.26~1.39GB，10 分钟 0 失败

4C8G（约 60,000 msg/min 以内）

  • 内存参数同上；shared_buffers 可保持 256MB（省内存）或 512MB（查询较多时）
  • CPU 是瓶颈：60,000 msg/min 时整机 CPU 70~82%，要求严格 80% 以内建议按 54,000 msg/min 预留
  • 实测：1,000 台、60,000 msg/min，整机 used 1.81~1.97GB，10 分钟 0 失败（59.5 万条）

低配通用注意

  • 不要在同一台机器上跑压测模拟器、AI 推理或音视频转码
  • 内存受限时优先降 PG shared_buffers，再调低 GOGC；不要靠调大进程内存上限硬撑
  • 上报频率和保留时长直接决定 CPU 与磁盘，低配优先降频率、缩短保留周期

六、连接数与内存的估算

整机内存 ≈ 4GB 基础（应用约 1GB + 数据库约 1GB + 系统/容器约 2GB）
         + 连接数 × 2KiB（每连接出站缓冲）
         + 入库速率带来的缓存/队列增量（约每 60,000 msg/min 增加 2GB）
连接数仅连接内存整机内存建议（中等上报）
1 万~20MB8GB
3 万~60MB8~16GB
10 万~200MB16GB 起（还需评估文件句柄与网络栈）

实测校准（最新版）：

  • 4C8G、1,000 台、6,000 msg/min：整机 used 1.26~1.39GB
  • 4C8G、1,000 台、60,000 msg/min：整机 used 1.81~1.97GB，CPU 70~82%
  • 8C8G、10,000 台、120,000 msg/min（旧版）：整机 used 4~5GB，8GB 稳定

连接内存不是大头，真正的内存消耗来自业务基础内存（应用与数据库常驻）、设备/产品缓存与时序数据页缓存。连接数超过单机 5 万时，建议拆分 broker 或使用独立 MQTT 集群。

更新日志

2026/10/20 09:14
查看所有更新日志
  • b3f5b-docs(容量评估): 按最新版实测更新配置公式与低配置建议于
  • 61e09-docs: 新增服务器配置与容量评估文章及容量计算器于