必须将升级会话放入专用systemd slice以实现CPU硬限制，因传统包管理器自身不支持资源控制，而systemd slice能强制约束所有子进程的CPUQuota、MemoryLimit等资源，且不依赖启动方式或脚本嵌套。
直接给包管理器升级过程划CPU红线，关键不是去改yum或apt本身，而是把整个升级会话放进一个带硬性限制的systemd slice里。systemd的slice机制天然适合这种“临时重载任务隔离”场景，它不依赖进程启动方式，也不怕脚本嵌套，只要进程属于该slice，就强制受控。
确认系统支持Cgroup v2与TasksMax基础能力
先确保底层机制就位，否则后续配置无效：
- 运行
mount | grep cgroup，确认输出中包含type cgroup2；没有则需在内核启动参数中添加systemd.unified_cgroup_hierarchy=1 - 检查当前用户slice默认限制：
systemctl --user show --property=TasksMax，若显示TasksMax=512或更低，说明默认值偏紧，需要覆盖 - 验证
CPUQuota可用：systemctl --user show --property=CPUAccounting应为yes；如为no，需在/etc/systemd/user.conf中设DefaultCPUAccounting=yes并重启用户实例
创建专用slice并设定CPU硬上限
不修改全局配置，只为升级任务新建隔离环境：
- 新建slice单元文件：
/etc/systemd/system/pkg-upgrade.slice - 内容如下（以限制为总CPU的30%为例）：
[Unit] Description=Package Upgrade Isolation Slice Before=multi-user.target <p>[Slice] CPUAccounting=yes CPUQuota=30% MemoryLimit=2G
- 启用并加载：
sudo systemctl daemon-reload && sudo systemctl enable pkg-upgrade.slice
在slice上下文中执行升级命令
让yum update或apt full-upgrade的所有子进程都落入该slice，而非默认的user.slice：
- 使用
systemd-run直接启动（推荐）：systemd-run --scope --slice=pkg-upgrade.slice --scope --uid=root yum update -y - 或对交互式会话整体切片（适用于需多次操作的复杂升级）：
systemd-run --scope --slice=pkg-upgrade.slice -- bash，然后在新shell中执行yum update - 验证是否生效：执行中运行
systemctl --user list-units --type=scope --all | grep pkg，再查其CPU使用：systemctl --user status pkg-upgrade.slice，输出中应含CPUUsageSec=...及明确的quota值
避免常见陷阱的实操要点
很多失败源于忽略systemd的会话归属逻辑：
- 不要用
sudo直接调用yum——这会让进程挂在system.slice下，脱离用户slice管控 - 禁止在已有的screen/tmux会话中执行
systemd-run——它们可能继承父会话的cgroup路径，导致slice不生效；建议新开终端或用loginctl terminate-session $X清理旧session - 如果升级涉及systemd服务重启（如kernel更新后需reboot），需额外在
pkg-upgrade.slice中加入AllowIsolate=yes，否则systemctl isolate类操作会被拒绝
