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（控制组）技术。它提供了一种强大的、细粒度的方式来管理和分配系统资源，比如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_ussudo 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 > /sys/fs/cgroup/cpu/my_app_group/taskssudo echo > /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_executableMemoryLimit=500MCPUQuota=20%# CPUShares=512 # 相对权重，默认1024# IOWeight=500 # 块设备I/O权重[Install]WantedBy=multi-user.target
保存后，重新加载systemd配置并启动服务：
sudo systemctl daemon-reloadsudo systemctl enable my-servicesudo 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）杀手，或者阻止进一步的内存分配。
乾坤圈新媒体矩阵管家
新媒体账号、门店矩阵智能管理系统
17 查看详情 
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 ServiceAfter=network.target[Service]ExecStart=/usr/local/bin/my_web_app_binary --config /etc/my_web_app/config.iniRestart=on-failure# CPU限制：最多使用一个核心的50%CPUQuota=50%# 内存限制：最多使用1GB内存MemoryLimit=1G# 如果希望进程在内存不足时被立即终止，确保没有设置 MemoryAccounting=no# 默认是开启的，不需要显式设置[Install]WantedBy=multi-user.target
重新加载Systemd配置并启动服务：
sudo systemctl daemon-reloadsudo systemctl enable my_web_app.servicesudo systemctl start my_web_app.service
通过这种方式，my_web_app进程及其派生的子进程都会自动归入由systemd创建的cgroup中，并受到这些资源限制。
监控cgroups资源使用情况有哪些方法？
了解cgroups的配置固然重要，但更关键的是能够实时或定期地监控这些限制是否生效，以及进程的实际资源消耗情况。我通常会写个小脚本去定期读取cgroup文件系统中的统计文件，或者直接用systemd-cgtop快速看一眼，但要长期监控和分析，还是得靠专业的监控系统。
以下是一些常用的监控方法：
直接读取cgroup文件系统：这是最底层也是最直接的方式。每个cgroup目录下都会有一些统计文件，记录了该组的资源使用情况。
CPU使用：
cat /sys/fs/cgroup/cpuacct//cpuacct.usage # 总CPU使用时间（纳秒）cat /sys/fs/cgroup/cpuacct//cpuacct.usage_percpu # 每个CPU核的使用时间
内存使用：
cat /sys/fs/cgroup/memory//memory.usage_in_bytes # 当前内存使用量cat /sys/fs/cgroup/memory//memory.max_usage_in_bytes # 历史最大内存使用量cat /sys/fs/cgroup/memory//memory.stat # 更详细的内存统计信息
这些文件提供了原始数据，适合编写脚本进行自定义分析。
使用systemd工具：systemd提供了一些方便的工具来查看由它管理的cgroups。
systemd-cgls： 列出当前所有由systemd管理的cgroup层级结构。
systemd-cgls
systemd-cgtop： 类似于top命令，但专注于显示cgroup的资源使用情况，按CPU或内存使用排序。这是一个非常实用的实时监控工具。
systemd-cgtop
systemctl status ： 查看特定服务或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进行展示。
通过上述方法，你可以有效地跟踪进程的资源消耗，验证cgroup限制是否按预期工作，并在资源瓶颈出现时迅速定位问题。
以上就是如何限制Linux进程资源 cgroups基础配置与管理的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/465576.html
微信扫一扫 
支付宝扫一扫 
