RHEL 9.7 部署与优化实战：从安装到内核调优的完整指南

我去年接手过一套跑在 RHEL 8.6 上的监控平台，因为要接入新的数据采集链路，被迫把操作系统从 8 系升到 9.7。当时第一反应是"不就升个级嘛"，结果光是在部署阶段就踩了七八个坑，从安装源的 GPG 校验到网卡命名规则变更，从内核参数兼容到旧的 systemd 服务单元失效，每一项都够喝一壶的。所以这次写 RHEL 9.7 的部署与优化，我不打算给你一份照搬手册式的清单，而是把我实际跑过的流程、调过的参数、还有那些"没人告诉你但迟早会撞上"的细节，一次性摊开讲清楚。

这篇文章适合谁？两类人：一类是准备从 CentOS 7/8 或者 RHEL 8 迁移过来的运维，另一类是刚上手 RHEL 9 系、想避开基础配置误区的开发者。你可以跟着正文一步步操作，也可以先通读一遍再按需翻阅。部署部分我会讲到安装源的配置策略、磁盘分区和软件包选择的取舍；优化部分重点覆盖内核参数、文件系统挂载选项、systemd 服务裁剪三大块，最后再加一个真实场景下的问题排查链路，看看当系统出现性能异常时，到底应该从哪里下手。

1. 部署 RHEL 9.7 前的几个关键决策

很多人拿到 ISO 就开始点下一步，直到装完才发现基础没打对。部署 RHEL 9.7 之前，有几个决策点非常影响后续使用体验，我按重要程度逐个说。

1.1 版本选择：RHEL 9.7 与 9.x 其他小版本的关系

RHEL 的版本号规则是这样的：大版本 9 代表内核和用户空间主版本，小版本号（9.1、9.2 ... 9.7）代表累积更新的快照。9.7 本质上是在 9.6 基础上叠加了安全补丁、bugfix 和新硬件支持，而不是一个全新的大版本。所以如果你已经跑着 9.5 或 9.6，直接通过 dnf upgrade 升级到 9.7 是官方推荐路径，不用重新安装系统。

但如果你是全新部署，我建议直接安装 9.7，原因有两个：第一，9.7 的内核版本滚动到了 5.14.0-503.x 系列，对较新的服务器硬件（比如 Intel Sapphire Rapids、AMD Genoa 平台）支持更完善，避免了装完识别不了 NVMe 磁盘或者网卡不工作的尴尬；第二，9.7 默认启用了一些新的安全策略（比如更严格的 OpenSSL 默认加密套件），新装系统比老系统升级上去的配置更干净，安全基线也更好对齐。

提示：如果手头有正版订阅，装完 9.7 后记得先 subscription-manager register 注册。如果没有订阅，可以用开发者订阅（免费），或者评估版，否则 dnf 源用不了，后面优化阶段的包安装会比较痛苦。

1.2 安装源的选择：本地仓库 vs 在线仓库

RHEL 9.7 官方推荐通过红帽 CDN 在线安装，但我实测在部分网络环境下，CDN 速度并不稳定。我的建议是：如果公司内网有卫星服务器（Satellite）或者已经搭建了本地镜像仓库，优先用本地源；如果只是单机测试或小规模部署，用官方 CDN 就行，但在安装引导参数里最好指定 inst.repo= 指向国内可用的镜像源，可以大幅缩短安装时间。

安装源配置方式是在引导菜单中选择 "Install RHEL 9.7"，按 Tab 编辑引导参数，加上：

code复制inst.repo=https://mirror.example.com/rhel9.7/BaseOS

安装完成后，/etc/yum.repos.d/redhat.repo 会自动生成。如果你用的是本地镜像源，建议额外创建一个独立的 repo 文件，例如 /etc/yum.repos.d/local.repo，把官方 CDN 源注释掉或者调整优先级，避免 dnf 同时匹配多个源导致版本解析异常。

1.3 磁盘分区策略：LVM 依然是默认首选

RHEL 9.7 的安装器（Anaconda）默认分区方案会自动创建 /boot、/boot/efi（UEFI 引导时）、/ 和 swap，根文件系统放在 LVM 卷组里。我强烈建议保留这个默认行为，除非你非常明确自己在做什么。

为什么坚持 LVM？举个真实例子：监控平台的时序数据库数据目录 /var/lib/influxdb 增长很快，跑了大半年后磁盘占用逼近 95%。因为有 LVM，我直接在卷组里划了新的逻辑卷扩展上去，一分钟搞定，完全不需要停机。如果是普通分区，就得用 growpart 之类工具在线扩容，过程繁琐且存在风险。

自定义分区时，我习惯这样分配：

这里有个细节：RHEL 9.7 默认文件系统是 xfs，对 xfs 的调整（比如 shrink 缩小）几乎不可行，所以规划分区时要留出余量。另外，如果服务器内存很大（比如 256G 以上），swap 不建议开太大，因为 RHEL 9.7 的 swap 默认使用率很低，很多场景甚至可以不开 swap，靠 zram 或直接物理内存应付突发流量。

1.4 软件包选择：最小化安装 + 后续按需补充

Anaconda 安装界面里有 "Software Selection"，默认选的是 "Server with GUI"。对绝大多数服务器场景，我强烈建议选 "Minimal Install"（最小化安装），理由很直接：图形界面不仅占用内存和 CPU，还会带来大量安全攻击面，而且是很多性能问题的隐形原因。

最小化安装后，基础系统只有大概 300 多个包。之后需要什么再 dnf install 什么，例如：

bash复制# 安装常用运维工具
dnf install -y vim net-tools lsof tcpdump bind-utils nc telnet tree
# 安装开发工具链
dnf groupinstall -y "Development Tools"
# 安装容器运行时
dnf install -y podman buildah skopeo

这样装出来的系统干净、可控、依赖关系清晰。我在生产环境见过太多"反正硬盘大就把所有组件都勾上"的机器，最后跑起来一堆用不到的服务，光排查端口占用就得半天。

2. 安装过程实战：从引导到首次登录的完整流程

这个章节我把新的 RHEL 9.7 安装流程从零走一遍，每一步的关键选项和需要注意的地方都会提到。全程以 UEFI + LVM + xfs 为例。

2.1 制作安装介质与引导

制作 U 盘启动盘，推荐 dd 直接写入镜像，简单可靠：

bash复制dd if=/path/to/rhel-9.7-x86_64-dvd.iso of=/dev/sdb bs=4M status=progress

注意 of= 指向的是 U 盘设备节点，不是分区（比如 /dev/sdb 而不是 /dev/sdb1），写错的话会覆盖掉磁盘分区表。

UEFI 引导下，开机进入启动菜单选择 U 盘，RHEL 9.7 的 GRUB 菜单会出现三个选项：Install、Test this media & install、Rescue a system。一般选第一个即可，如果你担心 ISO 下载损坏，先跑 "Test this media" 也不亏，就是多等几分钟。

2.2 图形化安装器的关键配置

进入 Anaconda 界面后，有三个区域我建议仔细设置。

Installation Destination（安装目标）：选择要安装的磁盘，勾选 "Custom" 进入手动分区。RHEL 9.7 的 Anaconda 支持对 NVMe 磁盘直接配置 LVM。点 "Click here to create them automatically" 生成默认 LVM 结构，然后手动调整逻辑卷大小。这里有个小技巧：把 /var 独立出来，因为日志、缓存、容器镜像都可能出现在这里，独立分区后即使某个服务疯狂写日志导致分区满了，也只是 /var 满，根文件系统还能正常响应，方便排查问题。

Network & Host Name（网络与主机名）：强烈建议在安装阶段就把静态 IP 配好，否则装完系统后要手动改 nmcli，多一步不如少一步。在 Anaconda 里点开网卡，把 "IPv4 Settings" 改为手动，填入 IP、掩码、网关、DNS 即可。

Root Password（根密码）：RHEL 9.7 默认启用密码复杂度策略，设置过于简单的 root 密码会拦截。我建议直接设置高强度密码，后面如果需要再用 chage 调整策略。如果纯粹是内网测试机，也可以安装时按两次 Done 强制使用简单密码，但生产环境千万别这么做。

2.3 首次启动后的必做配置

安装完成后重启，用 root 登录，接下来有几件事我建议立刻做。

bash复制# 1. 更新系统补丁包
dnf update -y

# 2. 设置主机名
hostnamectl set-hostname rhel97-node1

# 3. 配置网络（如果没有在安装时配置）
nmcli con mod ens160 ipv4.addresses 192.168.1.100/24
nmcli con mod ens160 ipv4.gateway 192.168.1.1
nmcli con mod ens160 ipv4.dns "8.8.8.8 114.114.114.114"
nmcli con mod ens160 ipv4.method manual
nmcli con up ens160

# 4. 创建普通管理用户并加入 wheel 组
useradd -G wheel admin
passwd admin

RHEL 9.7 默认的 SELinux 是 enforcing 状态，这个我建议保持开启。虽然会导致一些第三方应用初次运行时出现 permission denied，但这是正常的，用 ausearch -m avc -ts recent 查看拒绝日志并针对性放行即可。不要图省事直接 setenforce 0，那等于给系统开了个大洞。

2.4 订阅和仓库配置的两种适用场景

如果你用的是正版订阅，安装完成后激活：

bash复制subscription-manager register --username=... --password=...
subscription-manager attach --auto
subscription-manager repos --enable rhel-9-for-x86_64-baseos-rpms
subscription-manager repos --enable rhel-9-for-x86_64-appstream-rpms

如果没有订阅，RHEL 9.7 也提供 60 天免费评估订阅，可以通过 subscription-manager register 时选择评估类型获得。要注意的是，有些第三方的 EPEL 源和 RHEL 9.7 的兼容性偶尔会有包冲突，安装 EPEL 时建议用 --nobest 或者指定版本号，避免 dnf 自动升级把系统自带库版本覆盖了。

3. 系统层优化：内核参数、文件系统与启动服务

系统装好只是第一步，真正让 RHEL 9.7 发挥性能的是后续的调优。这一节讲的都是我在实际项目中验证过的参数，每个参数我都会解释为什么这么改。

3.1 内核参数调优：从默认到生产可用

RHEL 9.7 的内核基于 5.14，很多网络和内存参数已经比较合理了，但对于高并发或 IO 密集场景，仍需手工调整。我通常在 /etc/sysctl.d/99-custom.conf 里集中配置，这样不会和系统默认配置冲突。

ini复制# 网络连接优化
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# 文件句柄限制
fs.file-max = 2097152

# 虚拟内存优化
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# 内核 panic 自动重启
kernel.panic = 10

关键参数解读如下：

net.core.somaxconn 是所有 TCP 连接队列的上限，默认 4096。如果你的应用使用 Nginx 或 Redis，这个值直接决定了高并发下的连接建立性能。调大后 Nginx 的 backlog 参数才有意义，否则在 Nginx 里设置 listen 80 backlog=65535 会受内核限制。

net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_fin_timeout 是一对。TIME_WAIT 状态的连接会占用本地端口，短连接请求量大的时候非常容易把端口耗尽。启用 tcp_tw_reuse 允许内核在安全条件下复用 TIME_WAIT 连接，配合缩短 tcp_fin_timeout，可以有效减轻端口压力。注意：tcp_tw_recycle 这个参数在 RHEL 9.7 里已经被移除了，不用再去设置，因为它和 NAT 网络环境有兼容问题，内核团队早就删了它。

vm.swappiness = 10 是我个人非常强烈推荐的一个调整。RHEL 9.7 默认 swappiness 是 30，意味着内核会倾向于把不常用的内存页交换到 swap。对于内存相对充裕的服务器，10 或更低的值能显著减少 swap 读写带来的延迟。如果内存很紧张，建议先加内存，而不是靠增大 swappiness 硬扛。

修改完成后执行：

bash复制sysctl -p /etc/sysctl.d/99-custom.conf

3.2 文件系统挂载选项：noatime 带来的 IO 改善

RHEL 9.7 默认 xfs 文件系统挂载时带有 relatime 选项。这个选项已经比传统的 atime 好很多，但对于读写频繁的应用（比如数据库、消息队列），每次访问文件时仍会更新 atime 元数据，产生额外的 IO。

我的建议是将数据分区挂载参数改为 noatime,nodiratime。查看当前挂载参数：

bash复制mount | grep xfs

如果确认数据分区是独立挂载点，直接修改 /etc/fstab，在对应行的 options 列加入 noatime,nodiratime，例如：

code复制/dev/mapper/rhel-data /data xfs defaults,noatime,nodiratime 0 0

然后重新挂载或重启生效。实测在 InfluxDB 写入场景里，noatime 能降低大约 5%-8% 的元数据相关 IO，虽然不惊艳，但胜在零成本。

另外，xfs 有一个专门的参数 allocsize，控制预分配空间的大小。对于顺序写较多的场景（比如视频录制、日志采集），可以设置为较大值：

code复制/dev/mapper/rhel-data /data xfs defaults,noatime,allocsize=1m 0 0

3.3 systemd 服务裁剪：关掉用不到的东西

最小化安装后服务数量已经很少了，但 RHEL 9.7 仍会默认启用一些可能用不到的服务，比如 abrtd（内核崩溃报告）、mdmonitor（软 RAID 监控）、irqbalance（中断均衡）等。这些服务本身不占太多资源，但对于追求稳定和精简的服务器，逐个审视是必要的。

我建议先看当前有哪些服务在跑：

bash复制systemctl list-units --type=service --state=running

然后逐个分析：

• abrtd / abrt-journal-core：自动化 Bug 报告工具，生产环境很少需要人工查看，可以关掉。

  bash复制systemctl disable --now abrtd abrt-journal-core
  

• mdmonitor：如果没用软 RAID，这个服务没有存在意义。

  bash复制systemctl disable --now mdmonitor
  

• irqbalance：多核 CPU 场景下自动平衡硬件中断。如果服务器是单核或核数很少，建议关闭；核数多的话保留，尤其是跑网络转发或存储时中断均衡能帮忙分散压力。

  bash复制# 关闭（仅对 CPU 核数较少的机器）
  systemctl disable --now irqbalance
  

有个很重要的细节：RHEL 9.7 引入了 systemd-sysusers 和 systemd-tmpfiles 机制，很多服务会在启动时自动创建用户或临时目录。裁剪服务时不要随意删除 /usr/lib/systemd/system 下的 unit 文件，正确的做法是 mask（屏蔽）：

bash复制systemctl mask abrtd

mask 会建立符号链接指向 /dev/null，即使有其他服务依赖它也无法启动，而且升级时不会被覆盖，比直接删除安全得多。

3.4 tuned 调优配置集：一键切换性能模式

RHEL 9.7 自带的 tuned 是个容易被忽视的调优神器。它可以一键切换系统调优配置集，把内核、磁盘、CPU governor 等参数批量调整到适合当前负载的模式。

bash复制# 安装和启动
dnf install -y tuned
systemctl enable --now tuned

# 查看当前激活的配置集
tuned-adm active

# 查看所有可用的配置集
tuned-adm list

# 切换到 throughput-performance（吞吐优先）
tuned-adm profile throughput-performance

# 或者切换到 latency-performance（延迟优先）
tuned-adm profile latency-performance

生产环境我个人的经验：通用型服务器用 throughput-performance，延迟敏感型服务（比如 Redis、金融交易系统）用 latency-performance，数据库服务器可以根据压力模式微调 tuned 的 sysctl 和 vm 部分。

tuned-adm recommend 会给出系统推荐配置集，一般是 virtual-guest 或者 throughput-performance，可以先用这个作为基准。

4. 针对具体应用场景的专项优化

这一节根据我自己的实战经验，拆几个在 RHEL 9.7 上常跑的典型应用的优化思路。无论你是跑容器、数据库还是 AI 推理框架，大概率能找到对应的优化手段。

4.1 容器场景：Podman 的 no-new-privileges 与 cgroup 版本

RHEL 9.7 默认的主推容器方案是 Podman，兼容 Docker CLI 的使用习惯，但底层更安全（rootless 模式成熟）。部署容器应用时，有几个优化点值得关注。

第一，RHEL 9.7 默认使用 cgroup v2，这带来更干净的内存和 CPU 隔离，但也意味着一些老旧的容器镜像可能无法正常启动资源限制。遇到这类问题，可以用 Podman 的 --cgroup-manager=cgroupfs 参数临时规避，但这只是权宜之计，长期还是要拉取适配 cgroup v2 的新版镜像。

第二，容器日志默认无限增长，这是导致磁盘耗尽的常见元凶。RHEL 9.7 的 Podman 通过 conmon 保存日志，可以用 --log-opt path=/var/log/pods/... 结合 logrotate 处理，或者更省心的方法是直接限制日志大小：

bash复制podman run -d --log-driver json-file --log-opt max-size=100m --log-opt max-file=3 \
  --name nginx nginx:latest

第三，RHEL 9.7 上跑容器时，SELinux 标签是默认强制的。挂载宿主机目录到容器时，要注意目录的 SELinux 类型。如果不想在宿主机上逐一设置标签，最快的方案是给容器加 --security-opt label=disable（不推荐生产环境，但测试时真的很省心）。

4.2 数据库场景：内核参数与 IO 调度器的配合

如果你在 RHEL 9.7 上跑 MySQL、PostgreSQL 或 MongoDB，除了数据库自身配置外，操作系统层面的这些参数常常被忽略，但影响立竿见影。

IO 调度器。RHEL 9.7 默认的 IO 调度器是 none（针对 NVMe 和 SSD），这对大多数 SSD 场景是最优解。但如果用的是 SATA SSD 或老式 SAS 盘，mq-deadline 可能更合适。查看当前调度器：

bash复制cat /sys/block/sda/queue/scheduler

改成 mq-deadline：

bash复制echo mq-deadline > /sys/block/sda/queue/scheduler

要永久生效，用 udev 规则或者内核引导参数 elevator=mq-deadline（RHEL 9.7 里对非 NVMe 设备仍然有效）。

内存参数。数据库通常吃内存大户。RHEL 9.7 的 vm.dirty_ratio 默认 20%，我习惯调低到 10%-15%，避免磁盘写缓存累计过多导致瞬间 IO 尖峰。这对 PostgreSQL 的 checkpoint 场景尤其重要，因为 checkpoint 刷 dirty page 时如果 dirty 比例太高，可能把磁盘 IO 打满，导致业务 SQL 全部排队。

网络参数。数据库有时候会产生大量短连接（特别是应用层连接池配置不当），这时 net.ipv4.tcp_max_syn_backlog 和 somaxconn 的调整就很重要，具体值我已经在 3.1 节给过了。

4.3 AI/大模型部署场景：CPU 调频与内存带宽

近期 RHEL 9.7 上常见的一类负载是本地部署大语言模型推理服务。很多人以为这类负载只需要 GPU，其实 CPU 侧的准备同样关键。

RHEL 9.7 的新内核支持较新的 CPU 调频驱动器，例如 intel_pstate 的 active 模式。建议把 CPU 调频策略设为 performance：

bash复制cpupower frequency-set -g performance

这个设置只对当前的 CPU 生效，重启后会恢复默认。要永久生效，可以用 systemd unit 或者 tuned 的 cpu-partitioning 配置集。

另外，大模型推理中内存带宽是瓶颈之一，特别是纯 CPU 推理时。RHEL 9.7 里核数较多的设备建议关掉 NUMA balancing（默认开启），因为内存自动迁移的开销偶尔会超过收益：

bash复制sysctl -w kernel.numa_balancing=0

写入 /etc/sysctl.d/99-custom.conf 持久化。如果是大规模多路服务器，NUMA 绑核这个操作需要更精细的规划，但单路机器直接关掉是最省心的选择。

4.4 微服务/中间件场景：网络栈参数微调

如果你在 RHEL 9.7 上部署 Java 微服务（Spring Boot、Quarkus 之类），或者消息队列（Kafka、RabbitMQ），网络参数的调优优先级最高。

除了第一节列出的 TCP 参数外，Kafka 这类依赖 page cache 的中间件还需要注意 vm.max_map_count。ES 和 Kafka 都要求这个值至少 262144，RHEL 9.7 默认是 65530，需要调高：

bash复制sysctl -w vm.max_map_count=262144

写进 /etc/sysctl.d/99-custom.conf。不调整的话，Kafka 启动时可能报 max map count 相关错误，Elasticsearch 也一样。

微服务间的调用如果是内部的 HTTP/RPC，建议开启 tcp_sack（默认已开）和 tcp_window_scaling（默认已开），这两个参数在 RHEL 9.7 上一般不需要改，但确认它们没有被之前的安装脚本意外关闭很有必要。

5. 部署后必做的健康检查与一次真实问题排查

这一节先说部署完成后的日常检查可以怎么做，然后给出一个我实际经历的排障过程，希望能帮大家在类似问题出现时有个参考方向。

5.1 健康检查清单

新装系统并优化完成后，我会跑一遍下面的命令，确认系统处于健康状态：

bash复制# 系统信息
hostnamectl
uname -r

# 关键服务状态
systemctl --failed
systemctl is-active sshd NetworkManager firewalld tuned

# 文件系统使用率
df -hT

# 内存与 swap
free -h

# 内核日志错误
journalctl -p err -b

# SELinux 拒绝日志
ausearch -m avc -ts recent

每天都跑一跑这些命令不太现实，建议做成一个脚本放到 cron 或 systemd timer 里，每天一封邮件或一条告警通知就够。

5.2 真实案例：RHEL 9.7 上 MySQL 偶发卡顿的排查过程

当时有一个客户环境，RHEL 9.7 + MySQL 8.0 跑订单系统，表现是每天下午高峰时段出现少量慢查询，TPS 没有明显下降，但 SQL 响应时间偶发飙到 2-3 秒。数据库侧排查了一遍，慢查询日志、InnoDB 状态都没发现明显异常。最后把焦点放到操作系统层。

第一步，先用 top 和 mpstat 观察 CPU：

bash复制mpstat -P ALL 1 10

发现某个瞬间有软中断（softirq）占用升高。再深入看中断分布：

bash复制cat /proc/interrupts

发现网卡中断基本集中在 CPU0 上。RHEL 9.7 上较新的网卡驱动默认会启用 RPS（Receive Packet Steering），但如果没有开启，多队列网卡的中断会只落在单个核心上。处理办法是启用 RPS 或者手动配置 smp_affinity：

bash复制echo f > /sys/class/net/ens160/queues/rx-0/rps_cpus

另外检查了 irqbalance 服务，发现客户安装时把该服务关闭了（按 3.3 节的说法，在部分机器上关掉没问题，但这个场景不应该关），重新打开后中断均衡到多核，软中断压力明显降低。

第二步，检查 IO 延迟。用 iostat -x 1 观察 %util 和 await，发现 SSD 的 IO 延迟正常，但 /var/lib/mysql 所在分区的 mount 参数是默认的 relatime。改成 noatime 后，文件访问元数据更新被去掉，卡的频率进一步降低。

第三步，观察内存回收。用 vmstat 1 看 si 和 so（swap in/out），发现内存不足时有少量换页。虽然数据库服务器内存配了 64G，但 MySQL 的 buffer pool 被调到了 48G，加上 RHEL 9.7 的 page cache 以及其他进程，内存已经非常紧张。调整方案：把 buffer pool 改为 40G，同时把 swappiness 从默认 30 降到 10，iptables 的 conntrack 表也顺手调大了一些。

这一系列调整做完后，再观察两天，慢查询尖峰基本消失。

这个案例想说明什么？RHEL 9.7 的默认配置虽然在大多数场景下没问题，但实际业务负载往往是多个因素叠加的结果。不要指望改一个参数解决所有问题，而是要有"CPU -> IO -> 内存 -> 网络"这样一条系统性的排查思路。这也是我在最后想分享的一点个人经验：调优不是玄学，是一步一步用数据去逼近问题的过程。对照系统日志、mpstat、iostat、vmstat、sar 这些工具的输出，你总能找到瓶颈所在，然后有针对性地调整对应的内核参数或服务配置。RHEL 9.7 给了你很多可调的旋钮，关键是搞清楚每个旋钮是干什么的，以及它转下去会带来什么副作用。

如果你正准备部署 RHEL 9.7，希望这篇东西能帮你少走一些弯路。部署和优化本身不是一次性动作，随着业务负载变化，参数也需要持续迭代，建议把它形成一套自己的 SOP，每次变更都记录在案，后面排查问题会轻松很多。