第三世界的妖孽我是在生产环境跟Linux内核参数打了十来年交道的老运维。一说起RockyLinux内核调优，很多人的第一反应是“改一堆sysctl参数重启机器”，但真出了问题才发现，要么参数没生效，要么改完反而把业务搞崩了。这篇文章就围绕RockyLinux的内核调优，按我实际处理过的场景来写，从“要不要调”“调什么”“怎么调”到“调完怎么验证”，完整走一遍，不贴那种复制粘贴式的参数清单，而是把参数背后的原理和取舍讲清楚。
这篇内容主要面向两类人：一类是刚接手RockyLinux服务器、想搞清楚内核参数到底该不该动的运维新人；另一类是系统偶尔出现性能瓶颈、需要快速定位并调整内核参数的开发或架构师。内容不刻意绕开底层原理，但也不会一上来就堆源码，尽量用能直接落地的角度来聊。
1. 调优前的整体思路：先搞明白RockyLinux内核调优是在调什么
1.1 不是所有性能问题都要动内核
我见过太多人一遇到性能问题就冲去改内核参数，结果是典型的“不对症下药”。CPU跑满先看是不是代码循环问题，IO慢先看是不是存储类型或者文件系统挂载参数不对，网络延迟高先看链路和网卡队列，这些都比改内核参数更优先。
内核参数调优的本质，是调整操作系统的资源分配策略和限制边界。系统默认参数照顾的是“大众场景”——大多数机器、大多数应用跑默认值都没问题，甚至已经是接近最优。只有当你明确了瓶颈确实是某一类资源分配策略不合理，或者默认限制不够用时，才值得去动参数。
所以我建议所有人在调优之前，先回答三个问题：系统当前的瓶颈指标是什么？这个瓶颈是不是由内核参数直接限制导致的？调整后能否用压测或者线上数据验证效果？如果三个问题回答不清楚，先不要动，否则就是拿生产环境做实验。
1.2 为什么RockyLinux适合做内核调优的基座
RockyLinux是RHEL的社区重建版，内核基线和企业级发行版一致，而且它在RHEL体系里的生命周期很长，一个问题从发现到修复，有明确的支持路径可循。相比老CentOS时代，RockyLinux的仓库、工具链和社区活跃度都要现代得多，同时它没有把内核改得面目全非，大部分参数和RHEL保持兼容。
这一点对内核调优来说极其重要。内核调优最怕的就是“在某个发行版上改了一个参数，查文档发现语义跟其他发行版不一样”。RockyLinux因为和RHEL同源，网上能查到的RHEL调优建议、红帽知识库里的方案，绝大多数都能直接套用。内核版本稳定也带来一个好处：同样的配置文件在一批机器上的行为是可预期的，不会因为内核版本漂移导致同一个sysctl参数效果完全不同。
我的建议是：如果公司要长期维护一批服务器，就别用频繁滚动更新内核的发行版来跑核心业务。选择RockyLinux这类稳定基线系统，配合定期的小版本更新，内核调优的成果才能真正沉淀下来，而不是三个月后因为内核升级全部重来。
1.3 我的调优流程：先测量、再调整、最后验证
我在生产环境调内核参数有一套固定流程，基本没有出过大事故。第一步是给当前系统的运行状态拍快照：内核版本、sysctl全量配置、当前负载、内存水位、连接数、进程数，全部记录下来存档。第二步是把要调整的参数分好类，一次只调一个类别的参数，内存类归内存类，网络类归网络类，不要一把梭全改。
第三步是改动之后区分“可热生效”和“需要重启生效”两类参数。sysctl -w 能改的，先临时生效，观察一段时间；涉及内核启动参数的，比如透明大页、isolcpus这类，必须重启，那就安排在业务低峰窗口操作。第四步是验证：用压测工具或者观察线上指标，对比调整前后的差异。最后一步是写变更记录，哪个参数、为什么改、原来是什么值、现在是什么值、依据是什么，全部留档。
为什么流程这么严格？因为内核参数这玩意儿，改起来看似就是一行配置，但影响面是全局的，它不针对某个进程，而是作用于整机所有应用。流程的意义不是形式主义，而是让你在任何时候都能回答“这台机器为什么是这个参数”这个问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心内核参数逐个拆解：每个参数背后的原理与选型
2.1 内存与块设备参数：别一上来就关swap
内存类参数是内核调优里最常见的切入点，但也是被误解最多的。以vm.swappiness为例，它控制的是内核在内存回收时，有多倾向于把匿名页换到swap分区，取值范围是0到100。RHEL系默认是30，这个值意味着“内存压力中等时，可以开始使用swap”。
网上很多老教程会建议直接把vm.swappiness设为0，理由是“我有那么多内存，要swap干嘛”。这话一半对一半错。内核里swappiness=0的语义在近几个大版本里反复调整过，现在的行为是“尽量避免换出匿名页”，但它不等于“绝对不换出”。对于大多数业务，我更推荐设成1，既避免内核过早把进程内存页换到磁盘，又不至于让文件缓存被压缩得太狠。
再来看vm.dirty_ratio和vm.dirty_background_ratio这两个参数，它们控制的是脏页写回机制。后台写回阈值是当脏页占内存百分比达到这个值时，内核开始异步刷盘；dirty_ratio是进程需要同步等待刷盘的最大脏页比例。默认是vm.dirty_background_ratio=10、vm.dirty_ratio=20，对普通磁盘是稳的，但如果你的业务有大量顺序写，而且存储是SSD，可以稍微调大后台阈值，减少频繁刷盘带来的IO毛刺。
还有一个经常被忽略的vm.vfs_cache_pressure，默认100，代表内核倾向于回收目录项和inode缓存的速度有多快。如果你的机器内存充足，又经常访问大量小文件，可以考虑降到50左右，让文件元数据在内存里待得更久，能明显提升重复访问的响应速度。
内存类参数里还有一个容易踩坑的vm.overcommit_memory。默认值是0，也就是内核自己做启发式判断，接受大多数合理的内存申请。但在跑Redis这类应用时，fork出来的子进程要复制父进程的页表，启发式判断有可能拒绝分配内存，导致fork失败。很多Redis实例都会把这个参数设为1，表示允许overcommit。设1的代价是某些进程可能申请到超出物理内存的内存，一旦真发生内存压力，OOM Killer会介入，所以一定要配合监控来用。
2.2 网络协议栈参数：高并发场景的命门
网络类参数是Linux内核调优里最常被单独拎出来讲的一大块，因为绝大多数互联网业务都吃网络。net.core.somaxconn是一个特别典型的默认值坑，它控制的是全连接队列长度，默认只有128。如果你的Nginx配置里listen指令的backlog参数设得比128大，而内核的somaxconn没跟着改，超过内核上限的连接会被直接丢掉，表现就是客户端偶发连接失败或延迟飙升。
再看TCP连接复用相关的net.ipv4.tcp_tw_reuse。TIME_WAIT状态是TCP主动关闭方必然经历的状态，默认要等tcp_fin_timeout（一般是60秒）才能释放端口。在短连接特别多的场景下，大量TIME_WAIT连接会占满本地端口，这时候开启tcp_tw_reuse=1，允许内核把处于TIME_WAIT状态的连接用于新的TCP连接，能明显缓解端口耗尽问题。《tcp_tw_recycle这个参数在新的内核里已经被移除了，别再去网上抄那种同时开tw_reuse和tw_recycle`的旧配置了。
端口范围net.ipv4.ip_local_port_range是另一个高并发陷阱。默认值是32768 60999，也就是2万多个可用本地端口。如果你的连接模式是“对同一目标IP端口大量发起连接”，2万多个端口很容易被耗尽。把它调成1024 65535能在不引入风险的情况下多出一倍左右的端口空间。
连接跟踪方面，net.netfilter.nf_conntrack_max控制的是系统能跟踪的最大连接数。如果机器上有iptables或者firewalld在运行，新连接默认都会走conntrack表，表满了之后的新连接会被直接丢弃，日志里会出现“nf_conntrack: table full, dropping packet”之类的信息。这个参数要根据机器内存和实际并发连接数来规划，不要盲目调大，每个conntrack条目大概占用300多字节的内存，几十万条就是几十MB，还没到不可控的程度，但也要心里有数。
socket读写缓冲区net.core.rmem_max和net.core.wmem_max默认是212992字节，对大部分业务够用。如果你有大数据块传输或者高带宽场景，可以适当调大。但注意net.ipv4.tcp_rmem和net.ipv4.tcp_wmem里的“默认值”不建议乱动，那会影响所有连接的默认缓冲行为，调不好会拖垮整体吞吐。
2.3 文件句柄、进程数与共享内存：隐形成本上限
内核调优不只限于网络和内存，文件句柄和进程数限制也是业务跑到一定程度后必然会撞上的墙。fs.file-max控制的是整个系统能打开的文件句柄总数，RHEL系发行版会根据内存自动算一个值，但如果你跑的是Java服务或者文件密集型应用，经常需要手动调大。
kernel.pid_max很多人没注意过，默认值在多数机器上是32768，也就是系统最多同时存在这么多进程/线程ID。一个Java应用如果开了上百个线程池，再加上容器、监控、日志采集等一堆常驻进程，一台机器上跑到几万线程是很常见的事。调大kernel.pid_max本身没有副作用，建议那些线程密集型的机器都提前调大。
fs.aio-max-nr控制的是异步IO请求数上限，默认65536，跑数据库或者高IO应用时很容易触顶，建议调大到1048576。kernel.shmmax和kernel.shmall控制的是共享内存段大小，PostgreSQL这类依赖共享内存的数据库经常需要显式调大。
内核信号量kernel.sem也很关键，格式是SEMMSL SEMMNS SEMOPM SEMMNI四个值。它限制的是每个信号量集合的信号量数、系统总信号量数等。WebLogic、Oracle这类老牌企业级应用经常要求调大kernel.sem，否则启动就报错或者运行期并发抢锁异常。遇到这类应用报信号量相关的IPC错误，优先看这里。
NUMA相关的kernel.numa_balancing默认是开启的，内核会自动把内存页迁移到进程所在CPU的本地内存节点。在大多数场景这是好事，但在某些大内存应用、特别是对延迟极度敏感的场景下，自动迁移反而会带来性能抖动。如果你确认应用内存访问局部性很差，可以考虑关闭NUMA自动均衡，但关闭前一定要用数据说话。
2.4 透明大页与内核启动参数：什么时候必须动grubby
有相当一部分内核参数不写在sysctl里，而是内核启动参数，必须通过修改GRUB引导配置来设置。最常见的当属透明大页（Transparent Huge Pages）。
THP这个特性是内核自动把连续的小内存页合并成2MB的大页，本意是减少TLB miss。问题在于，数据库类应用和Java类应用有大量的随机内存访问，THP的内存规整过程会造成偶发的高延迟。MySQL、PostgreSQL、Elasticsearch这些应用，官方文档里都明确建议关闭THP。
关闭THP有两个层面。运行时临时关闭可以这样操作：
bash复制echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
但重启后这个设置会丢失，要想永久生效，就得改内核启动参数。在RockyLinux上用grubby命令操作最方便：
bash复制grubby --update-kernel=ALL --args="transparent_hugepage=never"
改完之后用grubby --info=ALL确认参数已经追加到了当前内核的启动项上，然后重启验证。注意只改GRUB配置文件而不执行grubby更新是不行的，RockyLinux的引导管理方式和老版本不太一样，手工改/etc/default/grub之后还要确保GRUB2配置真的被重新生成了。
类似的需要通过内核启动参数调整的场景还有：nmi_watchdog=0用来关闭NMI看门狗对高频率中断场景的干扰，isolcpus=2,3用来把指定CPU核隔离出内核调度，专门跑业务线程。这类参数改动影响面大，且依赖具体硬件和应用模型，我不建议照抄别人的配置，而是根据压测结果决定。
3. 实操过程与批量调优：从基线采集到一套配置跑全集群
3.1 采集内核参数基线
调优的第一步不是改，而是“知道自己现在在哪儿”。登录任意一台RockyLinux机器，先把内核版本和系统信息记录下来：
bash复制uname -r
cat /etc/redhat-release
然后导出一份完整的sysctl参数快照：
bash复制sysctl -a > /root/sysctl_baseline_$(date +%F).conf
这份文件就是后续所有变更的对照基准，建议直接存档到版本管理工具里，不要只存在服务器本地。线上环境有时候会有同事比你早动手改过参数，没有基线的话，根本看不出差异。
如果机器上有tuned在运行，还要把当前启用的profile记下来：
bash复制tuned-adm active
tuned会动态调整一部分内核参数，如果你同时手动改sysctl，两者可能会打架。后面我会专门讲tuned的使用，这里先留个心眼。
3.2 用/etc/sysctl.d/建立可回滚的参数配置
传统做法是把所有参数塞进/etc/sysctl.conf，但现代系统上我更推荐用/etc/sysctl.d/目录下的独立文件来管理。这个目录里的所有.conf文件会按字典序加载，同名的键，后面的文件覆盖前面的。
我的习惯是建一个/etc/sysctl.d/99-tuning.conf，把所有自定义的内核参数集中放进去。这样系统自带的配置在/etc/sysctl.d/下更靠前的文件里，不会被我的改动覆盖，而我自己的配置也不会被其他软件包生成的配置干扰。
写完配置文件后，不需要重启机器，执行下面的命令让所有配置生效：
bash复制sysctl --system
如果只想验证某个参数是否生效：
bash复制sysctl vm.swappiness
这里有一个细节要提醒：sysctl --system是顺序加载所有配置文件的，如果你在99-tuning.conf里写了一个系统中根本不存在的参数名，命令会报错，并且从报错位置往后的配置有可能不会继续加载。所以每次改完配置，一定要看命令输出有没有sysctl: cannot stat之类的错误。
3.3 场景化调优模板：Web网关、数据库、缓存三套示例
全套参数配置不能“千机一面”，不同角色的机器侧重点不一样。我按实际生产环境最常用的三个场景，分别给出可直接参考的配置模板。
第一类是Nginx/网关类机器，核心诉求是抗高并发短连接和大量TIME_WAIT：
bash复制# /etc/sysctl.d/99-gateway-tuning.conf
# 网络协议栈
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.netdev_max_backlog = 8192
# 文件句柄
fs.file-max = 1000000
# 内存
vm.swappiness = 10
注意tcp_fin_timeout不要设太低。15秒是很多生产环境验证过的折中值，再低的话会影响某些长尾连接的行为，得不偿失。
第二类是MySQL/PostgreSQL等数据库机器，核心诉求是稳定、延迟可控：
bash复制# /etc/sysctl.d/99-database-tuning.conf
# 内存与脏页回收，减少IO毛刺
vm.swappiness = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 20
vm.vfs_cache_pressure = 50
# 共享内存
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
# 信号量与异步IO
kernel.sem = 4096 2147483647 2147483646 32768
fs.aio-max-nr = 1048576
# 网络
net.core.somaxconn = 1024
net.ipv4.tcp_tw_reuse = 1
第三类是Redis等缓存类机器，核心诉求是低延迟和避免fork失败：
bash复制# /etc/sysctl.d/99-cache-tuning.conf
# 内存
vm.overcommit_memory = 1
vm.swappiness = 1
vm.max_map_count = 262144
# 网络
net.core.somaxconn = 1024
net.ipv4.tcp_tw_reuse = 1
Redis的持久化机制依赖fork，内存碎片整理也需要足够的内存映射区域，所以vm.max_map_count和vm.overcommit_memory是关键。这几套模板不是银弹，但可以作为一个合理的起点，后续根据压测结果微调。
3.4 用tuned做场景化管理：比手动改更省心
RHEL系发行版自带的一套内核调优工具tuned，经常被忽略，其实它在很多场景下比手动改配置更可靠。tuned提供了一批现成的调优profile，覆盖不同使用场景：
bash复制tuned-adm list
常见的几个profile里，throughput-performance适合追求吞吐量的通用场景，它会偏向文件系统和磁盘调度做一些激进调整；latency-performance适合数据库这类对延迟敏感的机器，它会关闭很多省电和动态调频机制；network-latency和network-throughput则针对网络场景做了专门优化。
如果内置profile不满足需求，可以在/etc/tuned/下创建自定义profile。举个例子，创建一个混合了数据库和网络优化的自定义profile：
bash复制mkdir /etc/tuned/db-network-profile
编辑/etc/tuned/db-network-profile/tuned.conf：
ini复制[main]
summary=Database with network optimized profile
include=latency-performance
[sysctl]
vm.swappiness=1
vm.dirty_background_ratio=5
vm.dirty_ratio=20
net.core.somaxconn=1024
[vm]
transparent_hugepages=never
然后启用这个profile：
bash复制tuned-adm profile db-network-profile
用tuned的另一个好处是它的参数管理是全局的，如果某个软件包或者系统服务在后面改写了内核参数，tuned会在适当时机按profile定义重新应用，避免“被覆盖后失效”的尴尬。当然，代价是tuned本身会占一点额外资源，单纯追求极简的机器可以不用它。
3.5 批量分发：ansible把参数推向全集群
手动一台台改参数只适合一两台机器，一旦上了规模就必须用批量工具。运维老本行里最常用的是Ansible。下面这个task可以很安全地把自定义内核参数配置推送到一批RockyLinux机器上：
yaml复制- name: 部署内核调优配置
hosts: all
become: true
tasks:
- name: 上传自定义内核参数配置
copy:
src: files/99-tuning.conf
dest: /etc/sysctl.d/99-tuning.conf
owner: root
group: root
mode: "0644"
- name: 加载内核参数
ansible.builtin.shell: sysctl --system
register: sysctl_result
failed_when: sysctl_result.rc != 0
- name: 验证关键参数
ansible.builtin.shell: sysctl vm.swappiness net.core.somaxconn
register: verify_result
批量操作的核心原则是“分批灰度”。先拿一台机器验证配置没问题，再推一个机房的一小组机器，观察半小时指标稳定后，再放大到全量。千万别直接整个集群一把梭。即使配置文件在开发环境验证过，线上某些机器可能跑着特殊应用、装的第三方内核模块不一样，同样的参数在不同的内核模块组合下表现可能完全不同。
4. 常见问题与排查技巧实录
4.1 参数设置了但重启后没生效
这个问题我见过太多次。最常见的原因是文件放错了地方。有人把参数写进了/etc/sysctl.conf，但系统里还有/etc/sysctl.d/下的文件后加载，把同名参数覆盖成了别的值。排查方法很简单，执行sysctl vm.swappiness看当前生效值，再对比配置文件里的值，如果不一致就说明有优先级更高的文件。
另一个原因是系统服务在启动后把参数覆盖了。比如systemd-tmpfiles、某些安全加固脚本会在启动阶段重置内核参数。遇到这种情况，要检查启动链路上有哪些服务动了对应参数。建议把调优配置放在99-tuning.conf，文件名排序靠后，可以最大化迟到加载的优势。如果还是被覆盖，就用systemd的drop-in或者开机脚本最后执行一次sysctl --system来强制兜底。
4.2 高并发下端口和连接表耗尽的排查
短连接一多，最容易踩到的坑是端口耗尽。现象是业务偶发“Connection refused”或者“Cannot assign requested address”。排查命令是：
bash复制ss -s
ss -ant | awk '{print $2}' | sort | uniq -c | sort -rn | head -20
如果大量连接堆积在TIME_WAIT状态，优先确认tcp_tw_reuse是否开启、tcp_fin_timeout是否合理。如果本地端口范围已经调到了1024 65535还是不够，那就得从业务层面减少短连接了，比如使用连接池，这是程序层的问题，内核无论如何调都救不了。
还有一种隐蔽的情况是conntrack表满。如果机器上有iptables规则，即使你没开防火墙，conntrack机制也可能在工作。出现连接无规律失败时，先看这个指标：
bash复制cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
如果count接近max，就要调大nf_conntrack_max，或者审查防火墙规则，减少不必要的连接跟踪。这里特别提醒：不要盲目把nf_conntrack_max调到一个天文数字，它占用的内存是线性的，调之前先算清楚机器剩余内存。
4.3 内存参数调完反而变卡
调整后的“变卡”往往来自两类操作。第一类是把vm.swappiness设成了0。这不是说0一定错，但在内存吃紧的机器上，完全不换页会导致内核为了挤出内存频繁扫描和回收页缓存，CPU消耗反而上去了。我碰到过把数据库服务器swappiness设成0之后，最终出现实例响应变慢的案例。后来改成1，问题就消失了。0和1只差一个刻度，语义却完全不同，这是很多老教程没讲透的地方。
第二类是把vm.dirty_ratio调得过高。假设你设成了50，意味着脏页要占到内存的50%才开始同步阻塞，中间这部分数据全部留在内存里靠后台线程慢慢刷。如果业务突然有大量写入，内存里的脏页激增，IO压力又大，最终触发同步刷盘的瞬间，系统卡顿非常明显，而且因为数据在内存滞留时间变长，宕机时的数据丢失风险也同步放大。所以调整脏页参数务必配合业务写入模型和监控，不建议在生产环境一次调太高。
4.4 关闭THP后的适配问题
关闭THP本身不是万能药。数据库类应用通常受益明显，但有些内存分配特别频繁的Java应用，在关闭THP后可能出现大页表压力，反而性能下降。所以关闭THP之前，最好先在压测环境做对比，而不是直接抄数据库文档里的建议。
另外，关闭THP之后要确认应用没有依赖HugePages。Oracle这类数据库如果配置了传统大页，它和THP是两回事。用grep Huge /proc/meminfo看大页使用情况，避免把“透明大页”和“传统大页”混为一谈。关闭THP的命令只影响透明大页，不会影响通过/dev/hugepages显式挂载的HugePages文件系统，这个要分开理解。
4.5 需要掌握的几个排查命令
内核调优之后，验证手段和调优手段同样重要。我常用的几个命令简单列一下：
free -h：快速看内存整体水位和swap使用情况，判断swappiness和dirty参数是否合理。vmstat 1：观察si、so列，如果swap in/out频繁，说明内存回收策略过于激进。sar -r -f /var/log/sa/sa$(date +%d --date=yesterday)：回看昨天的内存使用趋势，对比调优前后指标。ss -s：汇总看socket状态分布，快速定位TIME_WAIT堆积。dmesg -T | tail -50：内核日志里经常藏着关键线索，比如conntrack table full、Out of memory等。sysctl -a | grep -E 'param_name'：精确确认某个参数当前生效值。
排查问题的核心思路是：先看现象，再看日志，最后才动配置。不要一有问题就怀疑内核参数，很多时候是应用层的问题被内核参数“背锅”了。
我做内核调优这些年的体会是：调优不是越激进越好，而是越稳定越好。一套合理的参数配置，应该让系统在峰值流量到来时能平滑扛住，而不是把每项指标都逼到极限。每次变更都留档、每个参数都可解释、每个调整都能回滚，这才是生产环境内核调优该有的样子。
最后再分享一个小技巧：无论你自己建了多少个调优模板，都建议在交付新机器时跑一遍sysctl --system确认输出没有报错，然后用sysctl -a导出一份“交付基线”放到文档里。以后任何一次故障排查，这份基线都能帮你快速判断“是不是有人动过这台机器的内核参数”，省下大量无头绪的排查时间。