Read this post: Library.db size more than doubled in latest version - #253 by FordGuy61
The process only runs once every 7 days.
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.
1 Like
I did the same thing. By far the easiest solution.
Confirming that my weekly scheduled task has successfully shrunk my database back to normal size. From 46.2GB to 365MB.
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.
Cheers everyone!
1 Like
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.
Thanks for confirmation.
Notice the -wal file is 47.3 GB.
The -wal and -shm files are present only when Plex is running.
If you stop PMS, the both should go away, freeing up 47.3 GB.
When you restart PMS both will be re-created, and the -wal file will be at its normal, smaller size.
Awesome - cheers for that. Things are looking positively svelte now. My disk has gone from 75% full to 25%.
Really appreciate your help!
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
1 Like
Hi all,
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.
Any ideas of what I should try?
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.
You can use WebTools-NG Butler Scheduled Tasks to start the scheduled task immediately.
WebTools-NG runs on PC/Mac/Linux (download). It does not have to run on the same system as Plex Media Server.
1 Like
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 
Is there a target release date scheduled yet?
Not that I’ve seen (Plex rarely provides such details).
You can subscribe to the PMS release notes to be notified of new releases. Scroll to bottom of the thread and change Normal to Watching.
You could always load the beta, clean up the db, then return to the public release.
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).
1 Like
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.
Thoughts?
Can take a while, see my post above, took 13 hours 14 minutes.
To monitor progress, I checked the size of the wal file,, it increases until its roughly the size of the bloated database file.
1 Like
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.
If Plex is responsive, you should see Optimizing Database under the activity icon in Plex Web (Plex may be too busy to respond).
The -wal file will increase to the size of the bloated db file.
The db file will reduce to a normal size.
Initially, there will be little disk activity from the process. Once the -wal file starts growing, you should see an increase in disk activity.
When complete, Plex should be responsive, the db file will be normal sized, and the -wal file will be bloated.
Stop Plex and the -wal file will be removed (It is normal for the -wal and -shm files to go away when Plex is stopped and the database closed).
Start Plex and the -wal file will be re-created at its normal size.
1 Like
Thanks. Yeah, plex isnt being responsive right now. I’ll see where things are at tomorrow.
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.
1 Like
