Understanding Nice Values

Nice values are the user-space mechanism for influencing the Linux CPU scheduler. A high nice value means "I am being nice — let others have CPU first." The name comes from the social concept: a nice person steps back and lets others go first. Understanding what nice values actually do — and their limitations — helps you make appropriate decisions about when to use them and when a harder limit (cgroups) is more appropriate.

The nice value scale

Nice value scale:
  -20 ────────────── 0 ────────────── +19
   ↑                  ↑                 ↑
Most aggressive    Default         Most yielding
 (root only)      (everyone)        (everyone)

Example: server with 2 CPU-intensive processes:
  Process A: nice 0  (normal)
  Process B: nice 10 (yields)

  When both are runnable: A gets roughly 10× more CPU time than B
  (Exact ratio depends on kernel version and CFS weights)

Nice vs priority in top and ps

Tools display both the nice value and the calculated scheduling priority. The relationship: priority = 20 + nice for normal processes.

# In ps, use -o to see both:
ps -eo pid,ni,pri,stat,comm --sort=ni | head -10

ps output with nice (NI) and priority (PRI)

  PID  NI PRI STAT COMMAND
 1234 -10   9 Ss   sshd           ← NI=-10, PRI=9, high priority
 5678   0  19 Ss   nginx          ← NI=0, PRI=20, normal
12345  10  29 SN   rsync          ← NI=10, PRI=30, below normal
67890  19  39 S N  gzip           ← NI=19, PRI=39, lowest
# In top: NI and PR columns
# Look for processes with negative NI (high priority) or high NI (low priority)

Real-world impact of nice

# Demonstrate nice impact: run two CPU-intensive tasks
# Without nice (compete equally):
sha256sum /dev/urandom &    # Background CPU-intensive task
sha256sum /dev/urandom &    # Another equally important task
# Both get 50% CPU each

# With nice (background job yields):
nice -n 19 sha256sum /dev/urandom &    # Batch job
sha256sum /dev/urandom &                # Interactive job
# Interactive job gets ~90%+ CPU when runnable, batch job gets remainder

📝 NOTE: Nice values only matter when the CPU is busy. If the CPU is idle, a nice +19 process gets 100% CPU just like any other process — there is nothing to yield to. Nice helps when you have multiple processes competing for limited CPU time.

ionice: I/O priority

The ionice command sets I/O scheduling priority, analogous to nice for CPU. Use it with nice for background jobs that do both CPU and disk work.

# I/O scheduling classes:
# 1 = real-time (bypasses others, can starve system)
# 2 = best-effort (default, like normal priority — level 0-7)
# 3 = idle (only gets I/O when no other process wants it — best for backups)

# Run rsync with idle I/O priority and low CPU priority
ionice -c 3 nice -n 19 rsync -av /home/ /backup/home/

# Set I/O priority of a running process
sudo ionice -c 3 -p PID

# Check current I/O priority
ionice -p PID

cgroup CPU limits as an alternative

Nice values are hints to the scheduler but do not provide hard limits. A nice -n 19 process can still consume 100% CPU if it is the only runnable process. For hard enforcement, use cgroups.

# Limit a process to 25% CPU using cgroups (systemd-run)
# Run a backup with a 25% CPU limit
systemd-run --scope -p CPUQuota=25% nice -n 19 rsync -av /home/ /backup/

# Or apply to an existing process via systemd
sudo systemctl set-property --runtime user-1001.slice CPUQuota=50%

# View current cgroup CPU limits
systemd-cgls
cat /sys/fs/cgroup/system.slice/cpu.max

Conclusion

Nice values control CPU scheduler preference but do not enforce hard limits. Use nice -n 19 to start background jobs that should only use CPU when nothing else needs it. Combine with ionice -c 3 for I/O-heavy background work. For hard CPU limits that prevent a process from ever taking more than a specified percentage, use systemd’s CPUQuota= property or cgroups directly. Check nice values in ps -o ni or the NI column in top/htop.

FAQ

Is Understanding Nice Values important for Ubuntu administrators?+

Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.

Should I practice this on a live server?+

Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.

What should I do after reading this article?+

Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.

Need help with Ubuntu administration?

Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.

Hire Me for Support