Resource Usage
Historical CPU, memory, disk, and network observations for the ServerBee Agent and Server.
This page preserves historical resource observations for the ServerBee Agent and Server. They are not benchmarks of the current release. For database growth estimates, see Storage & Capacity Planning.
Source: the measurement notes originally recorded on this page for v0.9.3, dated 2026-05-19 unless noted otherwise. Raw benchmark logs and exact binary linkage were not archived with those notes. Memory/CPU readings are historical observations; the Agent network figure is a protocol-based estimate. Measure your deployed version, allocator, Agent count, enabled collectors, and query load before setting resource limits.
Agent
The original notes describe a 4-core AMD EPYC 7B13 / 8 GB / Ubuntu 24.04 (KVM) host, Agent v0.9.3, a 3-second collection interval, temperature collection enabled, and reporting to a remote Server over an HTTPS WebSocket.
| Resource | Cold start (~90s) | After 8h | Scope |
|---|---|---|---|
| Memory (systemd cgroup) | ~4.3 MB, peak ~5.1 MB | ~27 MB, peak ~28 MB | Cgroup accounting; a different scope from process RSS |
Memory (ps RSS) | ~10 MB | ~34 MB | Process resident memory, including shared mappings |
| CPU | ~0.7% (single core) | ~0.5% (single core) | Observed collection workload |
| Threads | 10 | 9–10 | Observed tokio runtime |
| Binary size | ~11 MB | — | Historical linux-amd64 binary |
| Network | Estimated ≤ 1–2 KB/s | — | One SystemReport JSON per 3-second interval plus ping/pong; varies with metrics |
Memory increased during the eight-hour observation. Those readings alone do not establish a long-term plateau or distinguish allocator retention from a leak. The recorded host OS does not establish which libc the binary used.
Server
Historical Railway observation
The original page recorded roughly 140–170 MB with a small number of Agents and MALLOC_ARENA_MAX=2 present in the environment. It also reported 800 MB–1 GB after 2–3 days in another run. The notes do not capture exact build linkage, Agent count, query load, or a controlled comparison. These are historical readings, not evidence that the environment variable caused the difference or a memory target for the current release.
Historical self-hosted idle observation
The v0.9.3 notes describe a near-idle Server on the same VPS with no active Agent connections:
| Resource | Observed | Scope |
|---|---|---|
| Memory (systemd cgroup) | ~15 MB, peak ~23.8 MB | Historical idle observation, not a loaded-server requirement |
| Threads | 7 | Observed tokio runtime |
| CPU | Near zero | Idle workload |
| Binary size | ~47 MB | Historical linux-amd64 binary with the frontend SPA embedded |
Allocator and build scope
MALLOC_ARENA_MAX applies to glibc's allocator. Official Linux release binaries and Docker images use musl, where this variable has no effect. The standard deployment examples therefore do not set it. For a custom glibc build, assess allocator behavior against that build's measurements rather than applying the old Railway numbers.
A separate release-toolchain regression affected v1.0.0-beta.1: the recorded idle Server grew about 20 MB per day because of cross-thread free behavior in Zig 0.16's bundled allocator. The release workflow now pins Zig 0.15.2; the correction shipped in v1.0.0-beta.2. Its cause, observation scope, and reproduction procedure are recorded in the release memory soak runbook. This is a distinct observation from the v0.9.3 figures above. Use a current release and investigate sustained growth on the actual deployed build.
Disk
Server disk use includes SQLite, uploaded brand images, downloaded GeoIP/ASN MMDB files, and configuration. Database growth depends on Agent count, enabled features, and retention. See Storage & Capacity Planning for database estimates and Backup and Restore for files outside SQLite. Reserve space for WAL, bursts, and complete backup sets in addition to the base database.
Caveats
- The historical idle Server readings do not describe many Agents or heavy query load.
- Cgroup memory and process RSS measure different scopes; compare like with like.
- Agent network usage is an estimate, not a captured traffic benchmark.
- A steady eight-hour reading does not prove long-term stability. Investigate unexplained growth with workload and allocator context.