Continued Disk Activity

[braunsch]

Hello - I am running Serviio on Docker using the @soerentsch/serviio docker container on a Synology NAS.

While it works wonderfully, it keeps accessing something on my disks all the time - so that the NAS will never go into hibernation mode, even if Serviio is completely idle.

I’m not sure if this is due to Serviio, or due to some other component included in the Docker container. Is it possible to fix this?

[soerentsch]

Hello @braunsch , perhaps the metadata indexer from Serviio is the issue. Please check your Settings under :23423/console/#/app/metadata Depending from your config the Indexer searching for new Metadata or creating missing Thumbnails.

[braunsch]

Thank you for getting back to me. Unfortunately it did not help: Even after unchecking everything on the metadata screen (and restarting the container) it still won’t go to sleep.

Do you have a Java VM installed inside of that container? (I’m asking - because I have heard that those might have a life of their own, doing all kinds of unexpected things and reading and writing disks - and I’m not sure how to stop them…)

Georg

Georg von Braunschweig

On Jun 12, 2022, at 12:25, Sören @.***> wrote:

 Hello @braunsch , perhaps the metadata indexer from Serviio is the issue. Please check your Settings under :23423/console/#/app/metadata Depending from your config the Indexer searching for new Metadata or creating missing Thumbnails.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[soerentsch]

Hi Georg, yes, of course is there a JVM in the container. Serviio is a Java Application. Til my Docker-Image v2.2.1-update7 i used the same JVM Version (OpenJRE 8) as the original Branch from riftbit/docker-serviio. With the Docker-Image v2.2.1-update8 i upgraded to OpenJRE 17. The current latest Docker-Image is v2.2.1-update11.

hub.docker.com/r/soerentsch/serviio/tags

If you want, you can test the Docker-Image v2.2.1-update7, this Docker-Image include the older OpenJRE 8 JVM.

Kind regards from Hamburg Soeren

[braunsch]

Hello Soeren - More investigations (a Synology ‘hibernation debug log’) shows significant activity coming from the docker container with Serviio:

Every 30 seconds, I see plenty of write activity on my disks - from the Docker daemon (dockerd process). I am not sure if this can be changed by the use of parameters - but with write activity every 30 seconds, of course the server never goes to sleep. The moment I stop the container my log becomes boring and quiet.

Just a few lines of my log:

(I still haven’t found a way how to map the block number to a file name - my NAS runs with BTRFS file system…)

[1089851.473295] ppid:1(systemd), pid:10393(dockerd), WRITE block 2405241568 on dm-2 (32 sectors) [1089851.473343] ppid:1(systemd), pid:10393(dockerd), WRITE block 2405241536 on dm-2 (32 sectors) [1089851.475420] ppid:1(systemd), pid:10393(dockerd), WRITE block 128 on dm-2 (8 sectors) [1089851.476676] ppid:1(systemd), pid:10393(dockerd), WRITE block 5191676952 on dm-2 (16 sectors) [1089851.478006] ppid:1(systemd), pid:10393(dockerd), WRITE block 2403421376 on dm-2 (64 sectors) [1089851.478049] ppid:1(systemd), pid:10393(dockerd), WRITE block 2405518528 on dm-2 (64 sectors) [1089851.478102] ppid:1(systemd), pid:10393(dockerd), WRITE block 2403421440 on dm-2 (128 sectors) [1089851.478172] ppid:1(systemd), pid:10393(dockerd), WRITE block 2405518592 on dm-2 (128 sectors) [1089851.478234] ppid:1(systemd), pid:10393(dockerd), WRITE block 2403421568 on dm-2 (128 sectors)

Grüße aus San Francisco! Georg

[soerentsch]

Hi Georg, our man in San Fransisco ;-), can you share your volume mapping settings? And have already tested to disable the "Library" settings "Search for updates of currently shared files" and/or "Keep library automatically updated" ?

Regards from the Waterkant Sören

[braunsch]

Hello Sören!

It took me a while - but I managed to wrestle Synology into looking at the problem. It turns out that there is a Docker setting in the container that causes all the “WRITE” entries - it’s called “health check”.

Here is what they wrote:

“Our developers took another look, and determined that the container(s) both contain a setting called healthcheck, which requires it to report it's status back to a config.v2.json file every 5 seconds.”

I have heard that the standard for Docker is not 5 seconds, but 30 seconds - which matches the frequency of ‘WRITE’ entries in my log.

Based on their recommendation, I re-created the Serviio container with the command sudo docker run -it --no-healthcheck --log-driver none --network host --name Serviio soerentsch/serviio:latest

(I added the “log-driver none” parameter because that was something I heard earlier would matter, but I am not sure it does).

The result was that after adding “no-healthcheck” all WRITE activity disappeared from my logs - and after a while, the device went correctly into hibernation.

Do you think it is possible to add the “no-healthcheck” as a default setting to the next version of your container?

Freezing in San Francisco. Georg

[soerentsch]

Hi Georg, thanks for sharing of your findings.

Unfortunately is the "--no-healthcheck" parameter a Container parameter and not an Image parameter. But of course i can remove the healthcheck from the Dockerfile. Currently i wait for the next FFmpeg Version during this week and then i will build the next image versions at the weekend.

Anyway, i wondering why the Healthcheck is triggered every 5s (seconds). At the Dockerfile the Healthcheck interval is every 5m (minutes).

Sweating in Hamburg, Sören

[lu-p-us]

I want to share some information for future readers:

Even without the healthcheck, I struggled with frequent disk activity every 20-30 sec. No chance for hibernation!

To find out what was going on, I compared the Serviio container to a qBittorrent and JDownloader container. With only qBittorrent OR JDownloader activated, my DS720+ managed to hibernate after 10 min and even power off after another 10 min. With both active, hibernation was possible, but it never "survived" the additional 10 min for power off without new disk activity. This was after tuning the (few) settings provided by qBittorrent and JDownloader for less frequent disk activity.

I managed to clear the situation by "moving" the /volume1/docker dir to a ramdisk (tmpfs file system mounted at the very same location shadowing the original HDD based docker dir). Almost all disk activity from the qBittorrent and JDownloader containers happened inside this dir, because I mapped the persistent config dirs etc. from inside to containers to this location. Frequent disk activity gone. Silence. Only the OS itself doing some stuff from time to time.

But after activating Serviio (persistent config dirs also mapped to /volume1/docker): Again frequent disk activity every 20-30 sec. WFT!?! Turns out that Serviio's Java is started with the default(!) option -XX:+UsePerfData. This writes some performance monitoring info to the file /volume1/@docker/btrfs/subvolumes/<id_of_container>/tmp/hsperfdata_root/1 about every 30 sec. One could either change the container (image?) to deactivate this option with -XX:-UsePerfData or map /tmp inside the container to a dir outside the container which is covered by the ramdisk, too. This is what I did. Silence again.

Update with Serviio version 2.4:

enable passing JAVA_OPTS env variable to the Linux start script

Setting it like so

made the hsperfdata_root directory disappear. Great.

BUT ... now regular writes to /docker/serviio/library/db/log/log<some_digits>.dat prevent hibernation. This a log file of the DerbyDB used by Serviio. Since I didn't find a way to disable this one too, I had to stay with the ramdisk/tmpfs solution described above.