如何限制Linux进程资源 cgroups基础配置与管理-linux运维-PHP中文网

cgroups是linux系统中限制进程资源的核心机制。1. 它通过控制器（如cpu、memory、blkio）管理特定资源；2. 组织成层级结构，子组继承父组限制并可细化配置；3. 进程被添加到cgroup后受资源限制，防止资源耗尽；4. 可直接操作/sys/fs/cgroup文件或使用systemd进行更高级管理；5. 推荐通过systemd服务单元文件配置cpu和内存限制，例如使用cpuquota和memorylimit参数；6. 监控方法包括读取cgroup统计文件、使用systemd工具如systemd-cgtop，或集成专业监控系统如prometheus。

如何限制Linux进程资源 cgroups基础配置与管理

在Linux系统中，限制进程资源的核心机制是cgroups（控制组）技术。它提供了一种强大的、细粒度的方式来管理和分配系统资源，比如CPU时间、内存、磁盘I/O和网络带宽，确保关键服务稳定运行，并防止单个进程或应用耗尽所有资源。这对于构建健壮的服务器环境、实现容器化技术（如Docker）以及优化资源利用率都至关重要。

解决方案

想象一下，你有一台服务器，上面跑着各种服务，有些可能很“贪婪”，偶尔会占用大量资源。cgroups就像是一个精明的管家，能够把这些“贪婪”的家伙圈起来，给它们划定地盘，确保它们不会互相干扰，也不会把整个系统拖垮。

cgroups的核心在于它的控制器（subsystems），每个控制器负责管理一种特定的资源。比如，cpu控制器管理CPU时间，memory控制器管理内存，blkio控制器管理块设备I/O。这些控制器可以组织成层次结构，就像文件系统一样。你可以创建一个父组，然后在其下创建子组，子组会继承父组的一些限制，并可以进一步细化。

在实际操作中，虽然可以直接通过操作/sys/fs/cgroup下的文件来配置cgroups，但现代Linux发行版普遍使用systemd来管理服务和资源。systemd为cgroups提供了一个更高级、更易用的抽象层，通过.slice、.scope和.service单元来定义和应用资源限制。

手动操作cgroups（了解原理）：

如果你想深入了解底层，可以尝试直接操作cgroup文件系统。

挂载cgroup文件系统： 大多数系统默认已经挂载了，通常在/sys/fs/cgroup。你可以通过mount -t cgroup查看。
创建一个cgroup： 例如，为CPU控制器创建一个名为my_app_group的组。
```
sudo mkdir /sys/fs/cgroup/cpu/my_app_group
```
登录后复制
配置资源限制：
- CPU限制： 使用cpu.cfs_period_us（周期，默认100000微秒）和cpu.cfs_quota_us（配额）来限制CPU使用率。例如，限制为20%的CPU。
```
sudo echo 100000 > /sys/fs/cgroup/cpu/my_app_group/cpu.cfs_period_us
sudo echo 20000 > /sys/fs/cgroup/cpu/my_app_group/cpu.cfs_quota_us
```
  登录后复制
- 内存限制： 使用memory.limit_in_bytes。例如，限制为500MB。
```
sudo echo 500M > /sys/fs/cgroup/memory/my_app_group/memory.limit_in_bytes
```
  登录后复制

将进程添加到cgroup： 将目标进程的PID写入到对应cgroup的tasks文件中。

sudo echo <PID> > /sys/fs/cgroup/cpu/my_app_group/tasks
sudo echo <PID> > /sys/fs/cgroup/memory/my_app_group/tasks

登录后复制

通过systemd管理cgroups（推荐）：

这是当前Linux系统中最常用和推荐的方式。

临时限制一个命令： 使用systemd-run。

systemd-run --unit=my-limited-command --scope \
    -p MemoryLimit=500M \
    -p CPUQuota=20% \
    /usr/bin/my_resource_intensive_command

登录后复制

这会创建一个临时的scope单元，并应用指定的资源限制。

为服务永久配置限制： 编辑或创建systemd服务单元文件（例如/etc/systemd/system/my-service.service）。

[Unit]
Description=My Limited Service

[Service]
ExecStart=/usr/bin/my_app_executable
MemoryLimit=500M
CPUQuota=20%
# CPUShares=512 # 相对权重，默认1024
# IOWeight=500 # 块设备I/O权重

[Install]
WantedBy=multi-user.target

登录后复制

保存后，重新加载systemd配置并启动服务：

sudo systemctl daemon-reload
sudo systemctl enable my-service
sudo systemctl start my-service

登录后复制

这样，my_app_executable进程及其子进程就会受到这些cgroup限制。

cgroups的核心概念和工作原理是什么？

cgroups，全称Control Groups，是Linux内核提供的一种机制，用于组织和管理一组进程的资源使用。它的设计初衷是为了解决多任务环境下资源分配不均、某个进程可能耗尽系统资源导致整体性能下降的问题。我记得刚接触cgroups时，最困惑的就是那些奇奇怪怪的文件名，比如cpu.cfs_period_us，这些其实就是内核暴露出来的接口，用于配置和查询资源状态。

核心概念有三个：

控制器（Controllers / Subsystems）： 这是cgroups的功能模块，每个控制器负责一种特定类型的资源管理。常见的有：
- cpu：管理CPU时间分配。
- cpuacct：报告CPU使用情况。
- memory：管理内存使用。
- blkio：管理块设备I/O访问。
- net_cls：标记网络数据包，以便通过tc（traffic control）进行流量整形。
- pids：限制cgroup中的进程数量。
- freezer：暂停或恢复cgroup中的进程。每个控制器都有自己的一套参数文件，比如cpu.cfs_quota_us、memory.limit_in_bytes。
层级结构（Hierarchies）： cgroups可以形成树状的层级结构。每个层级可以挂载一个或多个控制器。一个进程只能属于一个层级中的一个cgroup。这意味着，如果你在cpu层级下创建了一个cgroup，又在memory层级下创建了一个cgroup，同一个进程可以同时属于这两个不同层级下的cgroup。这种设计允许你根据不同的资源管理策略创建独立的层级。
控制组（Control Groups / cgroups）： 这是层级中的一个节点，也是实际进行资源限制和管理的对象。每个cgroup都有一个唯一的路径，对应文件系统中的一个目录。当你创建一个新的cgroup目录时，内核会自动在该目录下创建一系列文件，用于配置和报告该组的资源使用情况。

工作原理：

当一个进程被添加到某个cgroup中时，内核会根据该cgroup所属层级所挂载的控制器，对该进程的资源使用进行监控和限制。例如，如果进程被添加到cpu控制器下的一个cgroup，并且该cgroup设置了CPU配额，那么内核的调度器在分配CPU时间时，就会确保这个进程组的CPU使用不会超过设定的配额。同样，对于内存，当cgroup中的进程试图分配超过限制的内存时，内核可能会触发OOM（Out Of Memory）杀手，或者阻止进一步的内存分配。

乾坤圈新媒体矩阵管家

新媒体账号、门店矩阵智能管理系统

查看详情

cgroups v1和v2是两个主要的版本。v1允许不同控制器挂载到不同的层级，一个进程可以属于多个cgroup（在不同层级）。v2（Unified Hierarchy）则强制所有控制器共享一个单一的层级，一个进程只能属于一个cgroup，这简化了管理，并解决了v1中一些复杂和不一致的行为。现代系统通常会同时支持v1和v2，但systemd更多地倾向于使用v2的统一视图。

如何为特定应用或服务配置CPU和内存限制？

为特定应用或服务配置CPU和内存限制，最推荐且最现代的方式是利用systemd的单元文件。这种方式不仅清晰、可维护，而且能与系统启动和管理流程无缝集成。这里有个小坑，CPUShares是相对权重，CPUQuota才是硬性百分比限制。很多时候，大家会混淆这两个概念。

配置CPU限制：

systemd提供了两个主要的CPU相关参数：

CPUShares： 这是一个相对权重值，默认为1024。它不直接限制CPU的绝对使用率，而是在CPU资源紧张时，决定各个cgroup之间CPU时间的分配比例。例如，一个CPUShares=2048的服务将获得两倍于CPUShares=1024的服务所能获得的CPU时间。这在CPU过载时很有用，可以确保高优先级服务获得更多CPU。
CPUQuota： 这是更直接的硬性限制，以百分比表示。例如，CPUQuota=20%意味着该服务在任何情况下都不能使用超过一个CPU核心的20%时间。如果系统有多个核心，这表示该服务最多可以使用一个核心的20%能力。这对应于cgroup文件系统中的cpu.cfs_period_us和cpu.cfs_quota_us。CPUQuota=20%实际上就是cpu.cfs_quota_us = 20000 (假设cpu.cfs_period_us = 100000)。

配置内存限制：

MemoryLimit： 这是最常用的内存限制参数，直接指定服务可以使用的最大内存量，例如500M、2G。当服务试图分配超过此限制的内存时，内核可能会触发OOM killer来终止该服务，以保护系统稳定性。
MemorySwapMax： 限制服务可以使用的交换空间（swap）量。如果设置为0，则禁用交换。
MemoryHigh： 这是一个“软限制”。当内存使用超过此值时，内核会尝试回收内存，但不会立即终止进程。这有助于在达到硬限制之前缓解内存压力。

实际操作示例（通过Systemd服务单元文件）：

假设你有一个名为my_web_app的服务，你想限制它最多使用50%的CPU和一个核心，以及1GB的内存。

创建或编辑服务单元文件： 通常位于/etc/systemd/system/my_web_app.service。

[Unit]
Description=My Web Application Service
After=network.target

[Service]
ExecStart=/usr/local/bin/my_web_app_binary --config /etc/my_web_app/config.ini
Restart=on-failure
# CPU限制：最多使用一个核心的50%
CPUQuota=50%
# 内存限制：最多使用1GB内存
MemoryLimit=1G
# 如果希望进程在内存不足时被立即终止，确保没有设置 MemoryAccounting=no
# 默认是开启的，不需要显式设置

[Install]
WantedBy=multi-user.target

登录后复制

重新加载Systemd配置并启动服务：
```
sudo systemctl daemon-reload
sudo systemctl enable my_web_app.service
sudo systemctl start my_web_app.service
```
登录后复制
通过这种方式，my_web_app进程及其派生的子进程都会自动归入由systemd创建的cgroup中，并受到这些资源限制。

监控cgroups资源使用情况有哪些方法？

了解cgroups的配置固然重要，但更关键的是能够实时或定期地监控这些限制是否生效，以及进程的实际资源消耗情况。我通常会写个小脚本去定期读取cgroup文件系统中的统计文件，或者直接用systemd-cgtop快速看一眼，但要长期监控和分析，还是得靠专业的监控系统。

以下是一些常用的监控方法：

直接读取cgroup文件系统： 这是最底层也是最直接的方式。每个cgroup目录下都会有一些统计文件，记录了该组的资源使用情况。

CPU使用：

cat /sys/fs/cgroup/cpuacct/<your_cgroup_path>/cpuacct.usage  # 总CPU使用时间（纳秒）
cat /sys/fs/cgroup/cpuacct/<your_cgroup_path>/cpuacct.usage_percpu # 每个CPU核的使用时间

登录后复制

内存使用：

cat /sys/fs/cgroup/memory/<your_cgroup_path>/memory.usage_in_bytes # 当前内存使用量
cat /sys/fs/cgroup/memory/<your_cgroup_path>/memory.max_usage_in_bytes # 历史最大内存使用量
cat /sys/fs/cgroup/memory/<your_cgroup_path>/memory.stat # 更详细的内存统计信息

登录后复制

这些文件提供了原始数据，适合编写脚本进行自定义分析。

使用systemd工具：systemd提供了一些方便的工具来查看由它管理的cgroups。
- systemd-cgls： 列出当前所有由systemd管理的cgroup层级结构。
```
systemd-cgls
```
  登录后复制
- systemd-cgtop： 类似于top命令，但专注于显示cgroup的资源使用情况，按CPU或内存使用排序。这是一个非常实用的实时监控工具。
```
systemd-cgtop
```
  登录后复制
- systemctl status <unit_name>： 查看特定服务或scope单元的当前状态，包括其cgroup路径和一些基本资源使用信息。
```
systemctl status my_web_app.service
```
  登录后复制
使用专门的cgroup工具： 一些发行版可能提供了额外的工具，例如libcgroup-tools包中的cgget和cgexec。
- cgget： 获取指定cgroup的参数和统计信息。
```
cgget -r memory.usage_in_bytes my_web_app.service # 获取my_web_app服务的内存使用
```
  登录后复制
  （注意：使用systemd时，cgroup路径通常是/system.slice/my_web_app.service或/user.slice/user-UID.slice/user@UID.service等）
集成到监控系统： 对于生产环境，将cgroups的监控数据集成到专业的监控系统（如Prometheus + Grafana、Zabbix、Nagios等）是最佳实践。这些系统可以通过Agent（如Node Exporter for Prometheus）收集cgroup的指标，然后进行可视化、告警和长期趋势分析。
- Prometheus Node Exporter： 会自动暴露/sys/fs/cgroup中的许多指标，你可以通过PromQL查询并用Grafana进行展示。