Overseerr loading times are excrutiatingly slow

[abhineetgupta]

Description

It takes more than a few minutes to load any page on Overseerr. The screen just stays in Loading mode. Even the Settings page which is text only can take multiple minutes to load.

Version

1.33.0

Steps to Reproduce

1. Go to http://OVER.SEE.RR.IP:PORT/requests
2. Wait for page to load
3. Wait some more
4. Refresh hoping page load will be faster
5. Repeat from step 2

Screenshots

Requests page after waiting for 4 minutes

Settings page after waiting for 30 seconds

Logs

No response

Platform

desktop

Device

Macbook Pro

Operating System

MacOS 11.7.7

Browser

Firefox 114.0

Additional Context

Overseerr is running on Synology NAS DS918+ using linuxserver.io docker image.

Code of Conduct

• [X] I agree to follow Overseerr's Code of Conduct

[mdezzi]

I am experiencing the same issue. Extremely long load times on every screen, it started after upgrading to 1.33. I am running hotio docker image.

There doesnt appear to be anything in the logs that hints at why the loading is so slow.

[338lm]

SO SLOW, it's painful. This started immediately after the "upgrade" to 1.33.0

[barkcollar]

Same! My load times have been painfully slow as well.

[Bovive]

I am also experiencing this. 1.33.0 snap version on Ubuntu.

[338lm]

this resolved for me after a couple of days. I think it was an issue with TMDB at the time

[angelgtc87]

mine slow as of now, tried my friend overseer and is smooth :(

[rmatec]

Overseerr has been extremely slow since I started running it on my Synology DS920+ for some reason. At first I thought the resources were not enough but in comparison I can run a full Gitlab instance way faster. My internet is very fast so that is not the issue. Could it be the linuxserver.io is slow? Has anybody tried a different image?

[T0uc0]

Mine is also very slow, the page refreseh very often when I search movies, I take more than 30sec for load the homepage, manage request is slow too... I tried to change DNS, move to host connection, recreate the container, update the container. Nothing work... Anyone have a solution?

[barkcollar]

My performance issues resolved when I moved from a reverse proxy to using a Cloudflare tunnel for remote access.

On Sun, Jul 23, 2023, 3:17 PM T0uc0 @.***> wrote:

Mine is also very slow, the page refreseh very often when I search movies, I take more than 30sec for load the homepage, manage request is slow too... I tried to change DNS, move to host connection, recreate the container, update the container. Nothing work... Anyone have a solution?

— Reply to this email directly, view it on GitHub https://github.com/sct/overseerr/issues/3510#issuecomment-1646961452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUOHPPPZBXD5YXRXVDDVTRLXRWIHDANCNFSM6AAAAAAZLAQTX4 . You are receiving this because you commented.Message ID: @.***>

[chrishuman0923]

Same here! Running on custom homelab build and it is SO slow to do anything.

I am running behind Traefik, so I am gonna take some time to test the solution that @barkcollar implemented (remove from reverse proxy) and see what happens.

Just odd that none of the app logs for any of my containers points to a reason this would be this slow.

[rxbrad]

Loading is extremely slow on a Cloudflare-tunneled Overseerr here, and it has been for months. As everyone notes above, nothing in the logs seems to give a clue as to why. I just spend upwards of 30-60+ seconds staring at pulsing grey squares before it finally starts loading in art. But randomly, about 10% of the time, everything loads in quickly.

~~Loading the server using the non-tunneled local network IP is usually (but not always) faster, so I suspect there's a magic caching setting somewhere, either on Cloudflare or in Overseerr that might help.~~ It's slow whether I load it locally or through Cloudflare. I really don't think this is Cloudflare's fault.

[c11umw]

Same issue here with linuxserver image of overseerr Cleared logs and cache folders, forced container DNS to cloudflared and allowed docker to access all NAS CPUs None of it helped.

Reverted to 1.32.5 and - it's back to loading fast. Definitely something quirky with 1.33+

docker pull linuxserver/overseerr:1.32.5

[zelik888]

Same issue here with linuxserver image of overseerr Cleared logs and cache folders, forced container DNS to cloudflared and allowed docker to access all NAS CPUs None of it helped.

Reverted to 1.32.5 and - it's back to loading fast. Definitely something quirky with 1.33+

docker pull linuxserver/overseerr:1.32.5

Reverting to 1.32.5 did not fix the issue for me. Moving overseerr to SSD drive does fix the issue. Strange that this would require SSD to run smoothly.

[Schu-]

I also seem to be plagued by this bug. The image always has been on an SSD and no changes on my side except updates. I have tested behind a proxy and direct on the system but the bug occurs no matter where it is loaded from.

Still poking around on my own for logs or something to point out what might be going on. But wanted to add to this bug report for information.

Thanks!

[Schu-]

Hello All,

I just wanted to comment on this since I was able to figure out and fix my issue. After a bit more scouring the web, I was able to find a reddit post talking about slowness. https://www.reddit.com/r/Overseerr/comments/sirat6/discover_page_takes_3060_seconds_to_load/. This post talks about adding a DNS command to docker run --dns 1.1.1.1. I made this change on my system and Overseerr worked 100% immediately. This made me question my own DNS issue and did some digging. On my side I found a misconfigured ACL rule to allow my container to reach my DNS server. Once I fixed that all was good on my side.

I would recommend anyone having this issue to review the post about and possibly add that docker run command.

Thanks!

[rxbrad]

I've tried the DNS trick previously, and just gave it another attempt.

Still no help.

This issue is baffling & random, and unfortunately nothing in the logs is of any help.

On Thu, Sep 28, 2023, 5:05 PM Andrew Schumacher @.***> wrote:

Hello All,

I just wanted to comment on this since I was able to figure out and fix my issue. After a bit more scouring the web, I was able to find a reddit post talking about slowness. https://www.reddit.com/r/Overseerr/comments/sirat6/discover_page_takes_3060_seconds_to_load/. This post talks about adding a DNS command to docker run --dns 1.1.1.1. I made this change on my system and Overseerr worked 100% immediately. This made me question my own DNS issue and did some digging. On my side I found a misconfigured ACL rule to allow my container to reach my DNS server. Once I fixed that all was good on my side.

I would recommend anyone having this issue to review the post about and possibly add that docker run command.

Thanks!

— Reply to this email directly, view it on GitHub https://github.com/sct/overseerr/issues/3510#issuecomment-1740001701, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADI5BDPNJJM7TDRSV4LTTH3X4XRARANCNFSM6AAAAAAZLAQTX4 . You are receiving this because you commented.Message ID: @.***>

[mdezzi]

@Schu- thanks for the tip. I am using adguard for local DNS, so that could be a potential slowdown. I added the dns entry in the overseerr container and i'll monitor it to see if it is any faster.

[chrishuman0923]

I just added the extra docker run arg that @Schu- suggested. It immediately fixed my issue!

I am running my network DNS through PiHole. PiHole resolves requests using 1.1.1.1 already so maybe I have something misconfigured but not sure where to start looking. I'm just glad this has resolved it for the time being.

[drn]

FWIW — in my case, it turned out that setting DNS to 1.1.1.1 and 1.0.0.1 in my docker image was the culprit of the slowness. I had accepted that it wasn't "great" for a while — but then pulling up overseerr logs it was logging a number of getaddrinfo EAI_AGAIN errors.

I removed that config, blew away the old overseerr db/cache (kept the settings.json), and recreated the docker image and it's blazing fast now. I could've sworn I tested it without that DNS config, but perhaps that was on my old host (moved from a synology nas to a mac mini — but it was still slow and I gave up for a while).

Here's my current docker config:

  overseerr:
    image: linuxserver/overseerr:latest
    container_name: overseerr
    environment:
      - PUID=501
      - PGID=20
      - TZ=America/Los_Angeles
    volumes:
      - $HOME/docker/overseerr/config:/config
    restart: unless-stopped
    network_mode: bridge
    depends_on:
      - sonarr
      - radarr
    ports:
      - "5055:5055"

Hope this helps someone else! It's been bothering me nuts for months and it seems to be finally fast AF

[zelik888]

Overseerr works great on SSD. I had it on a docker in proxmox CT running on SSD and it was very fast. Moved it to synology docker on regular HDD and it slowed to a crawl. DNS fixes didn't help. Installed SSD cache on my NAS and it's zippy again.

Perhaps nuking the database and starting fresh would fix everything.

[c11umw]

Perhaps nuking the database and starting fresh would fix everything.

I've tried a few things including the forced 1.1.1.1 DNS as well as allowing the container to use all cores (--cpuset-cpus="0-3"), but none of it seemed to help. Tried a fresh data path/db as suggested and, yea .... it is a lot smoother and quicker. So much so that I forgot it's using the latest and not the older pre-slowdown version

Steps to replicate: Stop the container, remove images, create a new folder and copy the settings.json across to it. Amended the data path in the container to the new location and started up. After that force run the jobs to re-sync with plex user, plex library etc

The only gotcha in doing this is that it doesn't keep the request list, so you may need to make a note and then re-request the content and assign to the user that requested. If you forget then it's still available in the old data path to switch back and take note. If you don't then it'll still come, but the user won't get their notification that their request is ready.

But yea, it looks a lot better :)

Docker CLI for reference:

echo Starting overseerr
docker run -d \
--name=overseerr \
--network=proxylan \
-p 5055:5055 \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/London \
-v /volume1/docker/overseerr2:/config \
--restart=unless-stopped \
linuxserver/overseerr:latest

Overseer Image cache: on Nginx Proxy cache assets: off

[rxbrad]

None of the suggestions anywhere in these comments work... If they do, it's always just a coincidence. Randomly, maybe 10% of the time, Overseerr loads great. The rest of the time, it doesn't.

Steps I've taken and can confirm DON'T work...

• Manually setting the Docker container to use Cloudflare DNS
• Manually setting the Docker container to use Google DNS
• Running Overseerr on an SSD
• Totally nuking Overseerr and starting from scratch
• Enabling image cache

The only problems that ever even show up in my browser console logs are random failures to download avatar images from Plex.

GET https://plex.tv/users/xxxxxxx/avatar?c=xxxxxx

[viart]

• Synology ds1621+
• Docker (was) on HDD

Tried quite a bit to solve it, including debugging the app code in the container (+DNS/network) with no obvious issues on the app side...

Decided to add an nvme pool and move docker there, on the way noticed that here I have a checkmark here:

Unchecking it before moving docker folder to the nvme pool solved the issue for me.

I suspect the "data integrity" thing was the root - Overseer is pretty aggressive with file operations (cache) and Synology with counting checksums on it :)

UPD: in theory, a simple ways to check: copy existing data folder to a different location where the "data integrity" is off and mount it.

[timdonovanuk]

There seems to be a dozen posts about this on reddit and clearly a ton of people are having this issues and found their way to this thread. I am also using Cloudflare to access, so it seems to be DNS related. But why? No other web app I'm hosting has this issue.

[rxbrad]

I recently put explicit network information on all of my Docker containers. Since then, my Overseerr has been running consistently zippy.

I wonder if this is a MTU or IPV6 issue? Here's the network info I use for the container, in XML (I use Portainer stacks).

networks:
  default:
    enable_ipv6: true
    driver: bridge
    driver_opts:
      com.docker.network.enable_ipv6: "true"
      com.docker.network.driver.mtu: 1400
    ipam:
      driver: default
      config:
       - subnet: 192.168.140.0/24
         gateway: 192.168.140.1
       - subnet: fd00:0:140::/64
         gateway: fd00:0:140::1

[wiffleman]

Also struggling with this. Tried all of the aforementioned tips with the exception of migrating docker onto a NVME SSD. No errors seen on the logs either.

Just reinforcing the nature of this bug. Also running behind a reverse proxy (Traefik). All other containers are snappy and work well.

[timdonovanuk]

10 to 25 seconds to load most of the elements on the page:

Seems like a lot of elements are simply stalled and sat around waiting for overseerr to process the request:

[T0uc0]

Mine is also very slow, the page refreseh very often when I search movies, I take more than 30sec for load the homepage, manage request is slow too... I tried to change DNS, move to host connection, recreate the container, update the container. Nothing work... Anyone have a solution?

Hello, Recently decided to install docker on a Proxmox VM instead of docker on a Synology DS220+. Now overseerr is really fluid and pleasant to use 😀. Think overseerr on docker on Synology NAS was a bad idea...

[rxbrad]

Lowering the MTU to 1400 on the Docker container has resolved the slowness on my Overseerr install for about 2 months now.

I had the constant slowdowns until I specifically set the MTU. I have had zero slowdowns since.

[timdonovanuk]

I'm not even running in a docker container 😄 The MTU tweak seems to have worked, but it's really random, sometimes I think I've fixed it but the issue comes back. It's certainly not a lack of resources on my server.