-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set nice/ionice levels for commands run by backrest #281
Comments
I think this sounds like a great idea -- this is something I had intended to do pretty early on and simply fell off my plate. Adding the capability should be fairly straightforward. My leaning is the same of yours re: exposing a simple toggle to deprioritize backup operation IO. I wonder whether it even makes much sense to worry about nice on the CPU side of things. Perhaps an enum?
wdyt? Are there options I'm missing? |
I use a lot of old desktop machines and I hope that using nice would help those systems stay as responsive as possible during backup operations. But to be honest, someone would have to run tests and actually measure stuff to be able to draw some more objective conclusions.
Can't really help you there. My programming skills are almost zero. When looking at the manpage of ionice I didn't really understand what the difference between the class "none" and "best-effort" is. It didn't make a lot of sense to me that a process would be assigned the class "none" per default. What's the impact then if it gets re-classed as "best-effort"? Will it get more or less I/O time? Apart from that, "best-effort" and "realtime" support priority levels and the default priority level is 4 (highest=0, lowest=7). Maybe it would be a good idea to lower our priority level to 5. But then again: does it really matter? |
Adding my $0.02 since I'm also interested in this functionality: I think a single enum could work, but might be a bit limiting. Maybe have a Edit to add:
From my understanding, Edit 2: #!/bin/sh
ionice -c2 nice -n19 "$@"
exit $? |
Implemented a pair of enums in #309 , it should also be a pretty easy extension to support a wrapper script in general (and I can see that this solves some generic problems! e.g. mount / unmount a volume before / after commands perhaps?). This is something that can perhaps be done in a followup. |
Is your feature request related to a problem? Please describe.
Longer backup operations can noticeably impact system performance, especially on desktop systems.
Once
restic check
will be supported, something likerestic check --read-data
can also hog system resources for quite a while.Describe the solution you'd like
The rough idea is inspired by the restic documentation.
One example they use there is
$ ionice -c2 nice -n19 ./restic -r /media/gour/backup/ backup /home
.I have not completely thought this through, so this is just an idea that can probably be improved.
In the spirit of keeping things simple, I was thinking about implementing a switch somewhere (plan, repository) which would work as "run with normal process priority" or "run in background", where background would mean
ionice -c2 nice -n19
.I'm unsure whether running in background would be a good idea under all circumstances because if the machine is currently running other tasks (e.g. encoding a video), could the backrest task essentially take a lot longer and then block other backup operations? How would this new feature need to be implemented to not cause additional problems?
Would it be better to have
ionice
andnice
be configurable by the user?The text was updated successfully, but these errors were encountered: