Set process priority at startup #16565

Some users who run a node on their PC (used for gaming, email, adult activities, etc.) would surely like to set the bitcoin-qt priority for their node to "low" on Windows, or "niceness 19" on a Linux machine. On the other hand, a person running a server would potentially want to run the daemon at the highest priority possible. It would be nice to have the option to automate this for us.

Something similar was debated in issue #3618 and I am aware that there's the number of script validation threads setting (might be useful to further explain in the GUI that that's basically CPU core count). However, adjusting the process priority is another thing.

I like ghost's idea of --pri=, although to be honest I'd like --priority= even more - with at least three options (low, normal, high). "Above normal" and "Below normal", like described in Windows, might be a good idea as well.

If my computer restarts, I don't want to manually change the process priority every time it happens, or write a script - I'd like to input my preferences into the config file or click it in the GUI options. I'm sure many other users would like that as well.

I agree that we need process priority. To your second point: All starting arguments can be written in the bitcoin.conf so you can just add pri=19 to your bitcoin.conf file.

Personally, I'm not sure this is within the scope of this project. There are many system-level knobs (if you think of the modern stack as kernel < system < userspace) that we can fiddle with, and it is unfortunate that there aren't many system-level management software out there that allows for easy-fiddling (only systemd tries to do this). However, in this respect I believe that users are much better off writing a wrapper that sets niceness and ioniceness values.

What I think might be useful is writing documentation on how to fiddle with knobs, or even just a document linking to manuals where the fiddling is described.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.