Server Version: 4.51.3
Many have already observed this behaviour. The Plex container constantly creates approx 300kb writes to my disks every 1-2s. This wears on the disks and prevent any spindown. Unfortunately all other threads were closed without any resolution. It seems to help to switch to another docker image but there must be a way to get the plex native docker right to avoid that behaviour? Plex surely dont want their SW to be responsible for mutliple HDD/SSD deaths…
Are you using drives appropriately rated for running a server?
Green / Blue drives are not rated . They are archival, short duty cycle drives. They are supposed to be OFF most of the time.
Black drives are desktop computers. They are rated for about 50% system on/off.
NAS / Server drives are rates for 100% duty cycle (power on). More damage is done turning them off & on than leaving them on. (same behavior as a light bulb which burns out when you turn it on and not when left on continuously)
These drives have been on continuously with PMS running. They are WD NAS drives. Not an issue.
This particular drive has been in constant use just over 4 years now.
Good cooling (thermal stability) is important to long drive life).
Drives have a limited count of Head Load/Retract. Leaving them on (heads loaded) is optimal.
Hi ChuckPa, thank you for your response. But my question was not: which is the best drive for running NAS but what the heck is PMS doing by accessing the HDD every 2s. There is no activity with plex at that moment. Other docker plex images do not show that behaviour thus it must be a miconfiguration of the PMS docker image.
And to your point: Regardless if drives are specified for 100% duty cycle or not, they will wear more if more used. Compare it to your car, independant of the mileage warranty your car maker gives you (100k or 50k) your car will wear more if you drive more. And if your car is self-driving the entire day around the block while you are at home this is nothing you want…
Download the DEBUG logs ZIP file and we’ll look at what it’s doing.
No need of guesswork.
I won’t get bogged down in the “keep the drives off until I need them” argument.
If you’re running a server, with an active SQLite3 database, which is always looking for new players or things to do – then expect activity.
Can you minimize it? Yes. DEBUG = OFF, VERBOSE = OFF
Will the drives spin down ? No.
Do you know that QNAP doesn’t even have a “Power Save” option on its drives?
Hypothetical and ludicrous -----If everything powers down when not needed:
If your question were about Power Saving that’s important because electricity prices in some countries is very high. But, HDD death? I’m sorry. Western Digital, Seagate, and all the other makers out there will disagree with you.
Hi ChuckPa,
if Plex would do this intentionally because for the identified HDD it might be advantagious to run premanently then I would not argue. But it shows some strange behaviour and just because it could be not harmful with certain HDDs it is ok that a non-explicable behaviour shows?
Staying withmy car analogy - dont worry that your car is driving around the block, it will keep your brakes from rusting. That would be a great feature if the car would be driving in order to prevent this to happen but its driving, nobody knows why and people say…well if you dont care for the burnt gas it will keeps your brakes free of rust.
Every system (different drives, SSD), every use case is different and every computer is different. This is why it is most desireable to stick with the behaviour which was intended and not argue why an unintended usecase might not be soo bad. That might be true for some but not for all systems.
I would love to continue this philosophical discussion having a beer with you but currently Im just happy that you do want to have a look into my logs finding out the root cause. Some in the internet mentioned it might be related to the docker health check feature which other images do not use. Logs.zip (1.3 MB)
How can I send you a PM to give you the zip PW
Care to regenerate those logs without a password ?
I think i found the root cause. In the PMS docker file the healthcheck does run every 5s.
HEALTHCHECK --interval=5s --timeout=2s --retries=20 CMD /healthcheck.sh || exit 1
And healthcheck.sh performs a curl which writes to the local disk. This is exactly what I’m seeing, only writes every 5s and everytime the same size. Can you check with the team and change the healthcheck.sh to not write to the disk everytime? That would be great.
#!/bin/sh -e
TARGET=localhost
CURL_OPTS="–connect-timeout 15 --max-time 100 --silent --show-error --fail"
curl {CURL_OPTS} “http://{TARGET}:32400/identity” >/dev/null
I will talk with them.
Not familiar if that’s docker or PMS.
In the interim, can you manually disable / modify it?
I have been investigating a little bit more and I might have been wrong. The curl without -o option does not write to disk. I tested that.
Unfortunately I dont have the expertise to disable the healthcheck as my docker environment does not allow it somehow (honestly, i might be just too stupid to do it).
Looking in the processes of the container it still looks as if plex is doing something. There is activity which looks related to the data written regularly.
The log files will always be written to.
You can mitigate that by turning off DEBUG logging and VERBOSE logging.
Both debug logging and verbose is disabled. Would enabling those logs help you in analyzing the issue based on those logs?
No. You’re not happy with the current level of disk activity.
If logging were further enabled, it would be worse.
Granted, I could look at them to see if maybe you have unmatched media which PMS is continuously trying to match but you are probably in a better position to check that by inspection for posters
Another ongoing Plex activity which hits the disk is the network statistics. It performs periodic database writes and roll-ups.
Ok, I have a new update.
It is the Plex container creating the writes, but not Plex itself but Docker and yes it is realted to the healthcheck. Apparently the check itself does not create the io but docker is updating the result of the healthcheck everytime in hostconfig.json and config.v2.json and since Plex is running the healthcheck every 5s it updates every 5s the files. Now that I have figured out where this is originating from I found others having the same issue:
and somebody also filed a bug report for docker: Active HEALTHCHECK causes unnecessary overwriting of hostconfig.json and config.v2.json · Issue #3268 · distribution/distribution · GitHub
But not sure this is necessarily a docker error. Unfortunately my plex container does not like for some reason when I add the command --no-healthcheck to disable the behaviour. It would then not start at all. That might be related to portainer.
So my ask to Plex (@ChuckPa ) could you check with your docker engieers to modify the healthcheck to avoid this behaviour in the future?
I have the same problem, see Constant idle disk usage
Thanks @scyte for all the research. Sadly I can’t try the --no-healthcheck Docker parameter because I’m running Docker on my Synology NAS. At least I think that I can’t - I couldn’t find any place where I could specify that parameter in the Docker app of DSM.
@ChuckPa Could you please check with the Plex team if that healthcheck every 5 seconds is really necessary?
I think that’s a docker health check, isn’t it?
@ChuckPa It’s a Docker feature, yes. But the Plex Dockerfile explicitly uses it with a 5 second interval. See here:
What’s to gain by making it less frequent ?
What could happen by making it less frequent ?
Why the request for change ? (they WILL ask)
I did switch to the Plex Docker Image from Linuxserver. The --no-healthcheck command does not work for the PMC Docker Image. It worked for some other images, some Im still struggling (synchting).
Generally it is a docker bug. For some reason docker updates the hostconfig.json and config.v2.json on every healthcheck instead only updating it only on changed state. Docker needs to fix that asap imho. But there are ways to avoid that behaviour, e.g. linuxserver image does not show it. So there must be a way to do smarter healthchecks in docker
