Commit a4d3724
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 duration1 parent 31df747 commit a4d3724
1 file changed
Lines changed: 19 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
249 | 249 | | |
250 | 250 | | |
251 | 251 | | |
| 252 | + | |
| 253 | + | |
| 254 | + | |
| 255 | + | |
| 256 | + | |
| 257 | + | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
| 265 | + | |
| 266 | + | |
| 267 | + | |
| 268 | + | |
| 269 | + | |
| 270 | + | |
252 | 271 | | |
253 | 272 | | |
254 | 273 | | |
| |||
0 commit comments