Skip to content

Commit a4d3724

Browse files
committed
Bench(docs[lgtm]): State how long a load run can be
why: The shipped scenarios run 10 and 16 seconds, so nothing in the recipes approaches a limit and a reader has no reason to suspect one. A long run used to climb in memory until it ended in swap rather than in a clean error, which presents as a CPU spike that never recovers. Bisecting it showed removing the OTel sink left the growth unchanged while removing rampa's per-iteration recording cut it by 70%: the cause was rampa's runner buffering every sample for outputs that were never configured, and it is fixed upstream. what: - State that duration is safe, and name the version the growth belongs to, so a climbing run has an obvious first thing to check - Explain why the pane's holding command outlasts any plausible duration
1 parent 31df747 commit a4d3724

1 file changed

Lines changed: 19 additions & 0 deletions

File tree

scripts/lgtm/README.md

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -249,6 +249,25 @@ Going through the sink instead means it lands under the same metric names and
249249
the same branch, worktree, and spike labels as every other run, and the two are
250250
directly comparable.
251251

252+
### How long a run can be
253+
254+
The shipped scenarios run 10 and 16 seconds, but a long `--duration` is safe:
255+
a steady run holds about 100 MB resident whatever its length, growing by
256+
roughly 100 bytes per iteration rather than accumulating.
257+
258+
That depends on the rampa version. Through 0.0.1a1, `rampa run` attached its
259+
sample buffer unconditionally, so every metric sample was retained for the
260+
whole run even when no configured output would read it. On this workload that
261+
was about 1.75 KB per iteration -- 4 MB/s, climbing linearly with no plateau to
262+
2.25 GB after nine minutes, which on a memory-capped host ends in swap rather
263+
than a clean error. If a run's memory climbs steadily, check whether rampa
264+
predates that fix before looking anywhere else.
265+
266+
The tmux server's pane runs a holding command that outlasts any plausible
267+
`--duration` by design. If it exited first the window would close, the last
268+
window closing would end the session, and the server would go with it
269+
mid-run -- `destroy-unattached off` only survives *detach*.
270+
252271
## Why the acceptance check exists
253272

254273
A dashboard that renders is not a dashboard that works. A panel whose query

0 commit comments

Comments
 (0)