在Debian系统中，通过systemd的CPUQuota机制限制进程资源，核心操作就是编辑服务单元文件，在[Service]段加入CPUQuota=参数来指定CPU使用百分比。比如你想让某个服务最多只能使用50%的单核CPU，就写CPUQuota=50%；想限制为1.5个核，就写CPUQuota=150%。这套机制基于Linux内核的cgroup v2资源控制，从Debian 10（Buster）开始默认启用，Debian 11（Bullseye）和Debian 12（Bookworm）更是全面拥抱cgroup v2，配置更简洁、层级更清晰。下面我会从原理、配置方法、安全加固、实战案例四个维度把这件事讲透。
一、CPUQuota的底层原理：cgroup v2如何卡住CPU
systemd本身不直接控制CPU，它只是把指令下发给内核的cgroup（Control Group）子系统。cgroup v2在Debian新版本中是默认挂载的，路径通常在/sys/fs/cgroup/下。当你在服务单元里写了CPUQuota=50%，systemd会在启动该服务时，自动创建一个对应的cgroup，并设置cpu.max文件为"50000 100000"（单位是微秒，表示每100ms周期内最多跑50ms）。内核调度器看到这个限制后，就会在进程超出配额时强制 throttling（降频），而不是直接杀掉进程。这跟CPUAffinity（绑核）不一样，Quota是限制用量，Affinity是限制位置。
需要特别注意的是，Debian 11及之后如果你还在用cgroup v1（legacy模式），CPUQuota的写法和行为会有差异。v1用的是cpu.cfs_quota_us和cpu.cfs_period_us两个文件，而v2合并成了一个cpu.max。Debian 12 Bookworm默认就是v2，所以你配置的时候不用额外切换，直接写CPUQuota就行。如果你的系统还是v1，可以通过检查/proc/cgroups文件确认，看到"0::/"这种格式就是v2。
二、具体配置步骤：从编辑单元到验证生效
第一步，找到你要限制的服务单元文件。如果是系统自带的服务，比如nginx、mysql，直接去/lib/systemd/system/下找；如果是你自己部署的，通常在/etc/systemd/system/下。千万不要直接改/lib/systemd/system/里的文件，因为系统更新会覆盖。正确做法是用override机制：
systemctl edit nginx.service
这条命令会自动创建一个/etc/systemd/system/nginx.service.d/override.conf文件，你在里面写配置就行。
第二步，写入CPUQuota限制。假设你要把nginx限制在75%的单核CPU：
[Service] CPUQuota=75%
如果你想限制它最多用2个核（在多核机器上），可以写：
[Service] CPUQuota=200%
第三步，重载systemd配置并重启服务：
systemctl daemon-reload systemctl restart nginx
第四步，验证是否生效。用systemctl status查看服务状态没问题后，再用以下命令确认cgroup实际值：
cat /sys/fs/cgroup/system.slice/nginx.service/cpu.max
正常输出应该是"75000 100000"或者"200000 100000"，跟你配的一致就说明限制生效了。你也可以用systemd-cgtop命令实时查看各个服务的CPU使用情况，这个工具非常直观，类似top但按cgroup分组显示。
三、安全加固：光限制CPU还不够，这些配置必须加上
在Debian安全场景下，光设一个CPUQuota远远不够。一个被入侵的服务如果还能无限制地使用内存、进行网络通信、写文件系统，那CPU限制形同虚设。所以必须配合其他systemd安全 hardening 参数一起用。
首先是内存限制。用MemoryMax参数限制服务最大内存用量，单位可以是K、M、G：
[Service] CPUQuota=50% MemoryMax=512M
其次是禁止特权操作。加上这些参数可以大幅降低提权风险：
[Service] NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ReadWritePaths=/var/log/nginx CapabilityBoundingSet=
NoNewPrivileges=true意味着进程执行后不能再获得任何新权限（比如不能suid）；ProtectSystem=strict把/usr、/boot等挂载为只读；ProtectHome=true让服务看不到/root和/home下的文件；CapabilityBoundingSet=空表示剥夺所有Linux capabilities。这些组合起来，即使服务被攻破，攻击者能做的事情也极其有限。
另外，建议加上RestrictSUIDSGID=yes和RestrictRealtime=yes，防止服务创建setuid文件或使用实时调度策略。对于网络服务，还可以用RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX来限制只能用IPv4、IPv6和Unix socket，禁用其他协议族。
四、多服务场景和层级管理：别把所有鸡蛋放一个篮子
在实际生产环境中，你可能有几十个服务需要不同程度的资源限制。systemd支持通过slice（切片）来做层级管理。比如你可以创建一个"low-priority" slice，把所有低优先级服务放进去，统一给这个slice设CPUQuota：
systemctl edit low-priority.slice
[Slice] CPUQuota=30%
然后把具体服务分配到这个slice：
[Service] Slice=low-priority.slice
这样做的好处是管理方便，改一个slice的配额，下面所有服务自动生效。Debian 12的systemd对slice的支持已经非常成熟，你甚至可以嵌套slice，做更细粒度的控制。
还有一个容易被忽略的点：CPUQuota和CPUWeight不要混用。CPUWeight是在多个服务竞争CPU时的相对权重（默认100），而CPUQuota是硬上限。如果你同时设了两个，systemd会以Quota为准。所以如果你的目标是硬性限制，就只用Quota；如果只是想让某个服务优先级低一点，用Weight更合适。
五、常见踩坑和排错指南
第一个坑：CPUQuota只对可以被throttle的进程有效。如果服务里有子进程是直接fork出来的并且没有被systemd追踪到，那子进程可能不受限制。解决办法是确保服务使用Type=simple或Type=exec，并且systemd能正确追踪所有子进程。对于复杂的守护进程，可以用KillMode=control-group确保杀掉整个cgroup树。
第二个坑：在cgroup v1系统上，CPUQuota的百分比是相对于所有核的总和。比如你有4核机器，CPUQuota=50%实际上是限制用2个核（50%×4=2）。而在v2下，百分比是相对于单核的，CPUQuota=50%就是半个核，不管你有多少核。这个差异在迁移老系统时特别容易搞混。
第三个坑：有些服务启动时会短暂飙高CPU（比如Java应用的JIT编译阶段），如果你的Quota设得太低，服务可能启动失败或者反复重启。建议先用一个宽松的值（比如200%）跑一段时间观察峰值，再逐步调低到合理范围。
第四个坑：不要忘了daemon-reload。改了override.conf之后如果不执行systemctl daemon-reload，systemd根本不会读取新配置，服务重启后还是老参数。这是新手最常犯的错误。
六、实战案例：限制一个Python爬虫服务的资源
假设你在Debian服务器上跑了一个Python爬虫服务crawler.service，它经常把CPU打满影响其他业务。你可以这样做：
systemctl edit crawler.service
[Service] CPUQuota=40% MemoryMax=1G NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ReadWritePaths=/opt/crawler/data /var/log/crawler RestrictAddressFamilies=AF_INET AF_INET6
这套配置把爬虫锁在40%单核CPU、1G内存以内，不能提权、不能写系统目录、只能访问指定的数据和日志路径。就算爬虫代码有漏洞被利用，攻击者也翻不出什么浪花。配置完之后执行：
systemctl daemon-reload systemctl restart crawler systemd-cgtop
用systemd-cgtop确认crawler.service的CPU列显示在40%以下，就大功告成了。
七、总结与建议
在Debian上用systemd的CPUQuota做资源限制，本质上是利用内核cgroup能力实现的用户态配置。操作不复杂，但要做到安全可靠，必须把CPU、内存、文件系统、网络、权限这几个维度一起考虑。建议从以下几点入手：第一，先确认你的Debian版本和cgroup版本；第二，用override机制而不是直接改原始单元文件；第三，配合NoNewPrivileges、ProtectSystem等安全参数形成纵深防御；第四，用systemd-cgtop和cgroup文件双重验证。资源限制不是银弹，但它是Debian服务器安全加固中成本最低、效果最直接的手段之一，尤其适合多租户环境和对外暴露的服务。
