服务器资源被占满，最常见的情况就是某个应用失控，吃光了CPU、内存或磁盘I/O，导致其他服务瘫痪。要解决这个问题，最直接有效的方法就是使用Linux内核的Cgroup（控制组）技术。它不是什么新概念，但绝对是现代服务器资源隔离和限制的基石。简单来说，Cgroup能给你一把精准的手术刀，把系统资源（如CPU时间片、内存用量、磁盘读写带宽、网络流量等）划分成一个个“格子”，然后把不同的进程放进不同的格子里，规定它最多能用多少。这样，即使某个应用发了疯，它的破坏范围也被死死地限制在自己的格子里，不会波及整台服务器。
一、 Cgroup的核心思想：从“共享大锅饭”到“配额责任制”
在没有Cgroup的传统模式下，所有进程在资源面前基本是平等的，大家在一个池子里抢。一个内存泄漏的进程会榨干所有物理内存和交换空间，引发OOM（内存溢出）杀手无差别终结进程。一个陷入死循环的脚本会占满一个甚至多个CPU核心，导致系统响应迟缓。Cgroup彻底改变了这个局面，它引入了“层级化”和“子系统”的概念。你可以创建一棵树状的层级结构，每个节点就是一个Cgroup。每个Cgroup可以绑定一个或多个“子系统”（如cpu、memory、blkio），并为该子系统设定具体的资源限制参数。所有被放入这个Cgroup的进程及其子进程，都必须遵守这些规则。这就实现了从粗放的共享模式到精细的配额责任制的转变。
二、 动手实践：使用systemd管理Cgroup限制应用资源
现代Linux发行版（如CentOS 7/8, Ubuntu 16.04及以后）普遍采用systemd作为初始化系统，而systemd深度集成了Cgroup。通过systemd服务单元（service unit）来配置资源限制是最直接、最易于管理的方式。你不需要直接操作/sys/fs/cgroup下的虚拟文件，而是通过修改服务配置文件即可。
假设我们有一个名为“my-app.service”的Java应用经常内存溢出，我们需要限制它的CPU和内存使用。
1. 限制CPU使用
编辑服务单元文件：sudo systemctl edit my-app.service。这会打开一个覆盖片段文件，在其中添加以下内容：
[Service] CPUQuota=50% CPUAccounting=true
这里，CPUQuota=50% 表示这个服务最多只能使用单个CPU核心50%的时间片。如果你的服务器是4核，这并不意味着它能用满2个核心，而是指它在任何一个CPU核心上的使用率上限是50%。对于多核限制，更精细的控制可以使用AllowedCPUs=0-1（允许使用CPU0和CPU1）配合CPUQuota实现。
2. 限制内存使用
在同一编辑片段中继续添加内存限制：
MemoryMax=512M MemorySwapMax=1G MemoryAccounting=true
MemoryMax=512M 是硬性限制，应用进程使用的物理内存（RSS+Cache等）超过512MB，就会被内核OOM Killer强制终止。MemorySwapMax=1G 则限制了物理内存+交换空间的总使用量。设置交换空间限制非常重要，可以防止进程在物理内存不足时，通过疯狂换入换出磁盘拖垮整个系统的I/O。
3. 限制磁盘I/O
如果应用有大量磁盘读写，可以限制其I/O带宽，防止它阻塞其他关键服务（如数据库）。
IOAccounting=true IOWeight=default # 更精确的限制示例（限制对主要数据磁盘sda的读写） # BlockIOReadBandwidth=/dev/sda 10M # BlockIOWriteBandwidth=/dev/sda 5M
配置完成后，执行 sudo systemctl daemon-reload 重新加载配置，然后重启服务：sudo systemctl restart my-app.service。你可以使用 systemd-cgtop 命令实时监控各个Cgroup的资源消耗情况。
三、 深入内核：直接操作Cgroup v2接口进行更精细控制
虽然systemd很方便，但有时你需要更底层、更灵活的控制，或者你的环境使用的是更新的Cgroup v2架构（Ubuntu 21.04+， Fedora 31+默认启用）。Cgroup v2将所有控制器（子系统）统一挂载在/sys/fs/cgroup一个单一根目录下，设计更简洁一致。
例如，我们要为一批批处理脚本创建一个独立的控制组，限制其CPU和内存：
#!/bin/bash
# 创建Cgroup v2层级
CGROUP_NAME="batch-jobs"
CGROUP_PATH="/sys/fs/cgroup/${CGROUP_NAME}"
sudo mkdir -p ${CGROUP_PATH}
# 限制CPU使用时间为一个核心的20%（Cgroup v2使用cpu.max文件）
echo "20000 100000" | sudo tee ${CGROUP_PATH}/cpu.max
# 格式为"$MAX $PERIOD"，表示每$PERIOD微秒周期内，最多使用$MAX微秒的CPU时间。这里表示占用单核20%。
# 限制最大内存为256MB，超过则触发OOM
echo "256M" | sudo tee ${CGROUP_PATH}/memory.max
# 将当前Shell进程及其未来创建的所有子进程加入这个Cgroup
echo $$ | sudo tee ${CGROUP_PATH}/cgroup.procs
# 现在，在这个Shell中运行的所有命令都将受到上述限制
# ./my-heavy-script.sh通过直接操作这些接口，你可以实现动态的资源调整，比如在业务高峰时放宽限制，低谷时收紧。这对于实现自动化资源调度至关重要。
四、 关键策略与最佳实践：超越简单的“限流”
仅仅设置上限是防御性的。一个成熟的资源管控策略应该是多层次、智能化的。
1. 区分保障与限制
Cgroup不仅能设置上限（limit），还能设置保障（guarantee）。例如，通过cpu.weight属性（在Cgroup v2中）或CPUShares（在Cgroup v1/systemd中），你可以为不同的服务分配权重。当CPU资源竞争时，权重高的服务会获得更多的时间片。这确保了核心服务（如数据库）总能获得必要的资源，而非核心任务（如日志分析）则在空闲时运行。
2. 内存控制的艺术
除了硬限制MemoryMax，还应关注MemoryHigh。这是一个“软限制”。当进程内存使用超过此阈值，内核会开始积极回收该Cgroup内的页面缓存，并尝试压缩内存，使内存使用回落到阈值以下，而不是立即触发OOM。这给了应用一个自我调整的机会，能有效减少因瞬间峰值导致的非必要进程终止。
3. 联合文件系统（OverlayFS）与容器场景
当今主流的容器技术（如Docker， Kubernetes）正是Cgroup、Namespace和OverlayFS等技术的集大成者。在Kubernetes中，你可以通过Resource Requests和Limits为Pod定义资源请求和上限，Kubelet最终会将这些配置翻译成对应容器的Cgroup规则。深刻理解Cgroup，是优化K8s集群资源调度、防止“吵闹的邻居”效应、提升集群稳定性的前提。
五、 监控与告警：让资源限制体系形成闭环
设置了限制不等于高枕无忧。你需要建立监控，了解限制是否合理，以及是否有进程频繁触达限制红线。
监控点包括：
1. Cgroup资源使用率：通过systemd-cgtop、cat /sys/fs/cgroup/<path>/memory.current 或Prometheus的"node_exporter"（它收集cgroup指标）来持续监控。
2. 进程被OOM Kill的记录：查看内核日志journalctl -k | grep -i oom 或/var/log/messages，分析哪些应用因超限被终止。
3. 系统整体资源压力：使用vmstat， iostat监控整体CPU等待、内存换页、磁盘队列情况，判断资源限制是否过严导致系统资源闲置，或者过松导致底层竞争依然存在。
当监控到某个Cgroup持续触达其资源上限时，告警系统应通知管理员。这可能是应用存在性能缺陷需要优化，也可能是业务量增长需要调整配额。这样，Cgroup就从单纯的“隔离墙”，演变成了一个动态资源管理和容量规划的反馈系统核心。
总而言之，面对服务器资源被单一应用占满的难题，Cgroup提供了操作系统级别的、稳定可靠的解决方案。从通过systemd进行快速部署，到深入内核接口实现精细控制，再到结合权重、软硬限制形成策略，最后通过监控告警形成管理闭环，这套组合拳能从根本上提升服务器的多应用承载能力和整体稳定性。在微服务和容器化普及的今天，这不仅是运维人员的必备技能，更是开发人员设计可预测、高性能应用的基础知识。
