cgroup v2是现代Linux进程资源限制的首选方案，因其统一的层级结构和对CPU、内存、I/O等资源的细粒度控制而优于v1。首先确认系统已挂载cgroup2，通过mount | grep cgroup2验证；随后创建cgroup目录如/sys/fs/cgroup/my_limited_tasks，并启用所需控制器：echo '+cpu +memory' > cgroup.subtree_control。接着设置CPU限制，如echo '50000 100000' > cpu.max表示50% CPU配额；内存限制如echo 512M > memory.max。将进程PID写入cgroup.procs即可应用限制，或使用cgexec -g cpu,memory:my_limited_tasks command启动新进程。对于持久化管理，推荐结合systemd服务单元，配置CPUQuota=50%和MemoryMax=1G等参数，并启用Delegate=yes以允许服务管理自身cgroup。该方法适用于长期运行服务，确保资源隔离与系统稳定。在容器化环境中，cgroup v2为Docker、Kubernetes等提供核心资源隔离与计量支持，提升调度精度与系统可靠性，防止“邻居干扰”，是容器技术稳定高效运行的基础。
在Linux中限制进程资源，尤其是在现代系统上，cgroup v2无疑是目前最推荐和强大的方式。它提供了一个统一的资源管理接口，让你能细粒度地控制CPU、内存、I/O等多种资源，确保系统稳定性和公平性。
要使用cgroup v2进行进程限制，你需要遵循几个核心步骤。我个人觉得，理解其统一的层级结构是关键，它不像v1那样有多个独立的控制器层级，这让管理起来更直观，但也需要一点时间去适应。
首先，确认你的系统是否启用了cgroup v2。大多数现代Linux发行版默认都已启用。你可以通过运行
mount | grep cgroup2来检查。如果看到
/sys/fs/cgroup类型为
cgroup2的挂载点，那就没错了。
接下来，创建一个新的cgroup目录，这本质上就是你为一组进程定义的资源限制域。 例如，为我们的“受限任务”创建一个组：
sudo mkdir /sys/fs/cgroup/my_limited_tasks
进入这个新创建的cgroup目录，你会发现一些默认的文件。最重要的是
cgroup.subtree_control和
cgroup.procs。
cgroup.subtree_control用于启用这个组下子cgroup可以使用的控制器，而
cgroup.procs则是用来将进程PID添加到这个组中。
你需要激活你想要使用的控制器。假设我们想限制CPU和内存：
sudo sh -c "echo '+cpu +memory' > /sys/fs/cgroup/my_limited_tasks/cgroup.subtree_control"
这一步告诉cgroup系统，
my_limited_tasks这个组可以管理其子进程的CPU和内存资源。
现在，我们可以设置具体的资源限制了。 例如，限制CPU使用率为50%（假设一个周期是100000微秒，那么配额就是50000微秒）：
sudo sh -c "echo '50000 100000' > /sys/fs/cgroup/my_limited_tasks/cpu.max"
这里
50000是配额（quota），
100000是周期（period）。这意味着在每个100毫秒的周期内，这个cgroup中的进程最多可以使用50毫秒的CPU时间。
限制内存使用，比如限制为512MB：
sudo sh -c "echo 512M > /sys/fs/cgroup/my_limited_tasks/memory.max"
你还可以设置一个“软限制”
memory.high，当内存使用超过这个值时，系统会尝试回收内存，但不会立即杀死进程。这对于防止OOM（Out Of Memory）错误，同时允许一定程度的突发使用很有用。
最后一步是将目标进程的PID（进程ID）添加到
cgroup.procs文件中。 假设你有一个名为
my_heavy_process的程序，其PID是
12345：
sudo sh -c "echo 12345 > /sys/fs/cgroup/my_limited_tasks/cgroup.procs"
或者，如果你想直接在这个cgroup中启动一个新进程，你可以这样做：
sudo cgexec -g cpu,memory:my_limited_tasks /path/to/your/command
cgexec工具（通常由
cgroup-tools包提供）能帮你更方便地管理进程。
我发现，对于长期运行的服务，尤其是那些需要开机自启动的服务，直接操作
/sys/fs/cgroup目录虽然可行，但更推荐的方法是利用
systemd的单元文件来管理cgroup。
systemd提供了非常方便的
CPUQuota、
MemoryMax等选项，它会自动帮你处理cgroup的创建和进程的归属，这无疑是更优雅和持久的解决方案。
在我看来，cgroup v2之所以成为现代Linux资源管理的首选，主要在于它解决了v1中一些根深蒂固的设计问题，并带来了一套更统一、更易于理解的API。v1的多个独立层级，比如CPU、内存、I/O各有自己的层级，这在管理上经常让人感到混乱，尤其是在处理复杂的资源分配策略时。我记得有几次，我尝试在v1中配置一些相互关联的限制，结果总是因为层级结构的不一致而碰壁。
v2则通过引入一个单一的、统一的层级结构，彻底改变了这种局面。所有控制器（CPU、内存、I/O、PIDs等）都挂载在同一个根目录下，这极大地简化了管理逻辑。这种设计不仅减少了潜在的冲突和歧义，还使得资源分配的策略更加清晰和可预测。你不再需要担心某个控制器层级与另一个控制器层级之间的交互问题，一切都在一个统一的视图下进行。
此外，v2在内部实现上也进行了优化，提供了更精确的资源计量和更公平的资源分配机制。例如，它更好地处理了内存过载（memory overcommit）的情况，并对一些边缘情况（如fork炸弹）提供了更健壮的保护。对于开发者和系统管理员来说，这意味着更少的惊喜和更稳定的系统行为。从我个人的经验来看，虽然从v1迁移到v2需要一些学习成本，但长远来看，这种投入是值得的，因为它最终提供了一个更强大、更可靠的资源管理平台。
为特定应用程序设置CPU和内存上限，这在多租户环境或资源敏感型服务中至关重要。我通常会结合
systemd来实现，因为这能让配置持久化且易于管理。
假设你有一个名为
my_custom_app.service的应用程序，你可以创建一个
systemdunit 文件来定义其资源限制。
首先，创建一个服务文件，比如
/etc/systemd/system/my_custom_app.service：
[Unit] Description=My Custom Limited Application After=network.target [Service] ExecStart=/usr/local/bin/my_app_executable --config /etc/my_app/config.conf Restart=on-failure # 启用cgroup v2资源限制的关键 Delegate=yes # CPU 限制 # 限制为单个CPU核心的50% CPUQuota=50% # 或者更细粒度的控制，例如每100ms周期内，最多使用50ms的CPU时间 # CPUQuotaPeriodSec=100ms # CPUQuotaUsageSec=50ms # 内存限制 # 硬限制为1GB MemoryMax=1G # 软限制为800MB，当达到此值时，系统会尝试回收内存 MemoryHigh=800M # 当内存使用量超过MemoryMax时，系统会尝试杀死该cgroup中的进程。 # MemorySwapMax=0 # 禁止交换，强制内存限制 [Install] WantedBy=multi-user.target
这里
CPUQuota=50%直接对应了cgroup v2的
cpu.max文件，
systemd会自动将其转换为
50000 100000这样的格式。
MemoryMax=1G则对应
memory.max。
Delegate=yes这一行非常重要，它告诉
systemd这个服务应该拥有管理其自身cgroup子树的权限，这在容器或复杂服务中尤其有用。
配置完成后，你需要重新加载
systemd配置并启动服务：
sudo systemctl daemon-reload sudo systemctl enable my_custom_app.service sudo systemctl start my_custom_app.service
你可以通过
systemctl status my_custom_app.service来查看服务的状态，并通过检查
/sys/fs/cgroup/system.slice/my_custom_app.service目录下的文件来验证cgroup限制是否正确应用。
在实际操作中，我发现设置这些限制是一个反复试验的过程。一开始，你可能需要保守一些，然后根据应用程序的实际性能和资源使用情况逐步调整。设置过低的限制可能导致应用程序性能下降甚至崩溃，而过高的限制则达不到资源隔离的目的。因此，监控工具（如
htop,
top,
cgroup_top或更专业的Prometheus/Grafana）在这里扮演着至关重要的角色。
cgroup v2在容器化环境中扮演着核心的、不可或缺的角色，它是Docker、Kubernetes、Podman等容器运行时和编排系统实现资源隔离和管理的基础。可以说，没有cgroup，就没有我们今天所知的容器技术。
对我来说，cgroup v2在容器世界里的优势体现在几个方面：
首先，更强大的资源隔离能力。容器的核心理念就是将应用程序及其依赖打包，并在一个隔离的环境中运行。这种隔离不仅仅是文件系统和网络层面的，更重要的是资源层面的。cgroup v2提供了底层的机制，让容器运行时能够精确地为每个容器分配CPU时间、内存、I/O带宽，甚至限制其可以创建的进程数量（通过
pids控制器）。这意味着一个“行为不端”或资源消耗过大的容器不会轻易地影响到同一宿主机上的其他容器或宿主系统本身的稳定性。这就像给每个容器划定了清晰的边界，避免了资源争抢导致的“邻居干扰”问题。
其次，更准确的资源计量和调度。在Kubernetes这样的编排系统中，用户可以为Pod定义
requests和
limits，比如
cpu.requests和
memory.limits。这些配置最终都会被翻译成cgroup v2的参数。cgroup v2的统一层级和改进的计量方式，使得容器编排器能够更准确地了解每个容器的实际资源需求和使用情况，从而做出更智能的调度决策，将Pod放置到最合适的节点上，优化整个集群的资源利用率。
再者，简化了容器运行时的实现。相较于cgroup v1，v2的统一层级结构和更清晰的API，使得像
containerd或
runc这样的容器运行时在与内核交互时，可以采用更简洁、更一致的逻辑来管理容器的资源。这减少了实现复杂性，降低了出错的可能性，也为新特性的引入提供了更坚实的基础。
我个人认为，cgroup v2是容器技术“幕后英雄”的典范。大多数容器用户可能永远不会直接与cgroup文件系统交互，但他们每天都在享受cgroup v2带来的稳定性和性能。当容器出现资源瓶颈，比如某个Pod因为内存超限而被OOMKill时，深入理解cgroup v2的工作原理，就能帮助我们更快地定位问题，并优化资源配置。它让容器化环境不仅仅是“能跑起来”，更是“能稳定、高效地跑起来”。
服务热线
limited_tasks/memory.max"