Server Version#: 1.43.0.10389
Every Thursday a little after 5am (when scheduled tasks are set to run) my server becomes unresponsive and I have to restart the plex container. I have a script that watched for the plex container to become unhealthy for 5 minutes before restarting the container.
I suspect it’s due to the weekly database optimization or one of the other weekly tasks. I have run the PlexDBRepair tool multiple times on my database over the past few months but it hasn’t had any effect on this behavior.
I don’t have any logs to attach this time as I had verbose logging on up until now but I will attach debug logs next time.
Are there any other proactive steps I can take?
Does Plex Media Server crash or is it still running but non-responsive?
What is the size of the Plex database files? Are they abnormally large - 10s or 100s of GB?
Possible “DB Bloat” Problem:
If the db files are abnormally large, then you may be experiencing the “db bloat” bug that afflicted some releases of PMS 1.41.7. Plex Media Server could be trying to clean up the database files. The process runs once per week during scheduled tasks, may take hours, and Plex will be running, but non-responsive until it finishes.
You can speed up the process by running DBRepair and choosing the DEFLATE then AUTO options. Update to the current version of DBRepair first..
DBRepair can clean things up faster than PMS because PMS is stopped and the database is closed.
If db bloat is not the problem, a set of debug logs that capture the problem will be needed.
Before you start disabling scheduled tasks…
- Make sure Plex is configured for debug level logs.
- Disable the auto-restart script.
- After the problem occurs, restart Plex Media Server.
- Wait 2 - 3 minutes for PMS to fully boot and log the startup sequence.
- Pull the log files (settings → troubleshooting) and post the entire zip file to the thread.
Disabling the auto-restart script lets you control when Plex restarts. It also ensures the log files will not rotate too many times, possibly losing desired information.
Does Plex Media Server crash or is it still running but non-responsive?
It crashes as there is a crash report being sent at that time.
What is the size of the Plex database files? Are they abnormally large - 10s or 100s of GB?
See screenshot below.
If the db files are abnormally large, then you may be experiencing the “db bloat” bug that afflicted some releases of PMS 1.41.7. Plex Media Server could be trying to clean up the database files. The process runs once per week during scheduled tasks, may take hours, and Plex will be running, but non-responsive until it finishes.
You can speed up the process by running DBRepair and choosing the DEFLATE then AUTO options. Update to the current version of DBRepair first..
DBRepair can clean things up faster than PMS because PMS is stopped and the database is closed.
I’ve run the latest version of the DBRepair multiple times over the past month. I’m pretty confident I’ve run deflate at least once but I can try it again.
If db bloat is not the problem, a set of debug logs that capture the problem will be needed.
Before you start disabling scheduled tasks…
-
Make sure Plex is configured for debug level logs.
-
Disable the auto-restart script.
-
After the problem occurs, restart Plex Media Server.
-
Wait 2 - 3 minutes for PMS to fully boot and log the startup sequence.
-
Pull the log files (settings → troubleshooting) and post the entire zip file to the thread.
Disabling the auto-restart script lets you control when Plex restarts. It also ensures the log files will not rotate too many times, possibly losing desired information.
I’ve configured debug level logs and I will disable take care of the rest for next week in preparation of this happening again.
Thanks for the update.
Deflate + Auto will rule out any structural problems with the database. DBRepair does not look at content, so there could still be a db issue.
I’ve never heard of removing old bundles or cache files causing problems (the other weekly tasks listed in settings → scheduled tasks).
If you want, you can use WebTools-NG to kick off the database optimization, instead of waiting for a week to pass. You can start other tasks as well.
It talks to Plex via API calls. You can run it from a PC, Mac, or Linux system. It does not have to run on the server itself.
You’ll use the Butler Scheduled Tasks portion of the tool (In the Plex log files, scheduled tasks are referred to as Butler tasks.).
Wiki: Butler Scheduled Tasks · WebTools-NG/WebTools-NG Wiki · GitHub
Download: Release 1.2.1 · WebTools-NG/WebTools-NG · GitHub
Am I not able to just click Optimize Database in Troubleshooting?
There are differences between the weekly task and the button in troubleshooting.
- Optimize Weekly Task: Tries to deflate if necessary, then optimizes.
- Optimize in Troubleshooting: Optimize only. Does not deflate.
I do not know if there are other differences. I remember it came up when 1.41.7 was causing db bloat issues.
Since the problem seems to be with the weekly test, probably best to use WebTools-NG to kick off that version.
Ok without making any changes, I simply ran the Optimize Database task from the WebTools-NG tool. It completed in about 2-3 minutes with no issue. So…not sure where I go from here.
Thanks for the update.
Now wait. If Plex crashes again, pull and post the log files.
Crashed again at the same time this morning. Unfortunately I forgot to change the time window for the scheduled tasks and it was at 5am so I couldn’t reboot my server and download the logs as requested. I do have the unfiltered log from the time the scheduled tasks begin until it crashes though. It’s not sanitized though. Can I provide this like in a PM?
Sure. Click on my username then the Message button.
