Interesting, mind letting me know the size of your Docker vdisk and how much free space it has? I’ve got the same setup as you, using Unraid and the LSIO container but having issues.
Can manually trigger an ‘Optimize Database’ using WebTools-NG fine, however this fails as my docker vdisk fills up:
My docker vdisk is set to 80GB and utilisation in normal use in 28% (21.1GB)
Running an ‘Optimize Database’ it quickly fills up to 100%
My cache where the db lives is 1TB with 500GB free
My Plex db is bloated to 67GB, so plenty of space
I’ve been meaning to move over to Docker folders instead, so will give that a go, but interested to see how others got this to work.
I would suggest that you use the backup you still have; that’s what I did. Yes, you will lose a month of data but also the headache that you have with a bloated/repaired/waiting for maintenance db and hours after hours of repair attempts when the maintenance finally kicks in.
The only thing I did out of the ordinary was cut/paste the regular in place database backups out to a different disk so it didn’t completely fill up. Multiple 46GB files gobbles space quickly!
I kept my system otherwise healthy, and just waited.
Awesome post…
I only got wind of the issue when my plex box almost ran out of space and was about to crash.. Ran your commands, and although it took a few hours, reduced my db from 150GB to 450MB.
I caught mine growing based on posts here and reverted before it got so far out of hand it would generate errors. Reverted to x.6, then upgraded to x.8 when it became available.
It took several days, but yesterday must have been the day that it performed the cleanup and repair, back down to 200mb
I realized last week my plex db size had ballooned as well from a 400mb to over 62gb. After downloading and running the repair I unfortunately only shrunk a few gb (62.7gb → 58.8gb)
Thankfully I had a larger ssd laying around so swapped out to handle the backups that run but at a loss on what I should try next given this didn’t seem to resolve the issue.
PMS 1.41.8.9834 (current beta) has the fix to reduce db bloat. It occurs when Optimize Database runs as a scheduled task which happens once/week (enable in settings → scheduled tasks).
The process may take several hours to complete.
Plex Media Server will be non-responsive while the optimization occurs (no streaming).
The drive must have at least the size of the bloated db in working space. Move or delete backup db files if needed to free up space.
Good to know! Thankfully I can wait for the release given the bigger drive I was able to swap in (300gb overhead now) but lost a good 12hrs of my life this weekend trying to figure out what happened and fix things when all my dockers went down
Running an ‘optimise database’ via web tools-ng worked for me, took a while though:
13 hours 14 minutes
Database shrunk from 67GB down to 1.2GB
For anyone running Unraid and Plex in a container, running a ‘optimise database’ caused my docker vdisk to fill up to 100% which caused issues. I swapped over to docker folder and it completed fine (something I’d been meaning to do any way).
This thread has saved my sanity. I didn’t understand why I was getting locked out of Plex every few days, when it turns out it was trying to optimize my bloated 150gb db file.
I started a manual db optimization via webtools. It’s been going for about 13hrs. And ideas on how long it’s going to take? It’s running on a Linux box and htop shows the system is active.
My wal file is currently sitting at 33gb where as my db file is currently at 146gb. To be fair, I don’t know what my wal file was at prior to this, but maybe it’s coming back down? I am roughly 19hr or so in… I should add HTOP shows plex still using a significant amount of system resources and my system hasnt locked up… yet.
FYI, for those that don’t want to wait a day for the rows to be deleted simply run these commands (the first simply truncates the statistics_bandwidth table and the second shrinks the database).
DELETE FROM statistics_bandwidth;
VACUUM;
Note, i transferred the file from my server (After stopping plex) then opened in DB Browser for SQLite. My laptop is much more powerful (AI9 HX370), yet almost 9 hours later running the recommended “DELETE FROM statistics_bandwidth WHERE account_id IS NULL;” hasn’t finished yet. this is because SQLite is not made for massive transaction changes, especially deletes, it simply is absurdly slow. My DB was 36GB instead of the usually 320MB.
Note: it still took about an hour to delete those rows using the updated statement and you are purging all of the bandwidth stats, but i couldn’t care less about that. I use Plexpy for stats and it kept everything. Also all the recently played info is there.
Finally - Plex (The company) needs to apologize for this horrendous problem. We pay for this software so they can pay their developers. At the very least the moment they knew about this issue, they should have developed a fix in the next build to address it. This is shameful.
