Adding nice to backup process

[spannerman79]

Related: #531

I suggest adding nice to the backuip process in order to ensure both CPU & I/O doesn't trash the system on lower end hardware.

It will require the container to be started with --privileged --cap-add=sys_nice --cap-add=sys_nice or;

    cap_add:
      - SYS_NICE

added to docker-compose.yml in order to function.

Edit: --privileged not required, see #532 (reply in thread)

If the host has kernel > 2.6.26 ionice doesn't need to be defined as ionice is determined via nice ( man ionice )

I suggest some logic is added so that it isn't configured < 0 - Unless for testing wise DEBUG_MODE=1 is set.

In keeping with other env var's, AUTO_BACKUP_NICE, default to 0, with logic to only allow 1 - 19 to be defined without forcing odin to not continue.

---

The most ideal way to do this of course is that two containers are ran, that way you can define the container that handles odin/hugin is ran with --cpus=x or to pin the CPU's via --cpuset-cpus <value>

There are even better ways to control docker but those are not available to those that have docker on say a QNAP (actual experience)

[mbround18]

Tbh in a true production grade deployment, you would be running backups in a separate container on a little more beefy hardware or use a container running rsync. The backup function is rather simple and I can look into optimizing it a bit <3

[spannerman79]

You know that, I know that, but lets face some facts here.

The majority of discussions created in https://github.com/mbround18/valheim-docker/discussions/categories/help are from users that only know a little to be dangerous and not enough to be able to figure out that (from a quick look through that cat)

• Expect it to run on ARM
• Underpowered Hardware (CPU and/or RAM)
• Their Host OS is broken/borked or so old that a dist update is required

Expecting people like that to setup/use rsync is too much.

Adding some text to a docker-compose.yml or adding a bit more text to a docker run command is easier for them.

[mbround18]

I would say having users add --privileged to a container could be pretty dangerous and wouldnt serve the other market which is those who run this in kubernetes or other more complicated setups. I want to figure out what the root cause of the performance issue on the backup process to see if we can mitigate before having them use a privileged container.

[spannerman79]

--privileged --cap-drop=ALL --cap-add=SYS_NICE

solved.

and wouldnt serve the other market which is those who run this in kubernetes or other more complicated setups

This Idea isn't focused for those, as I already stated.

[spannerman79]

I've updated my OP.

--privileged is not required unless you are trying to set nice to a value lower then 0. And by looking at your logic checks in place nice can only be >=1 and <=19.

As a test i ran with just

    cap_add:
      - SYS_NICE
    environment:
      AUTO_BACKUP_NICE_LEVEL=19

added to docker-compose.yml, chcked htop while the container was running and watched when a backup was being done and sure enough backups were being done with nice of 19.

On my NAS it was faily quick but it will help other users running on Rock Pi's, lower end hardware etc.

[spannerman79]

This has been resolved via #549