Linux怎么限制服务的资源占用-linux运维-PHP中文网

答案：通过Systemd服务单元文件配置Cgroups资源限制是管理Linux服务资源占用的核心方法。具体可设置CPUQuota和MemoryLimit等参数实现对CPU和内存的硬性限制，结合BlockIOWeight和IOWriteBandwidthMax等控制I/O，同时启用Accounting以监控使用情况，并遵循监控先行、逐步调优的最佳实践，避免过度限制导致服务异常。

linux怎么限制服务的资源占用

Linux服务限制资源占用，核心机制在于Linux内核的Control Groups（Cgroups）功能。通过Cgroups，我们可以精细地为进程组分配和限制CPU、内存、I/O等系统资源。而Systemd作为现代Linux系统中的初始化系统和服务管理器，则提供了更高级、更便捷的接口来配置和管理这些Cgroups限制，极大地简化了操作。

解决方案

要限制Linux服务的资源占用，主要有两大途径：直接操作Cgroups文件系统，或通过Systemd服务单元文件进行配置。在我看来，后者是更推荐的方案，因为它与服务生命周期管理紧密结合，更具可维护性。

1. 通过Systemd配置资源限制

Systemd集成了Cgroups的功能，允许你在服务的

.service

登录后复制

单元文件中直接定义资源限制。这是最常见且推荐的做法。

CPU限制:
- ```
CPUShares=
```
  登录后复制
  : 设置CPU份额。这是一个相对值，默认是1024。如果一个服务有2048，另一个有1024，那么第一个服务理论上可以获得两倍的CPU时间，当系统CPU资源紧张时尤其明显。
- ```
CPUQuota=
```
  登录后复制
  : 设置CPU硬性配额。例如，
```
CPUQuota=50%
```
  登录后复制
  意味着该服务最多只能使用一个CPU核心的50%时间。
```
CPUQuota=200%
```
  登录后复制
  则意味着最多可以使用两个CPU核心。这比
```
CPUShares
```
  登录后复制
  更直接，尤其适合需要严格控制CPU上限的场景。
- ```
CPUAccounting=true
```
  登录后复制
  : 启用CPU资源统计，这样你才能看到服务实际的CPU使用情况。
内存限制:
- ```
MemoryLimit=
```
  登录后复制
  : 设置内存的硬性上限。例如，
```
MemoryLimit=512M
```
  登录后复制
  。当服务尝试分配超过此限制的内存时，可能会触发OOM Killer（Out-Of-Memory Killer）终止该服务。
- ```
MemorySwapMax=
```
  登录后复制
  : 限制交换空间的使用。
- ```
MemoryAccounting=true
```
  登录后复制
  : 启用内存资源统计。
I/O限制:
- ```
BlockIOWeight=
```
  登录后复制
  : 设置块设备I/O的权重，类似于
```
CPUShares
```
  登录后复制
  ，默认是1000。
- ```
IOReadBandwidthMax=
```
  登录后复制
  : 限制从块设备读取的最大带宽，例如
```
IOReadBandwidthMax=/dev/sda 10M
```
  登录后复制
  。
- ```
IOWriteBandwidthMax=
```
  登录后复制
  : 限制写入块设备的最大带宽。
- ```
IOAccounting=true
```
  登录后复制
  : 启用I/O资源统计。

操作步骤：

找到或创建一个服务的
```
.service
```
登录后复制
文件，通常位于
```
/etc/systemd/system/
```
登录后复制
或
```
/usr/lib/systemd/system/
```
登录后复制
。

在

[Service]

登录后复制

部分添加相应的资源限制参数。例如，要限制一个名为

my-app.service

登录后复制

的服务最多使用一个核心的50% CPU和512MB内存：

[Unit]
Description=My Application Service

[Service]
ExecStart=/usr/bin/my-app-server
CPUQuota=50%
MemoryLimit=512M
CPUAccounting=true
MemoryAccounting=true
BlockIOWeight=700 # 假设需要降低I/O优先级

[Install]
WantedBy=multi-user.target

登录后复制

保存文件后，运行
```
sudo systemctl daemon-reload
```
登录后复制
重新加载Systemd配置。
然后重启服务：
```
sudo systemctl restart my-app.service
```
登录后复制
。
你可以使用
```
systemctl status my-app.service
```
登录后复制
或
```
systemd-cgtop
```
登录后复制
来查看资源使用情况。

2. 直接操作Cgroups文件系统（不常用，但理解原理很重要）

这种方式更底层，通常用于Systemd无法满足的复杂场景，或者在没有Systemd的环境中。Cgroups文件系统通常挂载在

/sys/fs/cgroup/

登录后复制

下，每个子系统（如

cpu

登录后复制

、

memory

登录后复制

、

blkio

登录后复制

）都有自己的目录。

创建Cgroup:

sudo mkdir /sys/fs/cgroup/cpu/my_service_group

登录后复制

sudo mkdir /sys/fs/cgroup/memory/my_service_group

登录后复制

...

设置限制:

sudo echo 50000 > /sys/fs/cgroup/cpu/my_service_group/cpu.cfs_quota_us

登录后复制

(50% of one core)

sudo echo 100000 > /sys/fs/cgroup/cpu/my_service_group/cpu.cfs_period_us

登录后复制

sudo echo 536870912 > /sys/fs/cgroup/memory/my_service_group/memory.limit_in_bytes

登录后复制

(512MB)

将进程ID（PID）加入Cgroup:

sudo echo <PID> > /sys/fs/cgroup/cpu/my_service_group/tasks

登录后复制

sudo echo <PID> > /sys/fs/cgroup/memory/my_service_group/tasks

登录后复制

这种方式虽然灵活，但手动管理复杂且容易出错，所以Systemd的抽象层更受欢迎。

如何利用Cgroups精确控制Linux服务的CPU和内存使用？

要精确控制Linux服务的CPU和内存，Cgroups提供了非常细致的参数。我们得先明白，CPU的限制有两种主要模式：份额（shares）和配额（quota）。内存则主要是硬性限制。

AppMall应用商店

AI应用商店，提供即时交付、按需付费的人工智能应用服务

查看详情

对于CPU，

cpu.shares

登录后复制

是一个相对权重。如果你有两个服务A和B，服务A的

cpu.shares

登录后复制

是2048，服务B是1024，那么当CPU资源紧张时，A会获得大约两倍于B的CPU时间。但如果CPU资源充足，它们都可以无限制地使用。这在多租户环境中很有用，可以保证重要服务在资源争抢时获得更多份额。

更直接的控制是

cpu.cfs_quota_us

登录后复制

和

cpu.cfs_period_us

登录后复制

。

cfs_period_us

登录后复制

定义了一个周期（通常是100ms即100000微秒），

cfs_quota_us

登录后复制

则定义了在这个周期内，该cgroup下的进程可以使用的CPU时间。比如，如果

period

登录后复制

是100000，

quota

登录后复制

是50000，那么这个cgroup在一个100ms的周期内最多只能使用50ms的CPU时间，这相当于限制它只能使用一个核心的50%。如果需要使用两个核心的全部时间，你可以设置

quota

登录后复制

为200000。这种方式提供了硬性的上限，确保服务不会“跑飞”。在我看来，对于那些CPU敏感且需要严格控制的服务，

CPUQuota

登录后复制

是更稳妥的选择。

至于内存，

memory.limit_in_bytes

登录后复制

是其核心。它设定了一个绝对的内存上限。一旦cgroup中的进程试图分配超过这个限制的内存，系统就会触发OOM Killer，通常会终止占用内存最多的进程。这可能会导致服务崩溃，所以设置时务必谨慎。除了硬限制，

memory.swappiness

登录后复制

（虽然不在cgroup本身，但影响内存管理）也值得关注，它决定了系统将内存页交换到磁盘的积极程度。一个较低的

swappiness

登录后复制

值（如0或10）会使系统更倾向于使用物理内存，减少交换。不过，如果内存限制很严格，即使

swappiness

登录后复制

很低，也可能导致频繁的OOM。一个常见的实践是，在设置

MemoryLimit

登录后复制

时，同时启用

MemoryAccounting=true

登录后复制

，这样才能通过

cat /sys/fs/cgroup/memory/<group_name>/memory.usage_in_bytes

登录后复制

等文件来监控实际的内存使用情况。

举个例子，假设我们有一个Web服务，它偶尔会有流量高峰，但我们不希望它占用超过一个核心的CPU资源，并且内存不能超过2GB。在Systemd中，我们会这样配置：

[Service]
ExecStart=/usr/bin/my-web-server
CPUQuota=100% # 限制最多使用一个核心
MemoryLimit=2G
CPUAccounting=true
MemoryAccounting=true

登录后复制

这样，即使Web服务在高峰期，它的CPU使用率也不会超过一个核心，同时内存也被限制在2GB以内。这种硬性限制对于维持系统稳定性至关重要，尤其是在资源有限的服务器上部署多个服务时。

Systemd如何与Cgroups协同，简化服务I/O和网络带宽的限制？

Systemd在处理I/O限制方面，同样提供了非常友好的抽象。虽然Cgroups本身对网络带宽的直接限制能力相对有限（通常需要结合

tc

登录后复制

等工具），但对于块设备的I/O（磁盘读写），Systemd与Cgroups的协同工作非常出色。

Systemd通过

BlockIOWeight=

登录后复制

IOReadBandwidthMax=

登录后复制

IOWriteBandwidthMax=

登录后复制

这些参数来管理服务的磁盘I/O。

```
BlockIOWeight=
```
登录后复制
: 这个参数设置的是一个相对权重，类似于CPU的
```
CPUShares
```
登录后复制
。它影响的是当多个服务争抢磁盘I/O时，各自能获得的I/O带宽比例。默认值是1000。如果你的数据库服务对I/O性能要求极高，而日志收集服务可以容忍较低的I/O，你可以将数据库服务的
```
BlockIOWeight
```
登录后复制
设为2000，而日志服务的设为500。这样，在磁盘繁忙时，数据库服务就能获得更多的I/O资源。这对于避免“I/O饥饿”问题非常有效。
```
IOReadBandwidthMax=
```
登录后复制
和
```
IOWriteBandwidthMax=
```
登录后复制
: 这两个参数提供的是硬性的I/O带宽限制。你可以指定具体的设备和最大带宽，例如
```
IOReadBandwidthMax=/dev/sda 10M
```
登录后复制
意味着从
```
/dev/sda
```
登录后复制
设备读取数据的最大速度是10MB/s。这对于防止某个服务因为大量读写操作而耗尽磁盘I/O带宽，影响其他关键服务至关重要。我个人觉得，对于那些已知会产生大量I/O的服务，设定一个明确的硬性带宽上限是很有必要的，尤其是在共享存储或SSD寿命管理方面。

关于网络带宽： 这是一个比较棘手的问题。Cgroups本身并没有直接提供像CPU或内存那样简单直接的网络带宽限制机制。通常，网络流量整形（traffic shaping）是通过Linux内核的

tc

登录后复制

（traffic control）工具来实现的。

tc

登录后复制

可以基于IP地址、端口、协议等多种规则来限制带宽。虽然Cgroups可以将进程分组，但这主要是为了方便

tc

登录后复制

规则的匹配，而不是Cgroups本身在限制带宽。也就是说，你可以在一个cgroup中运行你的服务，然后通过

tc

登录后复制

规则去匹配这个cgroup中的进程产生的网络流量，进而限制其带宽。这通常需要更复杂的配置，涉及到

iptables

登录后复制

和

tc

登录后复制

命令的组合。所以，如果你需要精细到网络带宽的限制，可能需要跳出Systemd和Cgroups的直接管理范畴，深入到网络层配置。

在Systemd单元文件中配置I/O限制的例子：

[Service]
ExecStart=/usr/bin/my-data-processor
BlockIOWeight=500 # 降低其I/O优先级
IOReadBandwidthMax=/dev/nvme0n1 20M # 限制从NVMe设备读取20MB/s
IOWriteBandwidthMax=/dev/nvme0n1 10M # 限制写入NVMe设备10MB/s
IOAccounting=true

登录后复制

通过这样的配置，我们可以确保数据处理服务不会因为其大量的磁盘I/O操作而拖垮整个系统，特别是在使用高性能存储设备时，避免某个进程“独占”带宽。

在实施Linux服务资源限制时，有哪些常见的陷阱和最佳实践？

实施Linux服务资源限制，虽然能有效提升系统稳定性，但过程中也容易踩坑。在我看来，理解这些陷阱并遵循最佳实践，是确保限制有效且不产生负面影响的关键。

常见的陷阱：

限制过低导致服务崩溃或性能下降： 这是最常见的错误。如果你对服务的资源需求预估不足，设置的CPU、内存或I/O限制过低，服务在高负载时就可能因为资源不足而变慢、报错，甚至被OOM Killer终止。我见过不少案例，因为内存限制太紧，服务在启动时就因为初始化需要更多内存而直接崩溃。
忽略依赖服务的影响： 一个服务可能依赖于其他服务（如数据库、缓存）。如果你只限制了主服务，而其依赖的服务没有得到相应的限制或优化，那么瓶颈可能会转移，导致整体性能不佳。
I/O限制可能影响整个磁盘性能： 特别是当多个服务共享同一个物理磁盘时，对某个服务的I/O限制可能会在某种程度上影响到其他服务的I/O性能，尤其是在使用
```
BlockIOWeight
```
登录后复制
时，需要权衡。硬性带宽限制（
```
IOReadBandwidthMax
```
登录后复制
等）虽然直接，但如果设备路径不准确或限制过严，也可能导致意想不到的问题。
OOM Killer的触发时机和后果： 当内存限制被突破时，OOM Killer会选择一个进程（不一定是你的服务进程）来终止，以释放内存。这可能导致关键服务被误杀，而不是你期望的那个“超限”服务。理解OOM Killer的启发式算法很重要。
监控不足，无法评估效果： 缺乏有效的监控，你根本不知道你的资源限制是否合理，服务是否真的在限制下稳定运行，或者是否存在潜在的资源瓶颈。盲目设置限制就像盲人摸象。
过度依赖默认值： Systemd和Cgroups有很多默认行为。不理解这些默认值，可能会导致限制不如预期，或者产生副作用。

最佳实践：

充分了解服务资源需求： 在设置任何限制之前，先通过一段时间的监控（
```
top
```
登录后复制
,
```
htop
```
登录后复制
,
```
vmstat
```
登录后复制
,
```
iostat
```
登录后复制
,
```
promtool
```
登录后复制
配合node_exporter等）来了解服务在正常负载和峰值负载下的CPU、内存、I/O使用情况。这是最基础也是最重要的一步。
从小范围开始，逐步调整： 不要一次性设置过于严格的限制。可以先设置一个相对宽松的限制，然后根据监控数据和实际运行情况，逐步收紧。这就像给一个水龙头拧螺丝，慢慢来才能找到最佳平衡点。
进行压力测试和回归测试： 在生产环境部署前，务必在测试环境中对设置了资源限制的服务进行压力测试，模拟峰值负载，观察其行为。同时，也要确保限制不会引入新的bug或性能问题。
结合监控工具： 部署专业的监控系统，实时收集Cgroups的各项指标（如
```
/sys/fs/cgroup/.../cpu.usage_usec
```
登录后复制
,
```
memory.usage_in_bytes
```
登录后复制
等）。这能让你清晰地看到服务是否接近或触及限制，并及时做出调整。
```
systemd-cgtop
```
登录后复制
和
```
cgget
```
登录后复制
也是很好的即时查看工具。
区分硬限制和软限制：
```
CPUQuota
```
登录后复制
是硬限制，
```
CPUShares
```
登录后复制
是软限制。根据服务的关键程度和对资源独占的需求，合理选择。关键服务可能需要硬限制，而后台批处理任务则更适合软限制，以充分利用空闲资源。
考虑容器化技术： 如果你的服务部署环境允许，Docker和Kubernetes等容器化平台已经将Cgroups的资源管理进行了高度封装和自动化。通过这些平台，你可以更声明式地定义服务的资源需求和限制，大大简化了管理复杂度。在我看来，这是现代微服务架构下管理资源最优雅的方式。
记录和文档化： 记录你为每个服务设置的资源限制及其背后的理由。这对于未来的维护、故障排查和团队协作都至关重要。