|This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)|
ionice refers to linux kernel code that added priorities to the disk IO scheduler - much like nice does for CPU scheduling. ...though a bunch more coarse.
The ionice command works similar to the nice command: start something via it:
ionice -c3 ls
...or renice by giving it a PID:
sudo ionice -c3 -p `pidof sshd`
It looks like you need root permissions to:
- raise anything to realtime class
- change class on another process (use of -p), even if you're lowering your own processes to idle
Concepts and parameters
There are two main concepts to ioniceness (or rather, the cfq scheduler):
- scheduling class: the basic attitude to how a process will or won't dominate over other classes
- realtime (1)
- realtime means "process will be given access pretty much regardless of what else is going on". If a process is IO-heavy, you probably rarely want this, as it makes it very easy to cause cause IO starvation for everything else
- among realtime processes, priority determines timeslice length (how?)
- best-effort (2), the default class(verify)
- round-robin, priority determines amount of data handled in a single turn(verify)
- priority is based on from the process's cpu (startup?) niceness: io_nice = (cpu_nice + 20) / 5
- idle (3)
- only gets any disk time when nothing else is asking for it (see note/warning below)
- priority is not used at all (or is it, in recent versions?(verify))
- realtime (1)
- priority: controls how to order things in the same clss.
- seems to usually amount to a fractional "I get a little more/less than you" thing
The parameters for ionice:
- -n: priority within a class, values 0 (higher priority) through 7 (lower priority)
- -c is the scheduling class
- -c 1 for realtime
- -c 2 for best-effort (default)
- -c 3 for idle
- -c 0 seems to be none, and the default on a process(verify)
Idle class seems very conservative - it sees whether a disk stays idle for a short while before it considers letting in an idle process.
- Implies that on busy disks, an idle-class program may go minutes or longer without having a single IO command satisfied
- Also seems to imply that having enough idle-class processes may (relatively) starve each other (verify), rather than fill all your otherwise idle IO time
A filesystem's background operations (e.g. delayed metadata writes) may still hog the disk, and they don't fall under a user process's ioniceness. This seems to apply mostly to some of the more complex and clever journaling filesystems.(verify)
To inspect ioniceness, use ionice -p somepid without setting anything (-c or -n), for example:
ionice -p `which nfsd`
This will produce lines like:
none: prio 0 none: prio 0 best-effort: prio 4 idle
This is generally in the form of
...except that idle doesn't do priorities.
Is the default equivalent to -c2 -n4?(verify)
It's pretty granular. You rarely want realtime, and idle may starve when best-effort programs are pretty busy. In some situations, you want mostly best-effort processes, tweaking the priorities a bit.
IOnice only affects contention between processes on the same host (and is pretty granular)
- When you serve network clients, things become more complex, because you share io between local processes and a local service that serves files remotely. Details like whether it hosts from a single process or many can have significant influence on actual sharing(verify). In some cases traffic shaping may also be interesting.