Documentation
¶
Overview ¶
Package reslimits answers one question honestly: did a container actually receive the resource ceiling the benchmark intended for it?
Issue #141 §7 pins every app to 2 vCPU / 1 GiB and PostgreSQL to 2 vCPU / 2 GiB, and is explicit that if a limit can't be enforced the suite must "detect and report that fact rather than silently pretending limits were applied." A budget written in compose.yml is an intention, not proof. Whether `deploy.resources.limits` takes effect depends on the engine/Compose version and the host's cgroup support: Docker Compose v2 applies the limits on a plain `docker compose up` (verified locally against Compose v5.x), but a Swarm-mode stack, an older Compose (v1, and early v2 that needed `--compatibility`), or a host missing the required cgroup controllers can leave the container unlimited. So the evidence is the *running container*, not the file. This package reads the limits Docker recorded for the container (via `docker inspect`'s HostConfig — NanoCpus and Memory, where 0 means unlimited). These are the daemon's post-adapt create config, not a read of `/sys/fs/cgroup`, but the daemon zeroes or rejects a limit it cannot apply, so reading them back is an honest signal that an intended ceiling was dropped. It classifies them against the intended budget, producing the honest string a run records as metadata.resource_limits (the `make benchmark-crud-all` loop wires it per app; standalone run-crud records its own honest default).
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func FormatBytes ¶
FormatBytes renders a byte count as a compact 1024-based string (GiB/MiB/KiB) for human verdicts; whole units drop the fraction.
func ParseBytes ¶
ParseBytes parses a compose-style memory string ("1g", "512m", "2048k", or a bare byte count) into bytes, using 1024-based units the way Docker does.
Types ¶
type Applied ¶
Applied is what a container actually received, read from `docker inspect` (.HostConfig.NanoCpus and .HostConfig.Memory). Docker uses 0 as the "unlimited" sentinel for both fields — what you get whenever the intended limit never reached the kernel.
func ParseInspect ¶
ParseInspect reads the Applied limits from `docker inspect <container>` output (a JSON array; the first element is used).
type Budget ¶
type Budget struct {
CPUs float64 // whole vCPUs, e.g. 2
MemoryBytes int64 // e.g. 1 GiB = 1073741824
}
Budget is an intended per-container ceiling (issue #141 §7).
type Report ¶
type Report struct {
Container string `json:"container,omitempty"`
Budget Budget `json:"budget"`
Applied Applied `json:"applied"`
Status Status `json:"status"`
CPUVerdict string `json:"cpu"` // e.g. "2.00 vCPU (intended 2.00)"
MemVerdict string `json:"memory"` // e.g. "unlimited (intended 1.0 GiB)"
Explanation string `json:"explanation,omitempty"`
}
Report is the classification of one container against its budget, plus the human-readable, honest string for metadata.resource_limits.
type Status ¶
type Status string
Status is the overall enforcement verdict for one container.
const ( // Enforced: both CPU and memory match the intended budget. Enforced Status = "enforced" // NotApplied: neither limit was applied — the container runs unlimited, // so the compose.yml budget never reached the kernel. NotApplied Status = "not-applied" // Partial: some limits are applied and some are missing or wrong, so the // container is not running under the intended budget. Partial Status = "partial" )
Source Files