#Slow loading initial main page

1 messages · Page 1 of 1 (latest)

waxen fern
#

Since migrating to Seerr from overseerr, every time I load the main page or refresh the page, it takes about 20-30 seconds for anything to load on the page. Seems it is trying to load the data in the background so not sure this is by design or something with the setup. All I did was to copy over the existing overseerr directory in to a seerr directory and then loaded the new docker image in portainer on my Synology instance.

Enabling debug logs simply shows it is making queries to the database but is slow. I have the default mysql database setup and not sure if moving to postgres would help with these type of performance issues.

Has anyone else seen this longer page load time on their migrated instance?

stiff fable
#

Gonna need logs

waxen fern
#

That is a log with debug db logging enabled

#

actually, I can't post the entire log, throws a 500 error

stiff fable
#

try pastebin

#

i dont see much in what you posted.

waxen fern
#

Refresh it

#

Had to create a new one

#

with about 1500 lines

stiff fable
#

i dont see anything alarming

waxen fern
#

pastebin has same limitation

stiff fable
#

do you have cache enabled?

#

2026-02-17T22:50:31.638Z [info][DNS Cache]: Initializing DNS Cache

waxen fern
#

I tried to enable that to see if it would help, it didn't

stiff fable
#

did you previously have dns issues? why is force ipv4 first enabled

waxen fern
#

I didn't have any DNS issues previously, I'll disable that and try again

#

Here is my compose file

#

services:
seerr:
image: ghcr.io/seerr-team/seerr:latest
container_name: Seerr
user: 0:0 #or your PUID and PGID - 0:0 is for root.
healthcheck:
test: ["CMD-SHELL", "nc -z 127.0.0.1 5055 || exit 1"]
interval: 10s
timeout: 5s
retries: 3
start_period: 90s
init: true
ports:
- 5055:5055
environment:
TZ: America/Los_Angeles
#DB_LOG_QUERIES: true #Debug DB queries
volumes:
- /volume1/docker/seerr:/app/config:rw
restart: on-failure:5
network_mode: host
dns:
- 9.9.9.9
- 8.8.8.8
- 1.1.1.1

stiff fable
#

do DB_LOG_QUERIES: true send logs also run curl -w "%{time_total}\n" -o /dev/null -s "https://api.themoviedb.org/3/movie/550?api_key=test"

waxen fern
#

I uncommented DB_LOG_QUERIES before I sent you the log

#

let me see if I can run that curl command on my Synology

#

0.150963

stiff fable
#

is this a spinning drive /volume1/docker/seerr?

waxen fern
#

to me it just seems like slow DB access as if i go to requests and then scroll down, it will show the requests but no image and kind of flashing and then will eventually slow load

#

yes, these are spinning drives

stiff fable
#

gonna be slower on spinning drives but i wouldnt think that slow. so the logs above was with DB_LOG_QUERIES: true

waxen fern
#

it doesn't show those type of Debug queries by default

stiff fable
#

run this curl -w "%{time_total}\n" -o /dev/null -s "https://image.tmdb.org/t/p/w500/pB8BM7pdSp6B6Ih7QZ4DrQ3PmJK.jpg"

waxen fern
#

0.113132

#

ssh in to my synology with putty

stiff fable
#

hmmm can you check the dev console in your browser?

waxen fern
#

if I sudo curl it, I get longer times - 0.238173

stiff fable
#

is this local access or external?

#

thats still plenty fast

waxen fern
#

dev console cap on, standby

stiff fable
#

deff something going on ```media?filter=allavailable — 11.64s
request?filter=all — 11.99s
trending?page=1 — 12.33s
movies?page=1 — 12.80s
tv?page=1 — 13.35s``

waxen fern
#

yeah, funky

#

I tried from a different machine too, same delays. hmmm

stiff fable
#

yeah seems the db is getting hammered and cant keep up "spinning disks"

#

check the db docker exec Seerr sqlite3 /app/config/db.sqlite3 "PRAGMA integrity_check;"

#

also run docker exec Seerr sqlite3 /app/config/db.sqlite3 "VACUUM;"

waxen fern
#

will need to figure out how to run on Synology as ssh won't get to those paths

stiff fable
#

im not familiar with synology... try docker exec Seerr sh -c "sqlite3 /app/config/db.sqlite3 'PRAGMA integrity_check;'"

#

or seerr depedning on how its named

waxen fern
#

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/Seerr/json": dial unix /var/run/docker.sock: connect: permission denied

stiff fable
#

sudo docker exec Seerr sqlite3 /app/config/db.sqlite3 "PRAGMA integrity_check;"

waxen fern
#

OCI runtime exec failed: exec failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown

stiff fable
#

one last try, if not youll have to wait as im not familiar with synology sudo docker exec Seerr sh -c "sqlite3 /app/config/db.sqlite3 'PRAGMA integrity_check;'"

#

im suspecting slow drive/large db

waxen fern
#

not finding sqlite3 in path it seems

#

thanks for the help

stiff fable
#

sorry i couldnt help.. wait for a team member for further troubleshooting

waxen fern
#

would you happen to know what path sqlite3 is in, in the container?

stiff fable
#

try /app/config/db/db.sqlite3

waxen fern
#

what the heck, if I just run it in putty, it returns the help file

#

sqlite3
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

#

oh, that is pulling it up on the NAS, not in the container

stiff fable
#

try sqlite3 /volume1/docker/seerr/db/db.sqlite3 "PRAGMA integrity_check;"

#

after ssh in

waxen fern
#

came back ok

#

I'll try vacuum now

stiff fable
#

stop container first!

waxen fern
#

VACUUM doesn't look like it does anything

stiff fable
#

whats the size ls -lh /volume1/docker/seerr/db/db.sqlite3

#

did you do sqlite3 /volume1/docker/seerr/db/db.sqlite3 "VACUUM;"

waxen fern
#

i ran this and it shrunk for 4mb to 3mb

#

sqlite3 /volume1/docker/seerr/db/db.sqlite3 "PRAGMA temp_store_directory='/volume1/@tmp'; VACUUM;"

#

-rwxrwxrwx+ 1 1000 1000 3.1M Feb 17 16:05 /volume1/docker/seerr/db/db.sqlite3

stiff fable
#

run docker exec -it seerr time nslookup api.themoviedb.org

waxen fern
stiff fable
#

are you using plex local url for your connection under settings<plex?

#

is plex on the same machine?

#

im curious run curl -w "%{time_total}\n" -o /dev/null -s http://PLEX-IP:32400

waxen fern
#

plex is on a remote windows host

#

curl on the plex IP returns 0.002633

#

you know, it reminds me, I think long ago when I implemented overseer I had a similar problem and I had to muck with dns settings somewhere in the Synology config to help

#

trying to remember where that was

stiff fable
#

try removing the dns entries. maybe conflicting with synology dns

#

have you tried direct access ip:port?

waxen fern
#

removed and updated portainer stack, still showing slowness. about 12 sec

stiff fable
#

nuke option here but can you remove plex all together and see if things speed up

stiff fable
waxen fern
#

even going to settings page it takes a bit to load as well

#

weird

stiff fable
#

looking at the dev console it seems its stacking waiting on something and im curious if its plex.

#

remove your plex info restart the container see if its normal speed

#

also your cpu isnt being pinned at 80-100%? plenty of RAM available?

waxen fern
#

you can't wipe out plex settings it seems

stiff fable
#

can you uncheck your libraries.. maybe?

waxen fern
#

clicking just on settings i get this

stiff fable
#

is your system overloaded?

#

whats your ram and cpu look like rn

waxen fern
#

ram 34%

#

cpu 30-40%

stiff fable
#

also noticed your running as 0:0 its recommended to run as 1000:1000

waxen fern
#

let me change that

stiff fable
#

but i dont think thats the issue here..

waxen fern
#

updated

#

great, throwing errors now

stiff fable
#

yeah gonna have to chown the directory for 1000:1000

#

sudo chown -R 1000:1000 /volume1/docker/seerr

waxen fern
#

that worked, thanks

stiff fable
#

still slow?

waxen fern
#

yeah

#

I'll have to play with this a bit more to see what I can find out

muted ember
#

if you have many entries in media and seasons tables (I had ~50k and ~8k) then initial page is loading slowly (10+ seconds for me) because of bad sql in seerr's code. You need to wait for this pull request be released, it will fix the slowness of initial page: https://github.com/seerr-team/seerr/pull/2461

muted ember
#

yes, even for tiny db's

#

I had like 14mb

#

50k entries do not take that much space on disk

stiff fable
#

oh dang, i missed this one. yeah i ran out of ideas.

muted ember
#

easy way to test this is to run this cmdline, it will print out how long time it will take. It should be nothing, but will be 10+ seconds for decent sized db's:

time sqlite3 db.sqlite3 'SELECT COUNT(DISTINCT("Media"."id")) AS "cnt" FROM "media" "Media" LEFT JOIN "season" "Media__seasons" ON "Media__seasons"."mediaId"="Media"."id" WHERE (("Media"."status" IN (5, 4)));'

and while this query will be running the cpu will be maxing out one core to 100%

waxen fern
waxen fern
#

when will the fix be available for testing in a docker image?

warm ermine
waxen fern
#

Wow, massive difference with the develop image, now loads in about a second or two. Thanks!!

#

I don't know what to do with myself it is so fast now.. LOL

waxen fern
#

how do i know when it hits the latest or release image? Would rather be on latest instead of develop release.

ebon vessel
waxen fern
#

Thanks, I will watch for new releases and if the fix is in there.

potent vessel
#

Any idea when there might be a release with this fix?
Need to wait like 15-20 seconds on every visit to the page for it to load through.

ebon vessel
#

Pretty soon

inland helm
#

I've realised I've had this thing, anyone have any idea what it could be afterwards?

warm ermine
inland helm
#

I just changed all my dns servers

#

to my 2 adguard instances

#

then 1.1.1.1 8.8.8.8

warm ermine
inland helm
#

it /etc/resolv.conf

#

I'm running it lxc

#

on proxmox

warm ermine
#

ah i see

#

but i would try first

#

setting just 9.9.9.9 8.8.8.8 1.1.1.1

#

take adguard out of the equation and test

#

if its taking a long time loading the images and stuff then its 100% dns

#

the fix that this thread talks about is already live

#

on 3.1.0

inland helm
#

yey I assumed so

#

I was trying to do it myself without asking stupid questions

#

thought it was ssd/sdd

#

but it's installed on the ssd of my proxmox node

#

then tried dns but maybe it's conflicting

#

also ty for the response even when I've asked it so late I appreciate it

warm ermine
inland helm
#

ah it's 1am for me LMAO

warm ermine
inland helm
#

yeah I will do and let you know, cheers

#

it takes 10 seconds now

#

does that sound about right?

#

or should it be quicker?

#

I know it's on an SSD since the only thing that is on the spinning disk is my OMV baremetal which proxmox points shares to, to store the linux isos

#

should I enable dns caching and I don't have an IPv6 address so should I force IPv4 resolution as well?

warm ermine
#

but try force ipv4

warm ermine
inland helm
#

mine seems to lag behidn when I'm changing searches?

#

like I type alien nothing shows up then it appears

#

I type night at the museum, it first shows alien again before showing night at the museum

#

but yeah still takes like 10 seconds and stuff

#

gets stuck on this for ages

#

I've checked and my dns are all fine

#

oh wait let me stop torrenting lmao

warm ermine
inland helm
#

but I have a seer backend that searches

warm ermine
#

yeah thats not our plugin

inland helm
#

ah okay

warm ermine
#

we dont maintain that

inland helm
#

got you

warm ermine
#

we only support seerr

#

web app

inland helm
#

tyty

#

yeah it connects fine but that's all good

#

okay yeah u right

#

it's instant on the actual app

#

my bad

#

ty for all the help

#

and ty for the very c00l app

#

kinda nuts how you lot make this and it's very appreciated

#

okay for anyone that was a bozo like me and thought it was being slow

#

the fix I found for the jellyfin plugin is to create a TMDB account and register an API