R7: add a VPS/VDS sizing table (min/avg/max) to the trip report
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 9s
CI / integration (pull_request) Successful in 13s
CI / ui (pull_request) Successful in 36s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 57s

A practical single-host ordering guide — CPU cores, RAM, disk at three tiers —
grounded in the R7 profile (~5.5 cores / ~2.5 GiB peak at 500 players) and the
measured on-disk footprint (images ~2.4 GB; Tempo 3.1 GB at 72 h; the game DB
23 MiB and growing). Notes which knobs move disk (Tempo/Prometheus retention,
Postgres growth) and that the gateway scales horizontally past one host.
This commit is contained in:
Ilia Denisov
2026-06-11 11:32:09 +02:00
parent 2a48df9b83
commit 225188e4b5
+27
View File
@@ -172,6 +172,33 @@ prod contour env (the same compose, `PROD_*` values):
safe); pin `GOMAXPROCS` to each CPU limit; keep json-file rotation. safe); pin `GOMAXPROCS` to each CPU limit; keep json-file rotation.
- Memory is not the constraint anywhere; CPU is. - Memory is not the constraint anywhere; CPU is.
### VPS / VDS sizing (single-host contour)
The whole contour (the app + the observability stack) runs on one host via
`docker-compose`. The tiers below are grounded in the R7 profile (**≈5.5 cores / ≈2.5 GiB
RAM peak at 500 concurrent players**; ≈0.5 GiB idle) and the **measured** on-disk
footprint: prod images ≈2.4 GB; the Tempo volume **3.1 GB at 72 h** retention; Prometheus
≈12 GB at 15 d; the game DB 23 MiB and growing with history. CPU and disk grow; RAM has
the most slack.
| tier | CPU | RAM | disk | handles |
|------|-----|-----|------|---------|
| **Minimum** | 2 cores | 2 GiB | 20 GiB | ~up to ~150 concurrent; lower the compose limits (gateway 1.5 / backend·postgres 1 / tempo 1 GiB) to fit the box |
| **Average** (reasonable load) | 4 cores | 4 GiB | 40 GiB | ~300400 concurrent comfortably; the tested 500 with occasional gateway burst-throttling |
| **Maximum** (worry-free) | 8 cores | 8 GiB | 80 GiB | 500+ concurrent with full gateway burst headroom (its 3-core cap) + room to grow; the compose limits fit as-is |
- The per-service limits in `docker-compose.yml` are tuned for the **Average/Maximum**
target (the gateway alone caps at 3 cores). On the **Minimum** tier, scale them down to
match the host or the caps over-subscribe it.
- **Disk is dominated by observability retention + DB growth.** Tempo (72 h traces) and
Prometheus (15 d metrics) are the main levers — shorten the windows (or move Tempo to
object storage) to cut disk; Postgres grows with game history, so budget for months of
it; container logs are already capped (json-file 10m × 3 ≈ 30 MiB each).
- **RAM** rarely binds: the contour peaks ≈2.5 GiB at 500 players and the sum of all
configured limits is ≈5.6 GiB, so 8 GiB never strains.
- Beyond one host's worth of players, scale the **gateway horizontally** (it is
connection-CPU-bound) rather than ordering an ever-bigger box.
## Re-running ## Re-running
See [`README.md`](README.md). Briefly, from the repo root: See [`README.md`](README.md). Briefly, from the repo root: