答案是使用cgroups机制限制Linux进程资源。通过systemd-run临时限制或修改systemd服务文件持久化配置，可控制CPU、内存、I/O、进程数等资源，避免单个进程耗尽系统资源，同时需注意OOM Killer、CPU配额过低等常见问题，结合监控与测试精细调整参数。
在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_applicationCPUQuota=30%MemoryLimit=2GIOWeight=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_groupecho 100000 | sudo tee /sys/fs/cgroup/cpu/my_group/cpu.cfs_period_usecho 50000 | sudo tee /sys/fs/cgroup/cpu/my_group/cpu.cfs_quota_us # 50% CPUecho | 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和内存。不过，如果需要精确的网络带宽控制，还是得靠专门的网络工具。
搜狐资讯
AI资讯助手，追踪所有你关心的信息
24 查看详情
除了手动操作，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%，内存不超过1GBsystemd-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如何限制进程的资源使用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/432664.html
微信扫一扫 
支付宝扫一扫 
