Sonarr version (exact version): 4.0.15.2940 Mono version (if Sonarr is not running on Windows): 6.0.13 OS: Ubuntu Debug logs: Description of issue: Sonarr has a continious low level disk writing, even when it doesn’t show anything occuring on UI or in normal logs.
This has be something a lot of people have talked about in the past, but there has never really been a good answer.
my text logs aren’t growing all the time, though the timestamps on my sonar db files seem to be always current time, which would indicate that they are talking the small write load.
Is there a reason the DBs are constantly being written to, I’d assume sonarr would be mostly idle (especially in a DB context), unless its getting RSS feeds on a schedule or doing its scans on a schedule.
I can imagine its doing more active work in terms of keeping track of the downloaders, but I guess I’m unsure why it would have to continually write to the DB about that info (perhaps noting that a download has finished?)
This is on spinning media for me, but I can imagine the 100-200K/s load I see (via iotop), is talking somewhere in the 8-16GB a day of “wasted” writes that can’t be particularly healthy for the lifetime of an SSD (3TB a year of writes if averaging 100K/s, even if one drops the average down to 50K/s that 1.5TB a year), but even on spinning media low continous low level writes such as this can harm peformance, due to the iops they consume.
Sonarr decides if it needs to run a background task every 30 seconds, with a minimum interval of 1 minute (tracking downloads), so effectively it’s doing something approximately every 90 seconds, which includes writes to the database.
I checked my system and I was seeing 1-2 minutes between writes to the DB at that time.
Spinning rust has a knock on effect for writes though, there tend to be more retries due to slower disk access, if writes need to be retried then there will be more overall attempts to write data, even if it’s unsuccessful.
There are also logs (trace/debug writing more often), logs database (info and higher). Logs include access through the API (used by the UI and other apps), so if you have things hitting Sonarr often (I’ve seen Huntarr and Ombi hit things excessively previously) you’re going to see a lot more reads and writes.
so I’m not using anything that hits sonarr (the only other thing I have setup is trackarr, but I think thats sonarr hitting it, not vice versa).
In regards to tracking downloads, why does it need to track downloads every 60-90s if all the downloads are complete? i can see the value in tracking downloads if they aren’t complete, but if all the downloads are complete, it seems like a waste, especially if all tracking efforts result in db updates.
with all that said, it could just be sample bias, looked at iotop now, and sonarr isn’t doing anything (i.e. in the past when I’ve looked, its when I was wondering what was impacting IO and perhaps sonarr was doing enough IO to throw things out of wack, especially if it was constantly syncing as a DB might do)
Sound like Trackarr (if it’s the same one, hits Sonarr), which could result in a lot of requests if the tracker is busy.
Trackarr monitors tracker announce IRC channel, parses the announcements, and forwards those announcements to ARR PVRs (eg Sonarr/Radarr)
Things can get added outside of Sonarr and also things hit seeding limits, get paused and then get removed by Sonarr.
Overall it’s very little overhead, get the tasks, figure out which ones need to be executed, execute and update DB that they were executed. If we were checking far more aggressively we’d look to optimize further.
Glad to hear that it’s not a continuous problem though.