Resource Usage
Measured runtime CPU, memory, disk, and network footprint for the ServerBee Agent and Server.
This page records the measured runtime resource footprint of the ServerBee Agent and Server, covering CPU, memory, disk, and network. For detailed disk (database) growth capacity planning, see Storage & Capacity Planning.
These values are measured, not estimated. Unless noted otherwise, they were taken on 2026-05-19 using v0.9.3. Usage varies with the collection interval, number of connected Agents, whether GPU/temperature collection is enabled, and dashboard query load — the figures here are stable order-of-magnitude references.
Agent
The Agent is a lightweight probe with negligible CPU cost and a steady-state memory footprint in the tens of MB.
| Resource | Cold start (~90s) | Steady state (8h uptime) | Notes |
|---|---|---|---|
| Memory (systemd cgroup, real private memory) | ~4.3 MB, peak ~5.1 MB | ~27 MB, peak ~28 MB | Most accurate memory figure |
Memory (ps RSS, includes shared library mappings) | ~10 MB | ~34 MB | Overestimate, includes shared libs |
| CPU | ~0.7% (single core) | ~0.5% (single core) | Stable, includes the per-3s collection spike |
| Threads | 10 | 9–10 | tokio runtime |
| Binary size | ~11 MB | — | linux-amd64 release |
| Network | One SystemReport JSON per collection interval (3s default) plus periodic ping/pong; on the order of ≤ 1–2 KB/s | — | Scales with interval and enabled metrics |
Measurement environment: 4-core AMD EPYC 7B13 / 8 GB / Ubuntu 24.04 (KVM), Agent v0.9.3, 3s collection interval, temperature collection enabled, reporting to a remote Server over an HTTPS WebSocket.
Memory rose from ~5 MB at cold start to ~27 MB over 8 hours (at 8h the current value ≈ the peak, so it appears to be near a plateau, pending 24h confirmation). Same root cause as the Server: the Agent is also Rust + tokio, and glibc's default multi-arena allocator hoards freed memory inside the process instead of returning it to the OS (sysinfo produces many small allocations every 3s). This is not a code-level leak. If steady-state memory needs to be reduced further, set MALLOC_ARENA_MAX=2 on the Agent's systemd service.
For comparison: among comparable resident monitoring agents, Netdata often reaches tens to hundreds of MB, Telegraf ~30–50 MB, node_exporter ~15–20 MB. The ServerBee Agent's steady-state ~27 MB memory + <1% CPU is still in the lightweight tier.
Server
Server memory is driven mainly by the number of connected Agents, dashboard/API query load, and the data retention policy.
Production reference (Railway, real workload)
A production instance with a small number of connected Agents, after setting MALLOC_ARENA_MAX=2 (suppresses glibc multi-arena memory retention):
| Resource | Measured | Notes |
|---|---|---|
| Memory | Steady ~140–170 MB, flat over time with no sustained climb | Healthy level |
Without MALLOC_ARENA_MAX=2 (or switching to jemalloc), glibc's default multi-arena allocator hoards freed memory inside the process instead of returning it to the OS, and long-running RSS climbs continuously (observed climbing to ~800 MB–1 GB over 2–3 days). This is not a code-level memory leak, but setting this environment variable is recommended when deploying the Server.
Self-hosted idle reference
A near-idle Server instance (no active Agent connections) on the same VPS:
| Resource | Measured | Notes |
|---|---|---|
| Memory (systemd cgroup) | ~15 MB, peak ~23.8 MB | Idle lower-bound reference |
| Threads | 7 | tokio runtime |
| CPU | Near zero at idle | Rises with Agent count and query load |
| Binary size | ~47 MB | linux-amd64 release, embeds the frontend SPA |
Disk
Server disk usage comes from the SQLite database and grows with the number of servers, enabled features, and retention policy. For the full 30-day capacity formulas and scenario catalog, see Storage & Capacity Planning. In production, reserve an extra 10%–20% on top of the base database size as a buffer for WAL and burst writes.
Caveats
- The Railway memory figure assumes
MALLOC_ARENA_MAX=2is set; it does not apply otherwise. - The self-hosted Server figures were taken near-idle and do not represent usage under many Agents or heavy query load — treat them as a lower bound only.
- Agent network usage is an order-of-magnitude estimate based on protocol behavior; actual values vary with the collection interval and enabled metrics.
- All values are order-of-magnitude references for capacity planning and anomaly detection (watch the trend, not the absolute value: steady = healthy, continuously climbing without recovery = investigate).