tuned需手动启用dynamic模式才能自动调优：先启动tuned服务并加载cpufreq模块，再执行tuned-adm profile + dynamic true；云环境可能禁用频率调节，自定义profile需脚本驱动，排查须查journalctl日志。
Tuned 能自动根据负载切换模式，但默认不开启活动监控 —— 你得手动启用 tuned-adm 的动态调优功能，并确认后端服务支持实时探测。
确认 tuned 是否已安装并运行 tuned 服务
很多发行版（如 RHEL/CentOS 8+、Fedora、Rocky/AlmaLinux）预装 tuned，但服务常处于 inactive 状态。直接执行 tuned-adm list 报错或无输出，大概率是服务没起来。
- 运行
systemctl is-active tuned查状态，非active就要启动：sudo systemctl enable --now tuned - 检查是否加载了内核模块：
lsmod | grep cpufreq（动态频率调节依赖此）；若无输出，可能需加载acpi-cpufreq或intel_cpufreq - 某些云环境（如 AWS EC2）禁用 CPU 频率调节，
cpupower frequency-info显示driver: none，此时 tuned 的cpu-balance类 profile 会降级或失效
启用 tuned-adm 动态调优（dynamic 模式）
静态 profile（如 throughput-performance）不会随负载变化；只有开启 dynamic 模式，tuned 才会周期性读取 /proc/stat、/proc/loadavg、/sys/fs/cgroup/cpu.stat 等指标并触发 profile 切换。
- 启用命令：
sudo tuned-adm profile powersave && sudo tuned-adm dynamic true（注意：必须先设一个基础 profile，再开 dynamic） - 验证是否生效：
sudo tuned-adm active输出应含Dynamic tuning: on - 默认每 10 秒采样一次，间隔由
/etc/tuned/<profile-name>/tuned.conf</profile-name>中的dynamic_threshold和update_interval控制；修改后需重启tuned服务
自定义 profile 实现「应用级」负载感知
tuned 原生只看系统级指标（CPU、I/O、内存），不识别具体进程或端口。若你想“Nginx 请求突增时切 performance，空闲时回 powersave”，就得绕过默认逻辑，用外部脚本驱动。
- 在
/etc/tuned/my-web-profile/下新建 profile，含tuned.conf和可执行脚本script.sh -
script.sh里用ss -tn sport = :80 | wc -l或pgrep -f "nginx: worker" | wc -l判断活跃连接数，再调用tuned-adm profile my-web-performance - 通过 systemd timer（如每 5 秒触发一次）或
inotifywait监控日志关键词来驱动该脚本，避免轮询开销过大 - 注意权限：脚本需
chmod +x，且运行用户要有tuned-adm免密权限（加到/etc/sudoers.d/tuned：%tuned ALL=(ALL) NOPASSWD: /usr/bin/tuned-adm）
常见失效场景与排查线索
动态调优看似自动，但实际容易静默失败 —— 没报错，也不切换，负载高了依然卡在 powersave。
-
journalctl -u tuned -n 50 --no-pager查日志，重点看是否有Failed to get load average或Cannot switch profile: another transaction is in progress - 多个 tuned profile 冲突：比如同时运行
kdump或第三方性能工具（如irqbalance），它们可能锁住 sysctl 或 cgroup 设置 - 容器环境限制：Pod 中的 cgroup v2 默认隔离更严，
tuned读不到宿主机的/sys/fs/cgroup/cpu.stat，需改用 hostPID/hostNetwork 或在宿主机侧统一调控 - Profile 切换有延迟：从检测到触发通常 2–3 个采样周期（即 20–30 秒），不适合毫秒级响应场景；高频切换还可能引发
cpupower错误：Failed to set new cpu frequency
真正稳定的自动调优，从来不是靠开一个开关就完事 —— 它依赖准确的指标源、干净的执行上下文、以及对 profile 切换边界的清晰认知。别跳过 journalctl -u tuned，那是唯一告诉你“它到底有没有在干活”的地方。
