Linux如何限制进程的资源使用

P粉602998670

发布时间：2025-09-05 08:13:01

864人浏览过

来源于php中文网

原创

答案是使用cgroups机制限制Linux进程资源。通过systemd-run临时限制或修改systemd服务文件持久化配置，可控制CPU、内存、I/O、进程数等资源，避免单个进程耗尽系统资源，同时需注意OOM Killer、CPU配额过低等常见问题，结合监控与测试精细调整参数。

linux如何限制进程的资源使用

在Linux系统里，想给某个进程戴上“紧箍咒”，限制它的资源消耗，核心手段就是利用强大的cgroups（control groups）机制。它就像一个精密的管家，能把系统资源按需分配，防止单个进程“吃光”所有资源，影响其他服务的稳定运行。这不仅仅是为了系统稳定，很多时候也是为了实现公平调度和资源隔离，尤其是在容器化和多租户环境中，cgroups简直是基石般的存在。

解决方案

要限制Linux进程的资源使用，最直接且推荐的方式就是通过cgroups（控制组）。cgroups允许你将一组进程组织起来，并对这组进程的资源使用进行限制、审计和优先级管理。

从操作层面看，有两种主要途径：

使用
```
systemd-run
```
进行临时或一次性限制： 这是最简单快捷的方式，尤其适合测试或启动一个临时服务。
```
systemd-run
```
命令能够将你的进程在一个临时的
```
scope
```
单元中运行，并直接应用cgroup参数。比如，你想运行一个CPU密集型任务，但不想它占用超过一半的CPU时间：
```
systemd-run --scope -p CPUQuota=50% /usr/bin/my_cpu_heavy_process
```
或者，限制内存使用在500MB以内：
```
systemd-run --scope -p MemoryLimit=500M /usr/bin/my_memory_hungry_app
```
这种方式的优点是即用即走，非常方便。
通过
```
systemd
```
服务单元文件进行持久化限制： 对于需要长期运行的服务或应用程序，修改其
```
systemd
```
服务单元文件（
```
.service
```
文件）是最佳实践。在
```
[Service]
```
段落中添加或修改相应的资源限制参数即可。例如，编辑
```
/etc/systemd/system/my_service.service
```
：
```
[Unit]
Description=My Custom Service

[Service]
ExecStart=/usr/local/bin/my_application
CPUQuota=30%
MemoryLimit=2G
IOWeight=500
# 其他资源限制...

[Install]
WantedBy=multi-user.target
```
保存后，执行
```
sudo systemctl daemon-reload
```
然后
```
sudo systemctl restart my_service
```
使配置生效。这种方式的限制是持久的，并且与服务的生命周期绑定，管理起来非常规范。
直接操作cgroup文件系统（较底层，不常用）： 虽然不推荐日常使用，但了解其原理很有帮助。cgroups是通过一个虚拟文件系统暴露的，通常挂载在
```
/sys/fs/cgroup
```
。你可以手动创建目录（cgroup），然后将进程的PID写入该cgroup的
```
tasks
```
文件，再通过写入对应子系统的参数文件来设置限制。比如，限制CPU份额：
```
sudo mkdir /sys/fs/cgroup/cpu/my_group
echo 100000 | sudo tee /sys/fs/cgroup/cpu/my_group/cpu.cfs_period_us
echo 50000 | sudo tee /sys/fs/cgroup/cpu/my_group/cpu.cfs_quota_us # 50% CPU
echo  | sudo tee /sys/fs/cgroup/cpu/my_group/tasks
```
这种方式复杂且容易出错，通常只在调试或特殊场景下使用，或者由容器运行时（如Docker、Kubernetes）在后台自动完成。

cgroups到底能精细化控制哪些资源维度？

说实话，刚开始接触cgroups时，我个人也觉得它有点像个“黑盒子”，但深入了解后会发现它能控制的资源维度远比想象中要丰富和精细。它不仅仅是简单地限制CPU或内存，而是提供了一整套子系统来管理不同类型的资源。

核心的资源子系统包括：

CPU子系统 (
cpu
或
cpu,cpuacct
)：这是最常用的。
- ```
cpu.shares
```
  ：设置CPU的相对权重。当系统CPU资源紧张时，权重高的cgroup会获得更多的CPU时间。比如，一个cgroup的
```
shares
```
  是1024，另一个是512，那么在竞争时，前者会获得大约两倍的CPU时间。
- ```
cpu.cfs_period_us
```
  和
```
cpu.cfs_quota_us
```
  ：这两个参数配合使用，可以实现更精确的CPU时间配额。
```
cfs_period_us
```
  定义了一个调度周期（微秒），
```
cfs_quota_us
```
  则定义了在这个周期内，该cgroup可以使用的CPU时间（微秒）。例如，
```
period=100000
```
  （100ms），
```
quota=50000
```
  （50ms），意味着该cgroup在一个100ms的周期内最多只能使用50ms的CPU时间，也就是50%的CPU。这对于限制单个进程的绝对CPU使用率非常有效。
内存子系统 (
memory
)：
- ```
memory.limit_in_bytes
```
  ：设置cgroup可用的最大内存（包括文件缓存）。一旦超出，系统可能会触发OOM（Out Of Memory）Killer来终止cgroup内的进程，或者根据
```
memory.swappiness
```
  和
```
memory.failcnt
```
  等参数进行处理。
- ```
memory.memsw.limit_in_bytes
```
  ：限制内存和交换空间的总和。
- ```
memory.swappiness
```
  ：控制该cgroup内进程的匿名内存和文件缓存的交换行为。
I/O子系统 (
blkio
)：
- ```
blkio.weight
```
  ：设置块设备的I/O权重，类似于CPU shares，决定了在I/O竞争时的相对优先级。
- ```
blkio.throttle.read_bps_device
```
  和
```
blkio.throttle.write_bps_device
```
  ：可以对特定设备设置每秒读写字节数（BPS）的硬性限制。
- ```
blkio.throttle.read_iops_device
```
  和
```
blkio.throttle.write_iops_device
```
  ：对特定设备设置每秒读写操作数（IOPS）的硬性限制。这在多租户环境，防止某个进程“刷爆”磁盘I/O时非常有用。
PID子系统 (
pids
)：
- ```
pids.max
```
  ：限制一个cgroup内可以创建的进程/线程总数。这能有效防止fork炸弹。
设备子系统 (
devices
)：
- ```
devices.allow
```
  和
```
devices.deny
```
  ：控制cgroup内的进程是否可以访问特定的设备文件。这在安全隔离方面很有用。

网络资源方面，cgroups本身没有直接的“网络带宽”子系统。通常，网络流量的限制是通过

tc

（traffic control）工具结合

iptables

来完成的，但cgroups可以通过限制CPU和I/O间接影响网络吞吐量，因为网络处理也需要CPU和内存。不过，如果需要精确的网络带宽控制，还是得靠专门的网络工具。

我秀秀淘宝客api源码

程序介绍：程序采用.net 2.0进行开发，全自动应用淘客api，自动采集信息，无需，手工更新，源码完全开放。（程序改进无需填入阿里妈妈淘客API 您只要修改app_code文件下的config.cs文件中的id为你的淘客id即可）针对淘客3/300毫秒的查询限制，系统采用相应的解决方案，可以解决大部分因此限制带来的问题；程序采用全局异常，避免偶尔没考虑到的异常带来的问题；程序源码全部开放，请使

下载

除了手动操作，Systemd如何优雅地管理进程资源限制？

我个人觉得，

systemd

在整合cgroups方面做得非常出色，它把原本复杂且分散的cgroup文件系统操作，封装成了一系列直观的服务单元配置参数。这大大降低了管理成本和出错率，尤其是在生产环境中，通过

systemd

来管理资源限制几乎成了标准做法。

systemd

主要通过两种方式实现：

服务单元文件（
```
.service
```
）中的资源参数： 这是最常见、最推荐的方式。你可以在
```
[Service]
```
段落中直接设置一系列
```
systemd
```
特有的资源控制参数，
```
systemd
```
会在启动服务时，自动为该服务创建一个cgroup，并将这些参数应用到对应的cgroup子系统。例如：
- ```
CPUAccounting=yes
```
  ：启用CPU使用量统计。
- ```
CPUQuota=30%
```
  ：将CPU使用限制在30%。
- ```
CPUShares=512
```
  ：设置CPU相对权重。
- ```
MemoryAccounting=yes
```
  ：启用内存使用量统计。
- ```
MemoryLimit=2G
```
  ：限制内存使用为2GB。
- ```
MemorySwapMax=0
```
  ：禁止该服务使用交换空间。
- ```
IOAccounting=yes
```
  ：启用I/O统计。
- ```
IOWeight=500
```
  ：设置I/O权重。
- ```
TasksMax=100
```
  ：限制最大进程/线程数为100。
- ```
BlockIOWeight=600
```
  ：针对块设备的I/O权重。
- ```
BlockIODeviceWeight=/dev/sda 1000
```
  ：针对
```
/dev/sda
```
  设备的I/O权重。
这些参数的命名非常直观，而且
```
systemd
```
会自动处理cgroup文件系统的底层细节，你只需要关注业务逻辑和资源需求。当你需要调整时，只需修改
```
.service
```
文件，然后
```
systemctl daemon-reload
```
和
```
systemctl restart
```
即可。这比手动创建目录、写入文件要优雅得多，也更易于维护和版本控制。
```
systemd-run
```
命令： 前面也提到过，
```
systemd-run
```
是
```
systemd
```
提供的一个非常灵活的工具，它允许你在一个临时的
```
systemd
```
单元（通常是
```
scope
```
单元）中运行一个命令，并为其应用资源限制。这在需要快速测试某个进程的资源消耗，或者运行一个一次性、但又不想它“失控”的任务时，特别方便。比如，我经常用它来测试一些新的脚本或编译任务，防止它们意外占用过多资源，影响我正在进行的其他工作。
```
# 运行一个命令，并限制其CPU使用不超过20%，内存不超过1GB
systemd-run --scope -p CPUQuota=20% -p MemoryLimit=1G my_script.sh arg1 arg2
```
```
systemd-run
```
的强大之处在于它能创建各种类型的
```
systemd
```
单元，并能与所有
```
systemd
```
的资源控制参数无缝集成。这使得它成为日常运维和开发中一个不可或缺的工具。

资源限制配置不当，可能踩到哪些坑，又该如何排查？

配置资源限制这事儿，虽然能带来很多好处，但如果做得不够精细或者缺乏充分测试，那可真是一不小心就会“踩坑”。我个人就遇到过好几次因为资源限制配置不当，导致服务看似正常运行，实则效率低下，甚至直接崩溃的情况。

常见的坑和排查思路：

OOM Killer频繁出动（内存限制过低）： 这是最常见的。你可能给一个内存需求不明确的服务设置了过低的
```
MemoryLimit
```
。服务启动时一切正常，但在高负载或长时间运行后，内存逐渐增长，最终达到上限，Linux内核的OOM Killer就会无情地将进程杀死。
- 排查： 检查系统日志（
```
journalctl -xe
```
  或
```
/var/log/messages
```
  ），通常会看到“Out of memory: Kill process...”的字样，明确指出哪个进程被杀以及原因。同时，可以通过
```
systemctl status my_service
```
  查看服务的状态，如果经常重启，且退出码异常，很可能就是OOM。
- 解决： 逐步调高
```
MemoryLimit
```
  ，并结合
```
free -h
```
  、
```
top
```
  或
```
htop
```
  等工具，在高负载下观察服务实际的内存使用峰值，留出一定的余量。
```
cgroup
```
  的内存统计文件
```
/sys/fs/cgroup/memory//memory.usage_in_bytes
```
  也能提供精确的数据。
服务响应缓慢，CPU利用率“假性”不高（CPUQuota限制过低）： 你可能给一个计算密集型服务设置了
```
CPUQuota=20%
```
，结果服务虽然没崩溃，但用户抱怨响应慢得像蜗牛。你用
```
top
```
一看，总CPU利用率可能不高，但你的服务进程的CPU使用率也上不去，被硬性限制住了。
- 排查： 观察
```
systemctl status my_service
```
  ，可能会看到
```
CPUQuota
```
  相关的告警。更直接的是查看cgroup的CPU统计文件：
```
/sys/fs/cgroup/cpu//cpu.stat
```
  。里面的
```
nr_throttled
```
  和
```
throttled_time
```
  字段会告诉你进程因为达到CPU配额而被限制了多少次和多长时间。如果这两个值很高，那基本就是CPU限制太紧了。
- 解决： 同样是逐步调高
```
CPUQuota
```
  ，直到服务性能满足要求。
磁盘I/O成为瓶颈（
```
blkio
```
限制过严）： 特别是在数据库或日志服务中，如果
```
blkio
```
的
```
*_bps_device
```
或
```
*_iops_device
```
设置得太低，会导致磁盘读写速度跟不上，进而影响整个服务的响应速度。
- 排查： 使用
```
iostat -xz 1
```
  或
```
atop
```
  等工具观察磁盘I/O性能。如果发现某个磁盘的
```
%util
```
  很高，但
```
r/s
```
  或
```
w/s
```
  （IOPS）或者
```
rKB/s
```
  或
```
wKB/s
```
  （BPS）却远低于磁盘的实际能力，那就要怀疑是
```
blkio
```
  限制在作祟。同样，可以查看cgroup的
```
blkio
```
  统计文件，例如
```
/sys/fs/cgroup/blkio//blkio.throttle.io_service_bytes
```
  等。
- 解决： 根据实际I/O需求，调整
```
blkio
```
  的限制参数。
进程数超限导致服务无法启动或异常（
```
TasksMax
```
限制）： 有些应用程序会创建大量的线程或子进程。如果
```
TasksMax
```
设置得太小，服务可能在启动阶段就因为无法创建足够的进程而失败，或者在高并发时无法处理新的请求。
- 排查： 查看服务启动日志或
```
journalctl -xe
```
  ，可能会有“fork failed”或“resource temporarily unavailable”等错误信息。
- 解决： 评估服务在高负载下所需的进程/线程数，并适当调高
```
TasksMax
```
  。

通用排查建议：

从小到大，逐步调整： 永远不要一开始就设置一个非常激进的限制。从一个宽松的限制开始，然后逐步收紧，观察服务行为。
结合监控： 部署合适的监控系统（如Prometheus + Grafana）来收集cgroup的各种指标，这能让你更直观地看到资源使用趋势和限制效果。
压力测试： 在应用资源限制后，进行充分的压力测试，模拟真实世界的负载，才能发现潜在的问题。
理解应用程序： 真正理解你的应用程序的资源需求模式是关键。它是CPU密集型？内存密集型？还是I/O密集型？这决定了你应该重点关注哪个cgroup子系统。

总的来说，资源限制是一把双刃剑，用好了能让系统更稳定、更高效，用不好则可能带来新的麻烦。细致的观察、充分的测试和对cgroups机制的深入理解，是避免这些坑的关键。

Linux 孤儿进程为何不会拖垮系统

Linux 系统重启后配置丢失的根因

Linux OOM Killer 的触发条件与应对策略

Linux 启动服务过多对性能的影响

Linux 内核日志中常被忽略的重要信息