I’m trying to use the --thread-priority=low option in order to decrease Duplicati’s impact on my system while backups are running. I have tried setting it both on the backup jobs themselves, as well as on the shortcut which starts Duplicati at login, but it seems to have no impact on what priority the Duplicati processes run at (they, as well as their threads, all still run at Normal priority).
Interesting, I’m seeing the same thing when I try to modify the shortcut icon. Adding --thread-priority=low doesn’t seem to work. The processes still run at Normal priority:
Unfortunately, what you’re seeing is an artifact of how scheduled tasks work by default on Windows.
If you create a scheduled task normally, it will always run as Below Normal priority. Here, you can see I’ve started Duplicati as a scheduled task, with no arguments, and it’s already running at Below Normal.
If you export said scheduled task, you can open up the XML file in a text editor, change the Priority tag to whatever value you like, re-import it, and the task will now run at that priority level.
While this does give me a neat workaround for starting Duplicati up at a lower priority level, it would still be nice if --thread-priority behaved as advertised.
My guess is that you need elevated privileges to change the thread priorith, which you don’t have when starting Duplicati using a shortcut in the Startup folder.
There are also per-thread priorities viewable using right-click → Properties → Threads in info at bottom.
The thread-priority option looks like it means to adjust the current thread, but I’m not sure that’s enough, however adjusting all the threads in the process might be too much, e.g. to maintain UI responsiveness.
What you possibly want is for the actual backup processing to yield, just taking longer but not timing out.
It looks like SetBackGroundIOPriority code also reduces the CPU priority of the process, which I think
is documented by Microsoft as reducing the I/O priority (somehow – there is a lot that isn’t documented).
On my system, the CPU usually holds out, but the hard drive gets overloaded. Typically, the advice given
is to adjust both the CPU and I/O priority down, however it looks like I/O does both, and I’m not sure CPU done all by itself on the job has the desired effect because I’m not sure it affects all of the needed threads.
Regarding privilege, whoami /priv does show a lot more for an Administrator account, but keeping with good security practice, most are potential, initially disabled, and must be enabled with code to take effect.
sounded like it didn’t apply to this exact case (which is a decrease), but might apply to some other cases.
Here are Priority and IO Priority. First line is “normal”. Second is Duplicati with use-background-io-priority.
then after the backup finishes, Duplicati goes back to normal:
Here’s a Task Manager view during the backup. You can see lots of threads, but there’s no per-thread info:
The Low is the Base priority column which I suspect is the whole process, then threads are within it…
I understand the concept of I/O vs. CPU priority, and in my case, it is, in fact, the CPU utilization which is causing issues on my system. Setting the scheduled task’s priority to 9 seems to have done the job for me, without affecting the responsiveness of the UI, so I’m happy.
I had completely forgotten about manually twiddling scheduled task priorities via exporting and re-importing them, so thanks, @drwtsn32, for reminding me of that.
I’ll switch the solution of this thread to more accurately reflect that we still aren’t certain how --thread-priority works.
