qBitTorrent is being killed multiple times a minute because it's OOM. The default 512MB is too low when seeding and downloading many torrents. Please raise the default and/or make this configurable. For now I have manually edited the /opt/sparkbox/modules/media/docker-compose.yml file to give it more RAM, but I suspect this will be overridden on the next update.
7 replies
tomspark wrote:
You've nailed it — 512MB is too low for a busy qBittorrent that's seeding and downloading at once, and yes, your hand-edit to the compose file gets overwritten on the next update (that's expected, not you doing anything wrong). I'm bumping the default and making it an actual setting so you don't have to touch files. Until that ships, your edit holds until your next update — if it resets, just re-apply it. Thanks for the clear write-up, that's a real one.
tomspark wrote:
Done — shipped in 1.6.314. Run sparkbox update and qBittorrent now gets 2GB by default instead of 512MB, so the OOM-kills should stop. And you can set your own ceiling without hand-editing the compose file: add QBITMEMLIMIT=4G (or whatever you want) to /opt/sparkbox/.env and it sticks across updates. Thanks again for the clear report — that's exactly what made it a quick fix.
cbj11200 wrote:
We should be allowed to also edit the max memory for prowlarr, radarr, lidarr, bazarr, sonarr, flaresolverr, and seerr. I noticed they are all capped at 256MB. While i don't get OOM errors or kills on them, i can watch the usage and they constantly get to 80% or more suddenly dropping and rising again. I'd like to imcrease mine to at least 512MB, as I have the available memory to do so. It would give me peace of mind that they can at least run what they need without being bottlenecked. I know i can change in the compose, but it resets every update. What a pain. On that same note, when i run docker stats, I can see the CPU usage on the dashboard is usually reporting very low. I see 10-30% usage at any given point there, and on the dashboard i'm seeing 2%.
tomspark wrote:
Good call — and noted. Right now only qBittorrent got the configurable memory knob (QBITMEMLIMIT, new in 1.6.314); the arr apps and helpers are still on fixed 256MB caps. Since you're watching them creep toward the ceiling, extending that same override to Prowlarr/Sonarr/Radarr/Lidarr/Bazarr/Seerr/FlareSolverr makes sense — I've logged it as a feature so they get the same QBITMEMLIMIT-style knob. Can't promise a timeline (that's Tom's call), but it's a clean follow-on to what already shipped. Thanks for keeping an eye on the usage.
RyuikuX wrote:
Any status update on the configurable memory knobs for the rest of the arr apps and helpers? im getting Flaresolverr OOM kills and want a more permanent way to bump its memory. id also like to find a way to beef up jellyfin, ive noticed long load times in that too.
tomspark wrote:
Honest status: dashboard sliders for per-app memory aren't built yet, but there IS a supported way today that survives every update — a small override file. For FlareSolverr, create /opt/sparkbox/state/overrides/media.yml with: services: flaresolverr: deploy: resources: limits: memory: 1G And for Jellyfin, /opt/sparkbox/state/overrides/jellyfin.yml raising its memory the same way (it defaults to 1G — try 2G for a big library). Then sudo sparkbox up applies it, and updates never wipe it. Your OOM report is also feeding into raising the shipped defaults — the current caps are too tight on busy boxes, and we're fixing that at the source.
Chris wrote:
That landed today. Tom raised the shipped defaults in v1.6.463, and this thread is one of the two reports named in it. FlareSolverr now gets 1G instead of 512M. The old cap was OOM-killing the headless browser mid-challenge — exactly the failure you described — and it quietly broke your tagged indexers until something restarted it. Jellyfin went from 1G to 2G in the same release. So the override file is no longer needed for either of those; the defaults now match what it was setting by hand. Run sudo sparkbox upgrade to pick them up. Per-app memory sliders in the dashboard still are not built, so that part of the answer stands.