docs: publish the measured memory floor, not a guessed limit - #283
Conversation
CashPilot-4c22 asked for a number with its provenance rather than a limit, and that is what this is. Read from the kernel's own high-water mark (memory.peak) on a live install after 8 hours of normal operation, covering roughly 8 hourly collection cycles: cashpilot-ui steady ~72 MiB PEAK 207 MiB cashpilot-worker steady ~65 MiB PEAK 130 MiB (image 1.14.1, 15 managed containers, 54.7 MB database) THE POINT IS THE GAP. The UI idles near 72 MiB and peaks near 207 -- close to three times its resting size -- because collection runs every collector in-process. So a limit chosen by looking at a running container is almost certainly too low: 128 MiB looks generous against 72 MiB and will be exceeded on the first collection cycle. And an OOM here does not look like one. The container is killed mid-collection and restarts; the dashboard keeps serving the last figures it stored, so nothing on screen is wrong and the symptom is "earnings stopped updating", days later. The shipped compose files still set NO limit. This page now explains how to choose one if you want one, and says to re-measure on your own install rather than trusting these figures. Every percentage was recomputed rather than estimated -- an earlier draft said "256 MiB is only 19% above 207 MiB", which conflated headroom-as-share-of-limit with headroom-above-peak. It now states the absolute figure, 49 MiB. Filed separately: the live fleet is running with exactly that 49 MiB of spare, which is a production limit and so Sergio's call, not a change to make here.
|
Warning Review limit reached
Next review available in: 53 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Closes CashPilot-4c22, which asked for a number with its provenance, not a limit.
Measured, not estimated
Read from the kernel's own high-water mark (
memory.peak) on a live install after 8 hours of normal operation — roughly 8 hourly collection cycles:cashpilot-uicashpilot-workerProvenance: image
1.14.1, 15 managed containers, 54.7 MB SQLite database, collectors running hourly in-process under APScheduler.The point is the gap
The UI idles near 72 MiB and peaks near 207 — close to three times its resting size — because collection runs every collector in-process.
So a limit chosen by looking at a running container is almost certainly too low. 128 MiB looks generous against 72 MiB and will be exceeded on the first collection cycle.
And an OOM here does not look like an OOM
The container is killed mid-collection and restarts. The dashboard keeps serving the last figures it stored, so nothing on screen says anything is wrong — the symptom is "earnings stopped updating", noticed days later.
That is exactly why this page gives a number and a way to re-measure, rather than shipping a limit. The compose files still set none.
Arithmetic checked, not eyeballed
An earlier draft said "256 MiB is only 19% above 207 MiB" — which conflated headroom as a share of the limit (19%) with headroom above the peak (24%). Every figure is now absolute and unambiguous: 49 MiB spare, not a percentage that can be read two ways.
Filed separately
The live fleet is running with exactly that 49 MiB of spare on
cashpilot-ui. That is a production limit, so it is your call rather than a change to make here — filed with the measurement and a suggestion.mkdocs build --strictpasses; 4351 tests pass.