# Resource Usage

> Historical CPU, memory, disk, and network observations for the ServerBee Agent and Server.

URL: https://docs.serverbee.app/en/docs/resource-usage

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](/en/docs/storage-sizing).

<Callout type="info">
  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.
</Callout>

## Agent [#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 [#server]

### Historical Railway observation [#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 [#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 [#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](https://github.com/ZingerLittleBee/ServerBee/blob/main/tests/manual/server-memory-soak.md). 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 [#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](/en/docs/storage-sizing) for database estimates and [Backup and Restore](/en/docs/deployment#persistent-data) for files outside SQLite. Reserve space for WAL, bursts, and complete backup sets in addition to the base database.

## Caveats [#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.

## Related Docs [#related-docs]

<Cards>
  <Card title="Storage & Capacity Planning" href="/en/docs/storage-sizing" />

  <Card title="Agent Setup" href="/en/docs/agent" />

  <Card title="Deployment Guide" href="/en/docs/deployment" />
</Cards>