在Ubuntu系统运维中，使用systemd管理服务时，我们经常需要限制某个服务的内存与CPU使用量，以防止其过度消耗资源影响系统整体稳定性。例如，一个Java应用可能内存泄漏，或者一个后台脚本可能陷入死循环吃满CPU。直接有效的解决方法是在服务的systemd unit文件（通常是.service文件）中，通过配置"MemoryMax"、"CPUQuota"等指令来设定硬性限制。

理解systemd的资源控制核心：cgroups

systemd对服务资源（内存、CPU、IO等）的限制，本质上是依赖Linux内核的cgroups（控制组）机制实现的。当你为一个systemd服务设置了内存上限，systemd会在后台为该服务创建对应的cgroup，并将服务进程放入其中，由内核强制执行资源隔离与限制。这意味着限制是内核级别的，比用户空间工具更可靠、更底层。作为管理员，你几乎无需直接操作复杂的cgroups接口，systemd通过简洁的配置文件指令将其抽象化了，这是其最大的运维便利性。

限制服务内存使用的具体配置方法

内存限制主要防止服务耗尽系统RAM或交换空间。关键指令有多个，用于控制不同层面的内存使用：

1. "MemoryMax"： 设置服务所能使用的最大物理内存（RAM）。这是硬限制，一旦触及，内核会通过OOM Killer终止服务进程。单位可以是K, M, G, T等。

2. "MemorySwapMax"： 设置服务所能使用的最大交换分区（swap）和内存的总和。设置为0表示禁止使用任何交换空间。

3. "MemoryHigh"： 设置一个“软限制”。当服务内存使用超过此值时，系统会开始对服务进程施加回收压力，试图让其降低内存使用，但不会立即杀死进程。这通常比"MemoryMax"更友好。

你需要编辑或创建服务的unit文件，例如"/etc/systemd/system/myapp.service"，在"[Service]"段落下添加指令。一个完整的示例如下：

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

[Service]
Type=simple
ExecStart=/usr/bin/myapp
Restart=on-failure

# 内存限制配置
MemoryMax=512M
MemorySwapMax=1G
MemoryHigh=400M

[Install]
WantedBy=multi-user.target

此配置意味着："myapp"服务物理内存使用被硬限制在512MB，内存+交换空间总量被限制在1GB。当物理内存使用超过400MB时，系统会尝试让其收敛。配置完成后，执行"sudo systemctl daemon-reload"重载配置，并使用"sudo systemctl restart myapp"重启服务生效。

限制服务CPU使用的具体配置方法

CPU限制主要控制服务能使用的CPU时间片份额，防止单个服务使CPU负载长期处于高位。主要指令如下：

1. "CPUQuota"： 这是最常用的指令，用于设置该服务可以使用CPU时间的上限。例如，"CPUQuota=50%"表示该服务最多只能使用单个CPU核心的50%。如果系统有多核，它可以在所有核心上运行，但总时间份额被限制。"CPUQuota=200%"则表示它最多可以使用两个完整核心的100%时间。

2. "CPUWeight" / "CPUShares"： 用于在多个竞争CPU资源的服务之间设置相对权重（默认权重是1024）。权重越高，在CPU繁忙时获得的份额越多。这是一种比例分配，而非绝对上限。

3. "CPUAffinity"： 可以控制服务进程只在特定的CPU核心上运行，这对于NUMA架构优化或隔离核心很有用。

同样，在服务的".service"文件中配置。一个结合CPU和内存限制的示例如下：

[Unit]
Description=Heavy Computation Service
After=network.target

[Service]
Type=exec
ExecStart=/usr/local/bin/compute_worker
User=worker

# CPU限制配置
CPUQuota=150%
CPUWeight=500

# 内存限制配置
MemoryMax=2G
MemorySwapMax=0

# 防止内存碎片化，可选
LimitMEMLOCK=64M

[Install]
WantedBy=multi-user.target

此配置将计算服务限制在最多使用1.5个CPU核心的全力，并在CPU竞争时给予中等权重（500）。内存被严格限制在2G物理内存，且禁止使用交换空间。"LimitMEMLOCK"是一个相关扩展，限制了服务可以锁定在物理内存中的页数。

验证与监控资源限制效果

配置后，如何确认限制已生效？systemd提供了强大的查询命令。

1. 使用"systemctl show"命令查看服务的全部cgroup属性：

sudo systemctl show myapp.service -p MemoryMax -p MemoryCurrent -p CPUQuota -p CPUUsageNSec

这会显示配置的最大内存、当前内存使用、CPU配额和已占用的CPU时间。

2. 更直观的方法是使用"systemd-cgtop"命令。这是一个类似"top"的工具，但按cgroup层级显示资源消耗。你可以实时看到每个服务（cgroup）的CPU、内存、IO使用情况，一眼就能判断你的限制是否在起作用。

3. 直接查看cgroup文件系统。systemd将服务挂载在"/sys/fs/cgroup/"下相应的子系统（如"memory"， "cpu"）中。例如，查看内存限制和当前使用：

cat /sys/fs/cgroup/system.slice/myapp.service/memory.max
cat /sys/fs/cgroup/system.slice/myapp.service/memory.current

这是最底层的验证方式。

高级技巧与最佳实践

1. 组合使用软硬限制： 对于内存，建议同时设置"MemoryHigh"（软限制）和"MemoryMax"（硬限制）。软限制提供缓冲和警告，给服务一个自我清理的机会；硬限制是最终安全网。对于CPU，可以组合"CPUQuota"（绝对上限）和"CPUWeight"（相对优先级）。

2. 注意"Type"的影响： 服务的"Type"（如"forking", "oneshot", "notify"）会影响systemd对主进程的识别。对于资源限制，通常推荐使用"Type=exec"或"Type=simple"，以确保限制正确应用于目标进程及其所有子进程。

3. 限制子进程： 默认情况下，通过"[Service]"段设置的资源限制会作用于整个控制组（cgroup），即服务进程及其创建的所有子进程。这是符合预期的，也是其优势。

4. 结合"Slice"使用： 对于更复杂的多服务资源池管理，可以创建自定义的"Slice"单元。例如，创建一个"background.slice"，为其分配总体的CPU和内存预算，然后将多个后台服务放入这个Slice。这样可以对一组服务进行整体的资源约束，实现层级化的资源分配。

# 创建 /etc/systemd/system/background.slice
[Slice]
MemoryHigh=4G
MemoryMax=6G
CPUQuota=300%

# 修改服务文件，加入：
[Service]
Slice=background.slice

5. 动态调整： 在系统运行中，你可以使用"systemctl set-property"命令临时调整限制，而无需重启服务。例如："sudo systemctl set-property myapp.service MemoryMax=800M"。但注意，动态修改的配置在重启后会失效，永久修改仍需编辑unit文件并重载。

常见陷阱与排错思路

1. 限制不生效： 首先检查unit文件语法是否正确，是否在正确的段落（"[Service]"）中。执行"sudo systemctl daemon-reload"后是否重启了服务？使用"systemctl show"或"systemd-cgtop"验证。确保systemd版本较新（Ubuntu 18.04及以上支持较好）。

2. 服务被意外杀死： 如果服务频繁因OOM被杀死，检查"MemoryMax"设置是否过小，或服务是否存在内存泄漏。同时观察"MemoryHigh"的触发情况，系统日志（"journalctl -u myapp"）中可能有相关记录。

3. 性能下降不符合预期： 检查"CPUQuota"是否设置过低，导致服务计算能力不足。也要考虑IO限制（如"IOWeight"、"IOReadBandwidthMax"）是否成为瓶颈，因为磁盘IO慢也会导致CPU等待。

4. 交换空间使用问题： 如果你将"MemorySwapMax"设置为0（禁用swap），而"MemoryMax"设置得较小，当服务内存需求激增时，可能因无法交换而直接被OOM杀死，而不是变慢。需要根据服务特性权衡。

总之，熟练运用systemd的资源控制功能，是Ubuntu系统运维走向精细化和专业化的关键一步。它让你从被动的资源告警处理，转变为主动的、可预测的资源规划，极大地提升了生产环境的服务质量和整体稳定性。