#Extreme slowness on Synology

48 messages · Page 1 of 1 (latest)

vast egret
#

I have Overseerr running on my Synology 920+ and it is extremely slow. It takes 45+ seconds for the homepage to load completely. I'm unable to do anything until it loads completely. It also frequently times out when trying to request media.

Here is my docker-compose config. This was taken from the TRaSH guides. https://hastebin.com/tulajuwayu.yaml

glossy pagoda
#

I also had that problem (for most apps being sluggish, not just Overseerr, but Overseerr was particularly poor) with or without image caching enabled - my solution was to add a couple of M2 SSDs as a Read/Write Cache and it made such a difference. It's pretty zippy now 🙂

vast egret
#

I haven't added SSDs yet, but I don't see this issue in any other docker container I have running.

vast egret
#

I'm seeing the same thing using the official image as well. sctx/overseerr:latest

vagrant merlin
#

Seeing the same issue here. Also on the DS920+

woeful swan
#

also seeing the same issue RS818+ in Docker using linuxserver/overseerr:latest

sand island
#

i also added m.2 ssds but as a volume, works amazingly, loads instantly

strong snow
#

Ahaha, I just migrated my lsio overseerr container from my ds1817+ to my nuc because of this issue. Not sure why it's happening in the syno.

devout estuary
#

I'm getting this too on my DS920+ with docker. Unbearably slow UI. Posters take ages to load. Radarr and Sonarr are snapy as ever.

devout estuary
#

The new version has revealed that the "Recently Added" and "Recent Requests" sliders are causing slow loading times on the home page. Disabling these sliders will significantly improve loading speed. Additionally, there is an issue with the global queue for slider image loading, which prevents simultaneous loading and slows down the process further. It is unclear why this method was chosen instead of using asynchronous loading.
The loading of images for the next slider is being delayed until the completion of the previous slider's loading process.

sand island
#

Has anyone not running on SSDs tried the smaller stripe cache size? I/O bottlenecks caused most of my issues, this might alleviate it.

devout estuary
#

Modify the stripe cache size
If you are using RAID 5, 6, F1, or SHR with more than three drives, adjust the stripe cache size following the instructions below based on your DSM version.

DSM 7.0: Go to Storage Manager > Storage, select a storage pool, and click 1.png. Click Settings and select Smaller stripe cache size under Stripe Cache Size.1

#

I don't seem to have that option

vast egret
#

I'm assuming you mean these sections?

devout estuary
vast egret
#

It's faster, but still slower than when I had it running on an old mac mini.

#

And slightly annoying that I have to disable a feature to get it to be sort of acceptable

#

Also is this per user? So I need to tell every user to go remove these?

devout estuary
#

No said you need to remove it. This was merely to pinpoint the problem.

#

#tech-chat message

#

This is what I'm seeing ^

sand island
devout estuary
#

I'm also on SHR (not SHR-2)

zinc cape
#

exactly the same problem, with Synology DS920+, SHR, Google DNS, but since I've buy a SSD it's little more fast

devout estuary
#

What differentiate overseerr from the other arrs that it needs an ssd? Sonarr and radarr load instantly with more than 1000 items.

sand island
#

@devout estuary check your logs, I had hundreds of DB request failures in radarr/sonar because with SHR iops are extremely slow. There is no caching only 100% commit to avoid losing data. It is not just overseer. I'm running something like 15 containers so if one app is active the iops for all others are tanked. SSD solved all this.

devout estuary
#

Thanks for the suggestion. I didn't identify any errors in the logs of sonarr or radarr.

glossy pagoda
#

I can only echo what Potato in a jar said and mirrored what I saw. With high io waits.
Overseer seemed to be affected more than most, but I did see sluggish behavior on other apps (lidarr was also quite badly affected)

devout estuary
#

Can you paste here the exact error you were seeing?

vast egret
sand island
glossy pagoda
devout estuary
#

I don't use a ssd

dry grail
#

I have ssds in syno and still loads very very slowly... Any ideas?

dry grail
#

Generally - how to set up overseer for best performance?

vast egret
#

This is still a huge issue. Is there any fix for this?

zinc cape
#

Since I've buy 2 SSD in my DS920+ no more problem

vast egret
#

Are you just using them as a read/write cache or what?

zinc cape
#

yes read/write cache

vapid merlin
#

I have used one for volume (where i stock all my docker folder & plex) and the secondary for read Only. IT works perfectly ! I'm with an DS920+

tranquil otter
cobalt osprey
#

I can confirm that it was so slow on a DS1819+ that I had to move it to my Windows Box in a docker container there. I am not sure why it runs so slow in Synology, but I have noticed that the performance of my docker apps on Synology have generally been worse the last few months.

vast egret
#

This is still a huge issue. Is there any plans to address what's happening here? None of my other Docker containers on my Synology are this slow.

kind helm
#

I don't know if it may be related but Synology NAS using DSM use a very specific version of docker which may have some issue with the way Overseer works? Maybe it's worth a try to install a recent docker version to run overserr?

golden salmon
#

Just echoing that I too experience the issue today and have been for quite some time. All other arrs work just fine. Overseer is the only one that is terribly slow.