In this lesson, you will learn how to use systemd "slices" to organize your services into resource-constrained buckets, ensuring that one category of applications cannot starve others of CPU or memory.
The Concept of Slices
Think of your server’s resources—CPU, RAM, and Disk I/O—as a giant pool of water. By default, every service on your system tries to drink from that pool simultaneously. If a memory-intensive data process goes rogue, it could potentially consume all available RAM, causing your web server or SSH daemon to crash.
"Slices" act as containers or sub-pools. They are hierarchical units that group services together. When you place a group of services into a specific slice, you can set "ceilings" (limits) on that slice. This forces all services inside that slice to share a restricted portion of the total system resources, preventing them from impacting the rest of the OS.
Implementing a Custom Slice
To create a partition, you define a .slice unit file. For example, if you want to group your background analytics services to ensure they never consume more than 25% of the CPU, you would create /etc/systemd/system/analytics.slice:
[Unit]
Description=Limited Slice for Analytics
Before=slices.target
[Slice]
CPUQuota=25%
MemoryMax=2G
Once this file exists, you simply tell your service units to join this slice by adding Slice=analytics.slice to the [Service] section of their configuration files.
When you restart these services, systemd uses Linux control groups (cgroups) to enforce these limits dynamically. You don't have to manage the underlying cgroup tree yourself; systemd handles the hierarchy and the enforcement automatically. If the analytics services try to exceed 25% CPU, the kernel will throttle them back, keeping the rest of your system responsive. This is a clean, modular way to keep production workloads stable without needing complex external tools.
Key Takeaway: Slices allow you to group services into hierarchical containers where you can apply resource limits to the entire group, protecting the system from runaway process consumption.