niceStart a command with a lower (or higher) CPU priority
nice starts a command with a different niceness, from -20 (greedy) to 19 (polite). A higher nice value means a smaller share of CPU when processes compete, so backups, compression and reports don't slow down the service users are waiting on. Only root can go below 0.
nice [-n ADJUSTMENT] COMMAND [ARG]... nice (prints the current niceness)You need to compress last month's logs on a production web server without slowing down requests.
nicecoreutils nice: changes its own niceness with setpriority(), then execs the command.
Every Linux thread has a nice value from -20 to 19, default 0, inherited across fork and exec. nice calls setpriority() (or nice()) on itself and then execs your command, which keeps the new value. The scheduler (CFS, and EEVDF since kernel 6.6) turns nice into a weight: nice 0 is 1024, each step is about 1.25x, so nice 10 is 110 and nice 19 is 15. When two CPU-bound tasks share a core, each gets CPU in proportion to its weight: nice 0 vs nice 10 splits about 90/10. If the CPU is idle, a niced task still runs at full speed: nice only matters under contention. Raising niceness is always allowed; lowering it below the current value needs CAP_SYS_NICE (root) or an RLIMIT_NICE allowance. Note that with autogroup or cgroups, nice only competes within the same group.
(no args)Print the current niceness of the shell-n NAdd N to the current niceness (range is clamped to -20..19)(no -n)nice COMMAND adds 10 by default-n -NNegative values raise priority; needs rootionice -c3Companion tool: idle I/O class for disk-heavy jobsionice -c2 -n7Best-effort I/O class, lowest priority levelNI / PR (top)Where to see it: NI is nice, PR is 20 + NI for normal tasksnice -10 backup.sh, thinking it means 'niceness minus 10'In the old single-dash syntax, -10 means an adjustment of +10. --10 would mean -10. Very confusing.
Always use -n: nice -n 10 backup.sh (or -n -10 as root)Using nice to cap a job at 10% CPUNice only sets the share under contention. On an idle box a nice 19 job still uses 100% of a core.
systemd-run --scope -p CPUQuota=10% backup.sh, or a cgroupExpecting nice to stop a backup from slowing the database's disknice changes CPU scheduling only. Disk I/O contention is untouched.
Add ionice -c3 (with BFQ) or an IOWeight/IOReadBandwidthMax cgroup limitIgnoring 'nice: cannot set niceness: Permission denied' in a cron logThe command still ran, at normal priority, so the job you meant to boost or lower wasn't.
Use positive values as a normal user, or set Nice= in the systemd unitTry these on a Linux machine of your own. Each task has a hint and a solution.
Print your shell's current niceness, then run `nice` through nice with +5 to see the inherited value.
Start `sleep 600` in the background at niceness 19 and confirm it in ps.
Try to start a command at niceness -5 as a normal user. Does it run?
niceStart a command with a lower (or higher) CPU priority
nice starts a command with a different niceness, from -20 (greedy) to 19 (polite). A higher nice value means a smaller share of CPU when processes compete, so backups, compression and reports don't slow down the service users are waiting on. Only root can go below 0.
nice [-n ADJUSTMENT] COMMAND [ARG]... nice (prints the current niceness)You need to compress last month's logs on a production web server without slowing down requests.
nicecoreutils nice: changes its own niceness with setpriority(), then execs the command.
Every Linux thread has a nice value from -20 to 19, default 0, inherited across fork and exec. nice calls setpriority() (or nice()) on itself and then execs your command, which keeps the new value. The scheduler (CFS, and EEVDF since kernel 6.6) turns nice into a weight: nice 0 is 1024, each step is about 1.25x, so nice 10 is 110 and nice 19 is 15. When two CPU-bound tasks share a core, each gets CPU in proportion to its weight: nice 0 vs nice 10 splits about 90/10. If the CPU is idle, a niced task still runs at full speed: nice only matters under contention. Raising niceness is always allowed; lowering it below the current value needs CAP_SYS_NICE (root) or an RLIMIT_NICE allowance. Note that with autogroup or cgroups, nice only competes within the same group.
(no args)Print the current niceness of the shell-n NAdd N to the current niceness (range is clamped to -20..19)(no -n)nice COMMAND adds 10 by default-n -NNegative values raise priority; needs rootionice -c3Companion tool: idle I/O class for disk-heavy jobsionice -c2 -n7Best-effort I/O class, lowest priority levelNI / PR (top)Where to see it: NI is nice, PR is 20 + NI for normal tasksnice -10 backup.sh, thinking it means 'niceness minus 10'In the old single-dash syntax, -10 means an adjustment of +10. --10 would mean -10. Very confusing.
Always use -n: nice -n 10 backup.sh (or -n -10 as root)Using nice to cap a job at 10% CPUNice only sets the share under contention. On an idle box a nice 19 job still uses 100% of a core.
systemd-run --scope -p CPUQuota=10% backup.sh, or a cgroupExpecting nice to stop a backup from slowing the database's disknice changes CPU scheduling only. Disk I/O contention is untouched.
Add ionice -c3 (with BFQ) or an IOWeight/IOReadBandwidthMax cgroup limitIgnoring 'nice: cannot set niceness: Permission denied' in a cron logThe command still ran, at normal priority, so the job you meant to boost or lower wasn't.
Use positive values as a normal user, or set Nice= in the systemd unitTry these on a Linux machine of your own. Each task has a hint and a solution.
Print your shell's current niceness, then run `nice` through nice with +5 to see the inherited value.
Start `sleep 600` in the background at niceness 19 and confirm it in ps.
Try to start a command at niceness -5 as a normal user. Does it run?