企业官网建设流程全解析

说实话，RH134学到第五章“调优系统性能”的时候，我才真正感觉到这门课从“会操作”开始往“懂系统”的方向走了。前面几章讲用户、权限、网络、存储，都是在教你“怎么把系统配置好”，到了性能调优这一章，核心变成了“怎么让系统跑得好”。这个转变挺微妙的，但也恰恰是系统管理员和只会敲命令的人之间的分水岭。

很多同学在这里只记住了几个命令，比如tuned-adm active、systemctl start tuned，但真正问到“系统性能瓶颈到底在哪”“为什么这个调优方案有效”，就说不清楚了。这篇文章我把自己学RH134性能调优这一章的完整思路、实操步骤、踩过的坑整理出来，希望能帮你把这章学透，而不是背完就忘。

1. 内容整体设计与思路拆解

RH134不是一门纯理论的课程，Red Hat在编排这章内容时，并不只是丢给你一堆调优参数，而是希望你建立一套“发现问题、定位瓶颈、选择策略、调优实施、验证效果”的闭环思路。

1.1 为什么把调优单独列一章

在RHEL系统的日常运维里，性能问题是最难凭空判断的。你说“系统慢”，慢在哪里？是CPU跑满了，还是内存换页频繁，还是磁盘I/O排队严重？没有监控数据支撑，盲目调参只会越调越乱。

Red Hat把性能调优放在RH134而不是RH124，是有讲究的。RH124主要是让初学者学会“使用系统”，RH134才开始培养“管理系统的能力”。性能调优需要你先理解系统资源之间的关系，比如CPU负载过高可能是磁盘I/O等待导致的，而磁盘慢又有可能是文件系统缓存设置不合理引起的。这种因果关系链，需要一定的基础才能学得动。

1.2 调优系统的三板斧：监控、调参、验证

我自己把这章内容归纳成三步：

• 监控：用工具看清系统现状，定位瓶颈在哪。
• 调参：通过tuned、sysctl、ulimit等机制修改系统行为。
• 验证：改完之后必须重新测量，确认效果，防止副作用。

这套思路不仅应对考试有用，放到真实生产环境也一样成立。很多老运维处理性能问题的流程也就是这三步，区别只是工具用得熟不熟、参数经验足不足。学这章时，你要带着“我是给公司服务器做调优”的心态去理解每一步，而不是单纯背命令选项。

1.3 从RH134考点看本章重点

从红帽考试的角来看，RHCSA级别的考试覆盖的是tuned管理、调优profile的选择和应用、sysctl持久化配置、ulimit限制设置，以及查看系统负载信息。这些听起来不难，但考试会在虚拟环境里模拟出“系统负载偏高”的场景，让你判断并采取措施。

所以我不建议你奔着“把所有性能工具全学会”去学，那是RHCE甚至RHCA的深度。RH134层面，掌握好tuned体系、关键监控工具的读法、常见内核参数的修改和持久化，就足够应付考试和日常工作里80%的性能需求了。

2. tuned调优体系：RHEL的调优总开关

在RHEL里，Red Hat给系统调优提供了一整套服务化的方案，就是tuned。它不是某个单一参数，而是一个可以针对不同工作负载自动调整内核参数、磁盘调度策略、CPU调速器等配置的系统服务。

2.1 tuned的架构和工作原理

tuned服务由两个核心部分组成：tuned守护进程和tuned-adm管理工具。守护进程后台运行，负责根据当前激活的profile应用系统的调优设置，tuned-adm就是你和它交互的命令行接口。

tuned_profile本质上是一个配置文件集合，放在/usr/lib/tuned/目录下，每个子目录对应一个调优方案，里面有tuned.conf定义需要调整的参数。RHEL出厂预置了很多profile，覆盖服务器、桌面、虚拟化、省电等常见场景。

为什么Red Hat要把调优做成服务而不是让你手动敲sysctl？因为手动调参是一次性的，重启就没了，而且不同场景下最优参数组合是联动变化的。tuned解决了两个痛点：一是调优配置可以持久化；二是切换场景时不需要你自己记住要改哪十几个参数，一条命令全搞定。

2.2 常用profile选型对比

每个tuned profile针对的工作负载差异很大，我这里给出一个我在学习和实战中整理的对比表：

我在实际使用中发现，很多初学者上来就想选latency-performance，觉得延迟越低越好，其实不对。如果一台普通虚拟机选了这个profile，它的省电机制会被关闭，功耗上升不说，虚拟化环境的调度可能反而增加争抢，得不偿失。选profile要看业务负载特征，不是看名字酷不酷。

2.3 tuned-adm常用命令实操

这块是考试重点，命令必须练到闭眼能敲。

查看当前系统激活的profile：

tuned-adm active

列出系统所有可用profile：

tuned-adm list

切换到指定的profile：

sudo tuned-adm profile throughput-performance

查看当前profile的建议说明：

tuned-adm recommend

这条命令很有意思，它会根据你的硬件类型自动推荐一个profile。虚拟机上跑这命令，大概率推荐virtual-guest，物理机上可能是balanced或者throughput-performance。我在实验环境里第一次跑这命令时真的被它的“智能”惊讶到了，它其实就是检测硬件特征匹配预设规则，但确实比我们人工判断更省事。

如果想让tuned服务开机自启，别忘了一步：

sudo systemctl enable --now tuned

2.4 自定义调优profile的玩法

RH134考试不会让你写配置文件，但实际工作中默认profile往往不能完全匹配业务，这时候就要自定义了。

方法很简单，在/etc/tuned/下新建一个目录作为profile名，里面建tuned.conf：

[main] include=throughput-performance [sysctl] vm.swappiness=10 net.core.somaxconn=4096 [disk] readahead=4096

include字段指定继承哪个基础profile，后面再覆盖或追加你要调的特殊参数。写完后用下面命令激活自定义profile：

sudo tuned-adm profile my_custom_profile

我踩过一次坑：自定义目录建在了/usr/lib/tuned/而不是/etc/tuned/，结果是系统升级时被覆盖了，调了一周的参数配置全部归零。记住，/usr/lib/是软件包管理的地盘，/etc/才是你改配置的地方。

3. 性能监控工具实操：先看清瓶颈再动手调参

没有监控数据支撑的调优就是耍流氓。RHEL自带了一批非常成熟的性能监控工具，学会看它们的输出，比背调优参数重要得多。

3.1 用top/uptime判断系统负载状态

uptime是最快的体检方法，一条命令就能看到过去1分钟、5分钟、15分钟的平均负载：

uptime

输出里三个负载值的含义要搞清楚：1分钟负载高、15分钟负载低，说明系统是临时冲高的；1分钟和15分钟都高，那就说明问题持续存在。判断的依据是“负载值除以CPU核心数”，比值接近1说明CPU基本满载，超过1就得引起注意了，超过2一般就明显卡顿。

top命令我更常用，它比uptime多展示实时的CPU使用率、内存、各个进程的资源占用。进入top界面按P按CPU排序，按M按内存排序，这是最基础的操作。看CPU那几行，如果%wa（I/O等待）很高，比如超过30%，那问题大概率不在CPU本身而在磁盘。

3.2 用vmstat定位CPU还是I/O瓶颈

我把vmstat称为“最被低估的调优工具”。它一条命令就能把CPU、内存、I/O的概况全列出来：

vmstat 1 5

参数含义是每1秒刷新一次，连续采集5次。重点看几个字段：

• r：运行队列长度，持续大于CPU核心数说明CPU不够。
• b：阻塞进程数，偏高说明I/O或锁等待严重。
• si/so：swap换入换出，如果长时间不为0，说明物理内存不够用了。
• us：用户态CPU占比，偏高说明应用本身在大量计算。
• wa：I/O等待占比，和b字段联动看，能确认是否为磁盘瓶颈。

我遇到过一台系统负载巨高但CPU占用率却不高的机器，当时就是靠vmstat看到了wa高达70%，顺藤摸瓜查到某块磁盘正在做大量写入操作。如果没有这个数据，我可能还在那儿分析进程日志呢。

3.3 用iostat精确分析磁盘I/O

定位到磁盘之后，需要iostat来细看哪块盘、什么IO特性：

iostat -x 1

-x参数输出扩展信息，重点看%util和await。%util接近100%说明这块盘已经很忙了，await是平均I/O响应时间，机械盘一般在十几毫秒，SSD应该是个位数毫秒。如果await很高但%util不高，可能是有大量小文件随机读写，而不是盘真的坏了。

3.4 用ss和ping排查网络层面的性能

网络性能问题用ss查连接状态、用ping看延迟和丢包，这点容易忽略。调优系统性能不只是CPU、内存、磁盘，网络队列溢出同样会引起“系统响应慢”的错觉。ss -s能快速汇总当前连接数，结合ss -lnt查看端口监听队列，连接数满了就会出现“端口服务正常但连不进去”的诡异现象。

3.5 监控工具数据解读经验

我个人的习惯是不要只看单次数据，至少连续观察几分钟形成趋势。CPU峰值1分钟和持续5分钟的处理方式完全不同。遇到问题先采集2~3轮数据再下结论，这个习惯帮我少踩了很多坑。日常顺手可以把top和vmstat的分类用法记在习惯了之后，企业中很多监控告警也是按这些指标来设阈值的。

4. 内核参数调整：动手改之前先学会持久化

监控工具看完了，确认了瓶颈，接下来就是改内核参数。RH134这一章涉及的不是高深的kernel hacking，而是通过sysctl和systemd的方式修改运行时参数。

4.1 sysctl临时生效与永久生效的区别

用下面命令可以立即查看所有参数：

sysctl -a

临时修改某个参数，直接写就好，比如：

sudo sysctl -w vm.swappiness=10

这样改完立即生效，但系统重启就回到默认值了。要永久生效，得把配置写入/etc/sysctl.d/*.conf文件：

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf

然后重新加载配置：

sudo sysctl --system

我见过不少同事临时调参完没落配置文件，结果系统一重启性能又回到老样子，问题一查就是一整天。规范化做法是：所有内核参数调整都要落到/etc/sysctl.d/的.conf文件里。

4.2 几个RH134重点的内核参数

RH134考试喜欢围绕下面几个参数出题，务必要理解它们的作用：

• vm.swappiness：控制系统使用swap的积极程度，范围0~100。值越高越倾向把内存页换出到swap，服务器一般设10左右，追求极致内存性能甚至可以设0。
• vm.dirty_ratio：脏页占可用内存的百分比阈值，达到该值时后台开始写盘。设太大会导致写盘瞬间抖一阵，设太小影响写入性能。
• net.core.somaxconn：socket监听队列上限，默认128，高并发服务一般调到4096或更高。
• kernel.pid_max：系统可用的PID上限，老系统默认32768，跑微服务或大量线程的机器经常不够用。

举个例子，我维护的一台Tomcat应用服务器，连接数经常超限导致客户端连不上，查看监听队列被占满，把net.core.somaxconn调到4096后问题明显缓解。

4.3 通过systemd管理资源限制

RH134调优章节里还有一块容易忽略的内容：用systemd控制服务的资源使用。这不只是内核参数，而是通过unit文件的资源控制字段实现的。

修改一个服务的CPU配额或内存限制，可以使用systemctl set-property命令：

sudo systemctl set-property httpd.service CPUShares=512 MemoryLimit=1G

这个命令会把配置写入/etc/systemd/system.control/下，属于持久化配置。设置完后要重启服务生效：

sudo systemctl daemon-reload sudo systemctl restart httpd

用systemd做资源限制的好处是精细、按服务隔离。比如一台机器上既跑着关键业务数据库，又跑着不太重要的批处理程序，你可以给数据库高CPUShares，给批处理服务设内存上限，防止它把内存吃光影响主业务。

4.4 nice/renice调度进程优先级

调优里还有一个简单但实用的手段：调整进程的运行优先级。nice值范围是-20到19，值越小优先级越高。

启动时就指定优先级：

nice -n -5 /usr/local/bin/myapp

对已经运行的进程调整：

sudo renice -5 -p 1234

普通用户只能调低自己进程的优先级（nice值往大变），只有root才能把优先级调高（nice值往小变）。生产环境里我给备份任务renice到19，让它默默干活不影响核心业务，效果非常直接。

5. 常见问题与排查技巧实录

学调优这章，光看文档是不行的，操作中会碰到各种意外。把我在学习和实验中最常遇到的问题整理成速查表，你以后碰到了可以直接对着查：

5.1 tuned和手动sysctl冲突的实战记录

有一次我在测试机上先激活了throughput-performance，后来又手动sysctl -w vm.swappiness=20，当时看生效了。结果第二天重启后系统自动切回了throughput-performance的默认参数，我的手动设置没了。

排查后才明白，tuned激活profile时会接管它负责的那批内核参数，手动sysctl临时改的还是会被tuned覆盖。正确做法是：如果使用了tuned，就尽量把自定义参数写进自定义profile而不是单独sysctl；如果只依赖sysctl配置，干脆停用tuned服务，避免两边打架。这也是很多企业服务器上tuned和自研脚本并存时的通用坑。

5.2 用压力测试验证调优效果

调优不是改完参数就觉得完事了，必须做前后对比验证。我在实验环境里经常用dd测试写盘性能，用stress工具制造CPU压力：

dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 conv=fdatasync

这个命令测的是实际落盘速度，调优前跑一遍记录数据，调优后再跑一遍对比。虽然dd是单线程的，不能代表所有场景，但用来验证I/O调度器和脏页参数的改变效果已经足够了。

生成CPU压力：

sudo stress --cpu 4 --timeout 120

压测期间再开另一个终端用top -d 1观察系统行为，这套方法能很直观地反映参数变化带来的影响。

5.3 内存不足时的排查顺序

调优过程中遇到无法启动服务或系统卡死，第一反应别急着重启，按部就班排查：先free -h看内存和swap用量，再vmstat 1 5看si/so是否剧烈，然后用ps aux --sort=-rss找出占内存最多的进程。最后决定动作：释放缓存是治标，调整业务参数限制是治本，加内存才是最终方案。

我自己在内存溢出上吃过亏，有一次看着内存满了直接kill了应用进程，结果它是主库，影响面很大，后续宁可先临时调大swap也不直接硬杀进程。

6. 学习建议与心得分享

把RH134的调优章节学透，关键不在于记住多少工具和参数，而在于形成“数据驱动决策”的习惯。遇到性能问题，先回答三个问题：瓶颈是哪个资源？是持续的还是瞬时的？改动后用什么指标验证？这三个问题能回答上来，调优方向就不会跑偏。

另外建议大家有条件就在自己电脑上多跑几遍tuned和sysctl的配置流程。装个虚拟机，试着在balanced和throughput-performance之间切换，用tuned-adm verify检查配置；再裸改几个内核参数，观察系统行为变化。这种亲手“折腾”出来的体感，比看十遍文档都扎实。

RH134的调优章只是一个入口，真正深入系统性能还有很大空间，比如perf、bpftrace、cgroup的进阶用法，那些是后面课程和生产的延伸。但把当前这块基础打牢，日常运维和考试已经是稳稳够用了。