Strangely enough … my logs were getting hammered with this same error. I also was running Overseer (everything is running in docker). So I stopped the Overseer container, and the number of errors for the slow query went from hundreds down to a few, when “browsing” my library (2800 movies) or large collections.
Recommend you temporarily stop the overseer container and see what happens on your end.
Hello.
I know there are probably several different issues (as in sources of the slowness) coexisting in this thread, as @Atomatth pointed out; but I found something quite interesting and I have not seen mention of this here.
TL;DR
Apparently sqlite does not work properly on nfs mounts. I changed the plex config mount I was using from nfs to iSCSI and not only my issue (slow query) went away, but general responsiveness and library scan speeds increased dramatically.
The Long(er) description
At the same time I detected the SLOW QUERY issue in plex I saw my sonar and radar services showing lots of messages of database is locked, I eventually found several answers on the matter. Even sqlite faq says having a sqlite db hosted on a nfs share is bad
The GitHub thread linked above has a few comments mentioning that iSCSI shares do not have that problem (I did not know they existed, I thought they were some stuff similar to scsi).
I updated sonar and radar’s configurations to use an iSCSI mount, they worked much faster and without any db lock messages.
Proceeded to do the same with plex and voila, no more slow queries.
I hope this helps.
It can be made reliable, but it requires the stars to align perfectly. It is brittle and can fail in many ways. It’s definitely not recommended without an unreasonable amount of faith in the NFS client, server, and network. When made to be reliable, it is likely to be slower than expected.
There’s a “don’t do this, but if you must, here are some tips” recommendation here in the forums.
CIFS/SMB is also a poor choice.
I’d strongly recommend keeping the Plex databases on local disks, even if the remainder of the Plex data directory is moved to a network location.
I agree that iSCSI is typically a better choice than direct NFS mounts for this purpose.
(Note that this only applies to direct NFS mounts. Another common scenario, virtual machine disk images located on NFS, works reliably.)
If I may?
If over the LAN, you better be using mGig (2.5Gb/s or higher == 250 MB/sec). Standard 1GbE won’t cut it for big databases (100 MB/sec). Knowing your ‘schtuff’ about networking is important here to get the NFS mounts perfect else it will corrupt on you.
iSCSI does carry the benefits of supporting the local file system local locks but is still limited by the transport (wire) speed. The tradeoff is the target is a fixed size block device. Increasing size means creating new.
That all having been said, suprisingly,
UUID= method to guarantee it always mounts up to the same place at OS startup even if other drives plugged in,Result:
If i can add some words to this topic, i made this post where i describe slow playback while scanning for new files. I was really annoyed so i tried to not installing PMS on bare metal but rather on Docker via docker-compose. It gave me same result with really little library (for the test i chose only one music artist with like 15 albums). It was as slow as my normal big library with over 100 artists and still adding.
Today, i’m going to create VM inside my working machine and try it there with different OS’s and PMS versions. Wish me luck…
(If you were lazy to jump into my post, here is some info about my setup: NVMe SSD 256 gigs, media stored on encrypted google drive and accessing via rclone mount. This setup (like, with rclone and stuff) worked flawlessly on RPI back then. Then i switched to much more powerful machine with Intel Core I5 8500T in it and i’m consistantly having very similar issue (described in my post) with PMS.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
