RHEL9正式发布之后,我在实际练习和运维切换过程中最深的一个感受是:它和RHEL8、RHEL7的差异,不是简单换个版本号,而是底层的很多默认行为都变了。比如默认的iptables变成了nftables后端,OpenSSL升级到3.0之后对旧版本协议和弱加密算法的限制明显更严,NetworkManager不再默认生成ifcfg文件,甚至yum这个命令都已经彻底被dnf接管了。如果你过去习惯了“老Red Hat三板斧”,第一次上手RHEL9会有点不知所措。这篇文章就把我最近在RHEL9上反复练习过的操作整理成一套可复现的练习清单,覆盖安装、命令行、软件包、存储、安全和性能诊断这几个高频场景,适合正在从RHEL7/8向RHEL9过渡的运维,也适合刚接触企业级Linux想系统练一遍的新手。
1. 安装阶段值得反复练的三个关键决策
安装这一步看起来简单,点几下鼠标就行,但实际上很多人的RHEL9学习在安装阶段就埋下了坑。我建议你在虚拟机里至少完整安装三遍,每一遍刻意选择不同的选项,然后观察系统装完以后的行为差异。装系统不是目的,通过安装理解RHEL9的设计思路才是目的。
1.1 为什么我坚持从最小化安装开始
RHEL9的安装器里提供了很多Base Environment,比如Server with GUI、Server、Minimal Install等。我强烈建议练习时选Minimal Install,也就是最小化安装,而不是顺手勾一个带图形界面的选项。原因很简单:生产服务器上绝大多数场景都不需要GUI,多装一个桌面环境就是多一片攻击面和一大批需要维护的软件包。最小化安装出来的系统足够干净,软件包数量少,后续所有练习都建立在“需要什么就装什么”的思路上,这本身就是企业运维该有的习惯。
最小化安装完成后,系统只有大约两三百个基础软件包,连man手册都不完整,很多命令需要自己补。这时候你会被迫学习和依赖dnf去查找、安装软件,比起一开始就用带GUI的完整系统,这种“缺什么补什么”的过程反而能更快建立起对RHEL9软件包管理体系的直觉。
1.2 手工分区是理解磁盘布局的必经之路
安装时磁盘分区这一页,很多人直接选Automatic自动分区,图省事。但如果你真想练好RHEL9,我建议至少有一遍安装选择Custom手工分区。自动分区虽然方便,但它的分配策略不透明,比如/boot可能分得特别小,swap的大小也不一定符合你的预期。手工分区能让你对系统磁盘布局有完整的掌控感。
我在练习环境里常用的分区方案是这样的:/boot分1GB,格式保持XFS,特殊情况下UEFI启动还需要一个vfat格式的/boot/efi;/根分区按练习需要分60GB左右,使用XFS文件系统;swap分4GB。至于/home,如果不是有特别独立的存储需求,我不建议单独分区,因为容器和虚拟化场景下/var目录的增长往往更难以预测,把根分区留足空间,后续再通过LVM扩展,比一开始就拆死各个目录要灵活得多。
这里有一个很重要的细节:/boot不要放在LVM里。RHEL8以后虽然GRUB2已经能支持从LVM启动,但在实际维护中,/boot放在普通分区上出问题的概率更小,排查起来也更简单。数据盘、业务盘的扩展完全可以通过LVM解决,没必要把引导分区也卷进去。
1.3 语言、时区与软件包选择别看轻
安装时系统语言我建议选英语。这不是矫情,而是很多日志、错误信息、文档和脚本都是用英文写的,你在/Linux运维过程中如果处理的都是英文环境,遇到问题时直接把报错丢给搜索引擎会更容易定位。系统语言可以在装完之后通过localectl修改,但一开始就养成英文环境的工作习惯,对你后面的运维生涯帮助很大。
时区一定要选对。装完系统之后用timedatectl检查,如果时区不对,很多日志时间戳会误导你排查问题的方向。我习惯在安装时直接选Asia/Shanghai,或者装完后执行timedatectl set-timezone Asia/Shanghai来调整。还有一个容易被忽视的点:建议开启NTP时间同步,RHEL9默认使用chronyd作为时间同步服务,安装完成后确认systemctl status chronyd是正常的,否则证书验证、日志比对、集群通信都会出各种怪问题。
软件包选择这里,Minimal Install下没有太多可选的组,无所谓。装完系统后,可以用dnf group list去查看所有可用的软件包组,再按需安装。比如你想练Web服务,可以dnf group install "Web Server";想练编译环境,就dnf group install "Development Tools"。装完基础系统之后,第一个值得做的快照就是这时候:一个干净、最小化、时区正确、时间同步正常的RHEL9基础镜像,后面所有练习搞坏了都能从这个快照重生。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 命令行基础与系统状态检查的每日必练清单
RHEL9的命令行操作和之前的版本没有颠覆性变化,但因为我前面说过,它的很多底层实现换了,所以日常巡检和排障时用的命令值得重新练一遍。我不建议你背命令,而是建议你像做体检一样,每天在系统里按固定的流程走一遍,走多了就形成肌肉记忆了。
2.1 服务与开机自启:systemctl的日常用法
systemctl在RHEL7就已经是标配了,但RHEL9上systemd的版本更高,行为细节也有一些变化。最基础的几组命令你必须练到完全不用想:systemctl status sshd查看服务状态,systemctl start sshd启动服务,systemctl enable --now httpd把服务设为开机自启并立即启动。注意enable和start是两个动作,--now参数可以让你一次完成。
还有一个容易被忽略的:systemctl mask。如果你不想让某个服务被意外启动,比如某些安全基线里要求禁用某些用不到的设备服务,用mask比disable更彻底。mask会把这个服务单元链接到/dev/null,即使另一个服务依赖它,也无法启动它。我在练习环境里就遇到过,disable之后某个依赖关系还是会把服务拉起来,用mask才真正禁掉。
日常巡检时,systemctl list-unit-files --type=service --state=enabled能打印所有开机自启的服务,这个命令在排查“为什么系统启动这么慢”或者“这台机器上到底跑了什么东西”的时候非常有用。
2.2 用户、权限与sudo:做一个合格的管理员
RHEL9里用户管理的基本流程没变,但我建议你认真做一遍这个练习:创建用户、设置密码、加入sudo授权组、验证登录。具体来说,useradd opslee创建一个普通用户,passwd opslee设置密码,然后usermod -aG wheel opslee把用户加入wheel组。RHEL9默认情况下,wheel组的成员可以通过sudo执行特权命令,这个设计比直接改/etc/sudoers要干净得多。
如果需要更精细的sudo策略,在/etc/sudoers.d/目录下新建一个文件,比如/etc/sudoers.d/opslee,里面写一行:opslee ALL=(ALL) NOPASSWD: ALL。注意一定用visudo -f /etc/sudoers.d/opslee来编辑,不要直接vi,因为visudo会检查语法,万一写错了,不会导致sudo直接崩掉,避免把自己锁在管理门外。
这个练习的目的不只是“会建用户”,而是要你理解sudo授权的边界:哪个用户、在哪台主机、能以谁的身份、执行哪些命令。生产环境里最小权限原则就是靠这些粒度控制实现的。
2.3 网络配置:nmcli才是RHEL9的默认网络入口
很多老运维习惯直接编辑/etc/sysconfig/network-scripts/ifcfg-*,这一套在RHEL9里基本可以退休了。RHEL9的NetworkManager默认使用keyfile格式,配置存放在/etc/NetworkManager/system-connections/目录下。你手动写ifcfg文件不仅可能不会被正确加载,还可能和NetworkManager的管理产生冲突。正确做法是使用nmcli或nmtui。
给网卡配置静态IP的完整练习是这样的:先ip addr查看网卡名,假设叫ens160,然后执行:
bash复制nmcli con mod ens160 ipv4.method manual \
ipv4.addresses 192.168.122.50/24 \
ipv4.gateway 192.168.122.1 \
ipv4.dns "192.168.122.1"
nmcli con up ens160
这里有一个容易犯的错误:只改了IP和网关,忘了指定ipv4.method manual,结果地址没生效。改完配置之后,最好用cat /etc/NetworkManager/system-connections/ens160.nmconnection看一眼生成的文件,确认配置写进去了。每改一次网络配置,都建议开一个新的SSH会话验证,不要把自己当前连接的会话搞断,这个教训我踩过不止一次。
nmtui是一个文本图形界面,对于不熟悉nmcli参数的初学者来说,用nmtui可以更直观地完成交互式配置。但到了脚本化、批量配置阶段,你终究还是要回到nmcli,所以建议两个都练。
2.4 日志查看:journalctl的基础查询
RHEL9下查日志的主力就是journalctl。最基本的是看某个服务的日志:journalctl -u sshd,最新的日志会沉在最下面。如果想实时跟踪,加-f参数,和tail -f的体验类似。
排查问题时,我常用的几个参数是:journalctl -b只看本次开机以来的日志,journalctl -p err只看错误级别以上的日志,journalctl --since "10 minutes ago"看最近十分钟的日志。这些参数组合起来基本能覆盖日常排障的大部分场景。日志里如果看到大量无关紧要的信息,可以通过journalctl -u服务名再加优先级参数过滤,一步步缩小范围。
2.5 一次状态快照:进程、内存、磁盘与启动链路
我建议你每天都跑一遍这套命令,刻意训练自己看输出的速度:uptime看负载,free -h看内存,df -hT看磁盘和文件系统类型,ps aux --sort=-%cpu | head看最吃CPU的进程,ip -s link看网卡丢包。这些命令的输出组合在一起,就是一台服务器当前健康状态的全景图。
如果系统启动变慢,systemd-analyze blame可以直接列出每个服务启动消耗的时间,systemd-analyze critical-chain则能看出启动关键路径上哪个环节卡住了。我在一次练习中真的发现某个机器启动慢是因为一个网络挂载在等待超时,用critical-chain一眼就锁定了问题服务。这套命令对理解systemd的启动依赖非常有帮助。
3. 软件仓库配置与DNF包管理的正确姿势
RHEL9的软件包管理工具是dnf,yum这个名字虽然还能用,但本质上就是一个指向dnf的兼容命令。很多人在RHEL9上遇到的第一个挫折就是dnf install报错,提示仓库不可用。这一章的核心就是把仓库这件事彻底搞明白。
3.1 先解决订阅、仓库启用与开发者订阅
RHEL9的软件仓库默认是随订阅提供的,没有有效的订阅,dnf install会直接报错。个人学习的话,我建议申请Red Hat Developer Subscription for Individuals,这是Red Hat为个人开发者提供的免费订阅,可以用于学习、测试,甚至最多16个节点的生产环境。申请成功后,注册并启用仓库的方式如下:
bash复制subscription-manager register --username 你的账号 --auto-attach
subscription-manager repos --enable rhel-9-for-x86_64-baseos-rpms
subscription-manager repos --enable rhel-9-for-x86_64-appstream-rpms
BaseOS仓库里是操作系统核心组件,AppStream仓库里是各种应用和运行时,这两个仓库是RHEL9最基本的软件来源。注册之后,用dnf repolist确认一下仓库列表,能看到状态为enabled的仓库就说明成功了。
订阅这一步看着不难,实际练习时最常见的坑是账号密码输错、没有绑定订阅导致无仓库可用,以及注册了旧的RHEL8订阅却想装RHEL9。遇到这类问题,先dnf repolist和subscription-manager list --available看当前状态,别急着重装系统。
3.2 EPEL与CodeReady Builder的联动
EPEL(Extra Packages for Enterprise Linux)是Fedora社区维护的扩展软件仓库,里面有大量RHEL默认仓库没有的软件包。RHEL9上安装EPEL的方法和以前一样:dnf install epel-release。
但这里有一个很多人不知道的前提:EPEL 9仓库里的部分软件包依赖CodeReady Builder仓库。如果你不先启用CodeReady Builder,安装某些EPEL软件包时会遇到依赖无法满足的错误。启用命令如下:
bash复制subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpms
这个坑我遇到过很多次,尤其是装一些开发库和工具链的时候。所以建议在RHEL9上配置EPEL之前,先把CodeReady Builder打开,避免后续安装时被依赖问题打断。
3.3 dnf的高频玩法:模块流、历史与回滚
dnf最强大的几个高级功能在RHEL8时代已经引入,RHEL9里更加成熟。第一个是模块流。AppStream仓库里很多软件有多个版本流共存,比如nodejs有18、20等版本。查看和切换版本的命令是:
bash复制dnf module list nodejs
dnf module enable nodejs:18
dnf install nodejs
模块流的存在让同一条RHEL9系统上可以灵活选择软件的版本系列,比过去源里只有一个版本要方便得多。但要注意,如果你不启用特定的模块流,dnf可能默认安装仓库里标记为默认的版本,未必是你想要的版本。
第二个是dnf history。dnf history可以查看系统上所有的包安装和卸载记录,配合dnf history info 事务ID查看具体内容。如果一次升级把系统搞挂了,可以用dnf history rollback 事务ID回滚这次操作。这个功能在生产环境里相当于一个包管理层面的后悔药,建议在练习环境里专门模拟一次“装错包→回滚”的流程,把命令练熟。
第三个是dnf provides。当你跑一个命令提示command not found,但不知道是哪个软件包提供这个命令时,用dnf provides */命令名去反查。比如dnf provides */semanage能找出semanage在哪个包里。这个反查能力在RHEL9上几乎是每日必用的。
3.4 离线环境下的本地仓库搭建
RHEL9的安装介质ISO本身就可以当作本地软件源,这在无法访问外网的离线环境中非常实用。把ISO挂载到一个目录,然后创建一个repo文件指向它:
bash复制mount -o loop rhel-9.x.iso /mnt/rhel9
cat > /etc/yum.repos.d/rhel9-local.repo <<'EOF'
[local-baseos]
name=RHEL9 BaseOS Local
baseurl=file:///mnt/rhel9/BaseOS
enabled=1
gpgcheck=0
[local-appstream]
name=RHEL9 AppStream Local
baseurl=file:///mnt/rhel9/AppStream
enabled=1
gpgcheck=0
EOF
dnf repolist
如果你手头有一堆散装的rpm包,想做成一个本地仓库,就需要用到createrepo命令。RHEL9上安装方式是dnf install createrepo_c,然后createrepo /你的rpm目录,会在目录下生成repodata目录,再用类似上面的repo文件指向它就行。
注意练习环境里我通常把gpgcheck设为0,省去签名验证的麻烦,但生产环境的本地仓库一定要保留gpgcheck=1,并用合适的GPG密钥验证包签名,否则很容易在依赖链中被植入恶意软件。
4. 存储练习:从裸盘到LVM与XFS的完整链路
存储是Linux运维的核心战区,RHEL9默认文件系统是XFS,默认的卷管理方案是LVM。这一章我建议你完完整整地把“一块新盘从无到有、再到挂载使用”的流程走一遍,这是整个RHEL9练习里性价比最高的一套操作。
4.1 分区、PV、VG、LV与挂载的完整实验流程
在虚拟机里给系统加一块20GB的新磁盘,假设设备名是/dev/sdb。第一步用lsblk确认新盘已经被识别。然后开始分区:
bash复制fdisk /dev/sdb
在fdisk里输入n创建新分区,接受默认的起始和结束扇区,再输入w写盘。分区完成之后,/dev/sdb1就是我们要用的分区。如果你要用UEFI或GPT风格的分区表,也可以用gdisk或者parted,但练习阶段fdisk足够。
分区完成之后,创建物理卷、卷组和逻辑卷:
bash复制pvcreate /dev/sdb1
vgcreate vg_data /dev/sdb1
lvcreate -L 10G -n lv_data vg_data
这几条命令的含义分别是:把分区初始化为PV(物理卷)、把PV加入VG(卷组)、从VG里切一个10GB的LV(逻辑卷)。理解这个层级关系很重要,你可以把VG理解成一个硬盘资源池,LV就是从池子里切出来的一块逻辑空间,之后格式化、挂载用的都是这个LV设备。
格式化并挂载:
bash复制mkfs.xfs /dev/vg_data/lv_data
mkdir /data
mount /dev/vg_data/lv_data /data
要做到重启后依然挂载,必须写入/etc/fstab。我强烈建议用UUID而不是设备名,因为设备名在系统重启后可能发生变化。用blkid /dev/vg_data/lv_data查UUID,然后在/etc/fstab里加一行:
code复制UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults 0 0
写完fstab之后,用mount -a验证一下,如果能正常挂载且没有报错,就说明fstab配置没问题。千万不要在fstab写错之后直接重启,否则系统可能会因为挂载失败进入紧急模式。
4.2 XFS在线扩容与swap扩展的实操
RHEL9默认的XFS文件系统一大优势是支持在线扩容,不需要卸载分区就能增大。当你发现空间不够时,先扩展LV,再扩展文件系统:
bash复制lvextend -L +5G /dev/vg_data/lv_data
xfs_growfs /data
注意,xfs_growfs后面的参数是挂载点,不是设备路径。扩容过程中数据不会中断,这在生产环境里非常有用。但XFS有一个明显的短板:不能缩小。如果你想缩分区,XFS本身做不到,只能备份、重建文件系统、再恢复。所以在创建XFS分区前一定要规划好容量。
swap空间在服务器内存规划中也很重要。如果系统内存不够,需要临时增加swap,可以创建一个LV作为swap:
bash复制lvcreate -L 2G -n lv_swap vg_data
mkswap /dev/vg_data/lv_swap
swapon /dev/vg_data/lv_swap
想让它在重启后依然生效,同样需要在fstab中添加对应条目。这里的经验是,swap的LV最好放在独立的VG或者有足够空间的VG里,避免和数据卷互相挤占空间。
4.3 RHEL9存储管理的新面孔:Stratis与VDO
RHEL9还引入了对Stratis的支持,Stratis是一个更上层的本地存储管理方案,目标是让存储管理更简单。和LVM的命令行风格不同,Stratis使用更接近zfs/btrfs的逻辑:先创建pool,再从pool里创建文件系统,支持精简配置、快照等特性。
bash复制dnf install stratisd stratis-cli
systemctl enable --now stratisd
stratis pool create mypool /dev/sdb
stratis fs create mypool data1
mkdir /mnt/data1
mount /dev/stratis/mypool/data1 /mnt/data1
如果是练习,装一套Stratis玩一玩是可以的。但放到生产环境,我建议谨慎评估,因为团队是否熟悉、Red Hat支持策略、以及和其他监控工具的集成情况,都是需要考量的因素。RHEL9的存储还有一个VDO去重压缩功能,可以内联处理重复数据。不过VDO的CPU开销和压缩率波动比较大,实际落地上不如LVM+XFS来得普适。我还是建议先把LVM和XFS的基本功练扎实,再去尝试这些新东西。
5. 安全加固综合练习:SELinux、firewalld、SSH与OpenSSL
RHEL9默认的安全状态比很多发行版都要严格,这对新手来说是个挑战,但对生产环境来说其实是好事。不要一遇到权限问题就关闭SELinux,也不要嫌firewalld麻烦就关掉防火墙,这套综合练习能让你真正理解RHEL9的安全模型到底怎么工作。
5.1 SELinux:不是关掉,而是让服务跑在该有的上下文里
RHEL9的SELinux默认是Enforcing状态。练习时你很快会碰到一个经典场景:把Apache的网站根目录换到自定义路径,结果服务启动成功了,但访问页面返回403,原因就是SELinux阻止了httpd读取非默认目录。
先用getenforce确认当前SELinux状态,再用ls -Z看一下文件和目录的安全上下文。你会发现/var/www/html和自定义目录的上下文标签不一样。解决办法不是setenforce 0关掉SELinux,而是给自定义目录打上正确的上下文:
bash复制semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
restorecon -Rv /data/www
semanage命令如果找不到,说明你没装policycoreutils-python-utils工具包,dnf install policycoreutils-python-utils装一下就行。如果你需要httpd去访问网络,可能需要打开相应的布尔值:
bash复制setsebool -P httpd_can_network_connect on
SELinux的排查能力是必修课。当出现权限问题时,用ausearch -m AVC -ts recent查看被拒绝的事件,能看到具体是哪个进程、想访问哪个资源、缺了哪条规则。这套“看AVC日志、分析上下文、修改规则”的流程,比单纯关闭SELinux解决问题要专业得多。当然,练习环境里为了排查方便,可以临时setenforce 0,但生产环境关闭SELinux对合规和安全性都是重大隐患,不建议。
5.2 firewalld:临时规则、永久规则与reload的坑
RHEL9的防火墙服务还是firewalld,默认区域是public。练习时最容易踩的坑有两个:一是加了临时规则忘了加--permanent,重启后规则消失;二是改了永久规则忘了reload,当前会话里规则没生效。
bash复制firewall-cmd --add-service=http --permanent
firewall-cmd --reload
firewall-cmd --list-all
这是我的标准三步操作:加永久规则、reload让配置生效、list-all确认最终状态。如果需要放行一个自定义端口:
bash复制firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload
firewall-cmd --query-port=8080/tcp
还有一个容易漏掉的地方是zone。RHEL9默认使用public这个zone,但如果你的网卡被划分到了其他zone,前面的规则可能完全不生效。用firewall-cmd --get-active-zones查看当前网卡归属,再用firewall-cmd --zone=internal --add-service=http --permanent这种形式把规则加到具体zone,比只改默认zone更可控。
5.3 SSH加固的规范操作
SSH是Linux服务器最主要的远程管理入口,也是被扫描攻击最多的服务。RHEL9安装完成后,SSH默认配置相对宽松,练习加固流程是必须的。我的建议是在/etc/ssh/sshd_config.d/目录下新建一个独立配置文件,而不是直接改主配置文件。因为主配置升级时可能被覆盖,而drop-in目录下的文件更清晰。
在/etc/ssh/sshd_config.d/99-hardening.conf里写:
code复制PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
然后在本地生成密钥对,把公钥放到服务器的~/.ssh/authorized_keys里:
bash复制ssh-keygen -t ed25519
ssh-copy-id opslee@服务器IP
修改完之后先执行sshd -t检查语法,再systemctl restart sshd。还有一个容易被忽视的细节:如果你先关闭了密码登录,再去测试密钥登录,一旦密钥没配好,你可能就登不上服务器了。保险做法是先配好密钥登录并确认能登进去,再关闭密码认证。
5.4 OpenSSL 3.0带来的兼容性变化
RHEL9使用的OpenSSL 3.0是一个大版本升级,最直接的影响体现在默认安全级别上。OpenSSL 3.0默认的SECLEVEL=2对密钥长度、签名算法、TLS版本的要求都更高了,TLS 1.0和1.1基本被默认禁用。这意味着一些老设备、老客户端使用旧TLS协议连接你的RHEL9服务时,会直接握手失败。
我在练习中用一个自签名证书来理解这一块:
bash复制openssl req -newkey rsa:2048 -nodes -keyout server.key -x509 -days 365 -out server.crt
生成证书之后,可以配置到Nginx或Apache里跑一遍HTTPS。如果客户端报错说证书算法不安全,或者TLS版本不支持,多半就是OpenSSL 3.0的安全策略在高强度拦截。RHEL9的这个变化在等保测评、密码评估类项目里尤其需要注意,很多旧系统的兼容性就是在这里翻车的。
6. 系统监控与性能诊断入门实战
监控和排障是运维日常的重要工作,RHEL9自带的工具链完全够用,关键是要在日常练习中把这些工具跑起来,而不是等出事了才去搜命令。
6.1 journald日志持久化与磁盘空间管理
RHEL9的systemd-journald默认情况下日志写在/run/log/journal/这个内存文件系统里,这意味着重启后日志就丢了。生产环境中,重启后想查上一次启动发生的问题,没有持久化日志会非常被动。开启持久化日志很简单:
bash复制mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
开启之后,journald会把日志写入/var/log/journal/,重启不丢失。但日志长期积累会占用很多磁盘空间,所以我们要学会控制journal大小和保留时间。常见的做法是编辑/etc/systemd/journald.conf:
code复制SystemMaxUse=500M
MaxRetentionSec=2week
改完重启systemd-journald。日常查询时,journalctl --disk-usage能查看当前日志占用,journalctl --vacuum-size=200M可以清理到指定大小以下。这个组合练习能帮你避免“日志把根目录写满”的经典事故。
6.2 tuned性能调优profile的正确用法
RHEL9默认装了tuned工具,它是一种可以动态调优系统参数的守护进程。很多管理员只听过tuned,没用过,其实它非常好用。
bash复制tuned-adm active
tuned-adm recommend
tuned-adm profile latency-performance
第一行查看当前生效的profile,第二行查看系统推荐的profile,第三行切换为低延迟性能模式。RHEL9自带的profile包括throughput-performance偏向吞吐量、latency-performance偏向低延迟、balanced兼顾两者。切换之后,tuned会自动调整内核参数、磁盘调度器、CPU governor等,比手动逐个调sysctl高效得多。
实际使用中,我建议先跑tuned-adm recommend看系统推荐值,再根据业务特征选择对应profile。如果你在虚拟化环境里做数据库测试,改用latency-performance往往能明显降低抖动;如果是做大量小文件读写,throughput-performance不一定是最好的,具体还得结合glances、PCP这类工具看真实负载。
6.3 PCP与sosreport:红帽支持场景的两个利器
PCP(Performance Co-Pilot)是Red Hat官方支持的性能监控框架,它比传统top、free更进一步,可以长时间采集历史数据并做图形化展示。RHEL9上要自己装:
bash复制dnf install pcp pcp-system-tools
systemctl enable --now pmcd
装好之后,pmstat -t 5可以每5秒刷新一次系统性能摘要,pminfo可以列出采集到的所有性能指标,pmval可以看某一指标的实时数值。PCP的美妙之处在于数据是结构化存储的,方便回溯和分析,如果你要写性能分析报告,PCP的数据比简单截个top输出要专业得多。
sosreport则是配合Red Hat技术支持排查问题时的标准数据包。装好sos之后,执行sos report --batch --label myhost,它会把系统配置、日志、运行状态打包成一个tar.xz文件,放在/var/tmp/目录下。红帽工程师拿到这个包就能快速定位大部分问题。这个工具在你向官方提交工单时几乎是必不可少的,建议练习环境里跑一次,看看生成的报告里都包含哪些内容。
6.4 systemd-analyze查找启动慢的元凶
新装的RHEL9启动通常很快,但当你装的服务越来越多,启动时间会一点点变长。systemd-analyze系列命令是我排查启动慢的首选工具。
bash复制systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain
第一条命令显示内核启动时间、用户态启动时间和总时间,第二条按耗时排序列出所有服务单元,第三条显示启动关键路径上每个服务的启动顺序和耗时。如果某个服务卡了很久,你可以在critical-chain里直观看到它阻塞了后续服务的启动。这个方法特别适合新装系统之后做启动性能基线,记下当前启动时间,每装一批服务对比一次,能帮你清楚知道哪些服务是启动开销的大头。
我个人的习惯是,在完成一套练习之后,用sos report打一个完整的系统状态包,再用PCP采集一小段时间的性能数据,结合systemd-analyze的结果,给这个虚拟机写一份简单的“系统体检报告”。
