Excessive disk activity?

[MaxVonEvil]

Hi all, not sure if this is a bug or something which can be resolved by tweaking the configuration of NJSPC. However I am experiencing non-stop disk activity when NJSPC is running.

I've been running it for a long time on a Pi, but since the SD card crashed last year I moved NJSPC to run as a docker container on my Synology 920+ NAS, using their Container Manager + an EW-11 network RS485 server. Everything works nicely.

However I've noticed my disks in my NAS are churning non-stop when I have the poolcontroller container running. I've verified that I have no logging options enabled as well as I have zero of the advanced features (heaters, chems, lights, rem, etc.) enabled. I basically just use NJSPC for controlling the speed of my IntelliFlo-VS pump and reading the watts, that's really all. I can post copies of my config.json files, but there's not that much interesting in them.

My docker file looks like this:

services:
  poolcontroller:
    container_name: poolcontroller
    restart: always
    user: node:dialout
    ports:
      - "4200:4200"
    volumes:
    - /volume1/docker/njspc/poolcontroller/data:/app/data
    - type: bind
      source: /volume1/docker/njspc/poolcontroller/config.json
      target: /app/config.json
    image: msmi/nodejs-poolcontroller
  poolcontroller-dashpanel:
    restart: always
    container_name: poolcontroller-dashpanel
    ports:
      - "5150:5150"
    volumes:
    - type: bind
      source: /volume1/docker/njspc/poolcontroller-dashpanel/config.json
      target: /app/config.json
    image: msmi/nodejs-poolcontroller-dashpanel
    depends_on:
      - poolcontroller

My thought is that if no logging is enabled, why would it need to have this much if any disk activity, once loaded up, it should just be all comms and ram, right?

Any suggestions are welcome!

[tagyoureit]

I'm not a Docker expert, but here are some things to look for:

1. Any way to drill down in docker/Synology to see what files are being written?
2. We batch log files, so even if you were logging it is only done on a periodic basis.
3. Logs would be the most likely culprit. We don't write to the config.json unless something is changed in the settings. Logs are in the ./logs directory. I don't know if it would help/hurt to map this location. But you can check it manually to see if, in fact, anything is being written there. This is true for both njsPC and dashPanel.

[MaxVonEvil]

So, I learned a ton today:

1. Synology offers a great way of looking into the running container: Container Manager > Containers > containername > Action (menu) > Open terminal. This opens up to the console of the container

Already here it was pretty obvious what was going on 1) the mappings of interior folders/files to external access was somehow borked and effing verbose logging was on as well.

2. You can open a terminal side by side with the console into the container: Hit the Create button, then use /bin/sh or /bin/bash (whatever works) and whoopee we were in.

3. To my dismay I found out I could not edit any files with vi inside the container session. What I had overlooked was that the terminal seemingly runs with the NAS's permissions on the container, i.e. I had to go to Synology's Filestation and set permissions. As I had no idea what user the Synology Container Manager is running as, I just set permissions to read+write for everyone on the docker/njspc tree - So sue me, it works :)

4. Another thing, the container manager apparently grabs all console output and redirects it into a log file which can be viewed through SCM > Container > containername > Log. So even though I only had verbose generating output to console, this translated to disk activity as Synology grabs it for display in it's own log view.

5. Purging the logs wasn't super easy as there's no longer a gui button to knock out the logs. I had about 10k log entries and managed to clear them out completely using a tip found here, essentially SSH into Synology as root, get path for container's logdb and truncate it to size 0:

LOG=$(docker inspect -f '{{.LogPath}}' "<your njspc docker container name>" 2> /dev/null)
truncate -s 0 "$LOG"

Anyway, I'm back on track, the poolcontroller is no longer generating disk activity, rainbows and unicorns all around! :)