non_burglar@lemmy.world 3 days ago
So, couple things here:
- Most VPS have elastic memory, meaning they can borrow burst ram from the host for short periods. This means you 1GB vps can probably run at 1.5GB or even two during some demanding jobs for a short time. And depends on the provider.
- You don’t document how you installed any of these.
- .net core doesn’t work that way, it’s not “running” underneath the arr stack. There is some init stuff that happens when you first start a .net app, setting up DLLs, paths in /opt and such, but there isn’t a resident “layer” involved.
- My arr stack executables never, ever exceed 700MB, 2GB is more than enough. I’ve watched these metrics since the days when radarr and sonarr were backed by mono. You do need some mem space to store temporary show/movie metadata, but it’s trivial.
- As others have said, peak demand ia what you want to know, not base requirement.
Generally, I like where you’re taking this, but I think some more experience with how processes and memory work will help you a lot.
smallserverdata@lemmy.ml 3 days ago
Taking these in order.
Point 3 first, because you are right and I was sloppy. There is no resident .NET layer sitting under the *arr apps. What I actually observed is four apps landing within 5 MB of each other, and the cause is that each process loads its own copy of the same runtime assemblies, not that something shared is running underneath. My wording implied a shared layer that does not exist. I will correct that on the site.
Point 2: the exact binary, flags and health check for each app are on its page on the site, but you are right that none of that was in the post, and the post is what most people read. Short version: every app is the upstream release binary run directly, no distro packages, no containers, so the numbers exclude container overhead.
Point 1: fair, and it undercuts how I framed the sizing rule. On a provider that allows bursting, a floor matters less than I implied.
Point 4 is the useful one for me. 700 MB for a whole *arr stack under real use is a much better number than anything I published, and it comes from someone who has watched it since the mono days. If you have a rough split per app I will put it up as a reported real-world figure alongside my measured idle ones, credited to you.
Point 5: agreed, and it is what I am fixing right now.
phlaym@discuss.tchncs.de 3 days ago
I’m still utterly dumbfounded, why you used Forgejo v/ which is not even supported anymore, instead of the current v15 (LTS) or v16. Where did you find these binaries?
smallserverdata@lemmy.ml 3 days ago
You are right and this is the worst error in the post.
I went and resolved what the current releases actually are, against what I benchmarked:
Two of those cross a major version. Prometheus 2 to 3 in particular is not a number I can assume carries over.
The cause is dumb and worth stating plainly. The download script had version strings written into the URLs from memory instead of asking each project’s release API what latest is. So the whole set froze at roughly one point in time and I never checked. Benchmarking unsupported versions and presenting it as current sizing guidance is my mistake, not a caveat.
Fix is running now. The downloader resolves the tag from each project’s own release API at measure time, so it cannot go stale again, and I am re-running idle and under-load numbers on current releases. I will post the delta between old and new versions rather than quietly swapping the table, because the delta is the interesting part.
Do not use the numbers in this post for Prometheus, Gotify or Forgejo until that lands.