GreedyAbyss1. 为什么说RockyLinux是内核调优的“正经选择”
先说结论：RockyLinux内核调优这件事，本质上不是“没事找事折腾系统”，而是在正式接手一批服务器之后，必须做的一次系统性体检和定向优化。我这些年经手过不少跑在CentOS 7、CentOS 8上的业务集群，自从上游转向CentOS Stream之后，生产环境里越来越多团队开始切RockyLinux。原因很简单：它是RHEL的社区重建版，和RHEL保持二进制兼容，稳定性、软件包生态、安全更新节奏都没掉链子，适合拿来当生产系统的底座。
内核调优的“调”字很关键。不是把参数改得越激进越好，而是根据你的业务形态——是高并发Web、消息队列、数据库、还是文件存储——把内核默认的“通用策略”改成“适配当前负载的策略”。RockyLinux默认内核是RHEL同源的企业级内核，默认参数保守稳定，适合绝大多数场景，但如果你需要支撑单机10万并发连接、或者跑高吞吐的MySQL/PostgreSQL、或者做KVM虚拟化宿主机，那默认参数一定会成为瓶颈。这篇东西就是围绕“明确场景、量化指标、逐项调优、验证回归”这条主线来展开的，适合刚接手RockyLinux服务器的新手，也适合已经在用但觉得性能总差口气的运维老手当作一份速查手册。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 调优前的摸底：别急着改参数，先搞清楚你的系统长什么样
2.1 确认当前内核版本与硬件基线
我见过太多人上来就改sysctl，改完发现系统负载反而更高了，回头一看连自己跑的内核是哪个小版本都没确认。RockyLinux 8系列默认内核是4.18那个分支，RockyLinux 9系列默认是5.14分支，这两个大版本在网络栈、调度器、文件系统层面的实现差异不小，对应的调优参数虽然大体通用，但有些细节完全不一样。所以第一步永远是执行这几个命令：
bash复制# 查看当前内核版本
uname -r
# 查看操作系统版本
cat /etc/os-release
# 查看CPU型号、核数、架构
lscpu
# 查看物理内存总量
free -h
# 查看磁盘类型（SSD还是HDD，是否NVMe）
lsblk -d -o name,rota,model
这里特别提醒一点，lscpu输出里的“NUMA节点”信息一定要看。现在的服务器动不动就是双路CPU，每个CPU有自己的内存控制器，跨NUMA访问内存的延迟比本地高不少。内核调优里有个很重要的思路就是“尽量让进程在本地NUMA节点上分配内存”，否则你调了半天内存参数，结果程序跑在Node 0的CPU上、内存却从Node 1分配，性能照样上不去。
2.2 安装必备的性能观测工具集
不装工具就调优，等于闭着眼开车。RockyLinux的官方源和EPEL源里工具很全，我习惯一上来就装一套标准的观测组合：
bash复制# 启用EPEL源
dnf install -y epel-release
# 安装性能观测与压测工具
dnf install -y sysstat htop iotop perf bpftool sysbench fio
说说每个工具的用途，纯新手可以记一下：sysstat里的sar、iostat、pidstat是看历史趋势和实时负载的主力，htop是交互式看进程CPU和内存占用，iotop看每个进程的磁盘I/O，perf是内核级性能剖析的利器，sysbench用于CPU/内存/线程压测，fio用于磁盘性能测试。
这些工具不只是调优前用，调优后的对比验证更离不开它们。我的习惯是调优前先跑一轮基准测试并把数据存档，调优后再跑同样的测试，用数据说话，而不是凭感觉觉得“好像快了一点”。这一条经验在团队协作时尤其重要——没有前后对比数据，你写的调优报告就是一张废纸。
3. 内核参数调优的核心战场：网络、内存、文件系统与CPU
3.1 网络协议栈参数：从“能用”到“能扛高并发”
网络参数是内核调优里最常被提及、也最容易抄作业抄出问题的一块。很多人一搜“Linux内核调优”就复制一整段sysctl配置，也不管自己到底是Web服务器还是数据库服务器。我建议按场景来，先理解每个参数在干什么，再决定改不改。
对于一个典型的Nginx/OpenResty前端或者API网关，首先关注连接队列和文件句柄：
bash复制# 全连接队列长度，默认128，高并发下很容易溢出
net.core.somaxconn = 65535
# 每个网络接口的接收/发送缓冲区默认值，单位字节
net.core.rmem_default = 262144
net.core.wmem_default = 262144
# 接收/发送缓冲区上限
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# 单个TCP连接的读写缓冲区范围
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
somaxconn为什么对高并发Web很重要？因为TCP三次握手完成后，连接会进入accept队列，如果队列满了，多余的连接会被内核直接丢弃，客户端表现为“连接被重置”。Nginx里listen指令的backlog参数和这个内核参数是配合使用的，你光调了Nginx的backlog、内核队列不够大，一样会丢连接。
接下来是TIME_WAIT和端口范围的问题。短连接场景下，服务端主动关闭连接会产生大量TIME_WAIT状态的连接，如果本地端口范围不够用，新连接就没端口可用了。这里有两个经典参数：
bash复制# 允许回收TIME_WAIT连接，用于新连接（注意，这个参数在新内核里有些争议）
net.ipv4.tcp_tw_reuse = 1
# 本地可用端口范围，默认32768-60999，高并发下可以扩大
net.ipv4.ip_local_port_range = 1024 65535
# TIME_WAIT最大数量
net.ipv4.tcp_max_tw_buckets = 20000
关于tcp_tw_reuse我要多说一句。这个参数在4.18和5.14内核里的行为不完全一样，它只对“客户端发起的新连接”生效，也就是出站连接可以复用TIME_WAIT状态的端口，但入站连接不受影响。如果你的业务大量依赖本机主动外连（比如调用外部API、数据库连接池），打开tcp_tw_reuse确实能缓解端口耗尽问题；但如果你跑的是纯服务端应用，这个参数帮不上什么忙。网上很多文章一刀切说“必须开”，其实不准确。
还有一个容易被忽略但影响很大的参数是net.ipv4.tcp_max_syn_backlog，它控制SYN半连接队列长度。在SYN Flood攻击或者瞬间大量并发新连接进来时，这个队列如果太小，握手就会失败：
bash复制net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_syncookies = 1
tcp_syncookies开启后，当SYN队列满时，内核会用一种无状态的方式处理新连接，避免服务被淹没。生产环境建议保持开启。
3.2 内存管理与OOM行为：别让系统在关键时刻“自杀”
内存参数里第一个要看的就是vm.swappiness。这个参数控制内核把匿名内存页换到swap的“积极性”，取值范围0到100，默认值在RockyLinux上是30。数值越大，内核越倾向把不常用的内存页换到swap；数值越小，越倾向保留在物理内存里。
对于数据库、Redis这类延迟敏感型应用，我通常建议调低：
bash复制# 降低swap使用倾向，优先使用物理内存
vm.swappiness = 10
注意，不建议直接设成0。在内核较新的版本里，vm.swappiness=0可能在某些场景下导致内存回收不够积极，反而引发OOM。设成10左右是一个安全和性能平衡的经验值。
接下来是vm.overcommit_memory，这个参数决定内核是否允许进程申请超过物理内存+swap的内存。默认值0表示“启发式判断”，内核对明显过大的申请会拒绝；值1表示“永远允许过载”，适合跑某些内存占用率波动极大的应用；值2表示“禁止超过比例的过载”，需要配合vm.overcommit_ratio使用。我生产环境一般保持默认0，除非是跑内存型数据库（比如Redis）并且你很确定自己的内存上限，否则不建议设1，搞不好一个内存泄漏的进程就把整个系统拖垮。
还有一个和数据库/Java应用密切相关的参数：
bash复制# 单进程允许映射的内存区域数量上限，默认65530，Elasticsearch等应用经常不够
vm.max_map_count = 262144
这个参数我以前踩过坑。部署Elasticsearch的时候，启动报max virtual memory areas vm.max_map_count [65530] is too low，很多人第一反应是调ulimit -v，其实正解就是调大vm.max_map_count。这是Java应用、Elasticsearch、ClickHouse这类mmap重度用户的常见需求。
最后说OOM行为。内核默认的OOM Killer会选择“得分最高”的进程杀掉，而得分跟进程占用内存量、运行时间、优先级都有关系。如果你不想让某个关键进程在内存耗尽时被杀，可以用/proc/<pid>/oom_score_adj调整，或者直接在sysctl里设置panic行为：
bash复制# 内核panic后自动重启，避免服务器“假死”等人处理
kernel.panic = 10
我给数据库服务器设这个参数的原因是，内存耗尽触发OOM后，系统可能进入一种半死不活的状态，SSH都连不上。与其让机器卡在那里等着人工干预，不如让它快速重启恢复服务，配合systemd的服务自启，业务中断时间反而更短。当然，这套策略要结合你的高可用架构来定，有负载均衡兜底的场景这么干没毛病，单机部署请三思。
3.3 文件系统与I/O调度：从HDD到NVMe的策略切换
RockyLinux默认的文件系统是XFS，这本身是一个成熟稳定的选择，没什么好黑的。文件系统层面的内核调优主要集中在两个方向：一是脏页回写策略，二是I/O调度器。
脏页回写相关的参数直接影响写入延迟和掉电丢数据风险：
bash复制# 脏页占系统内存的百分比达到该值后，后台开始回写
vm.dirty_background_ratio = 5
# 脏页占系统内存的百分比达到该值后，进程自身写入会被阻塞
vm.dirty_ratio = 30
这两个参数怎么理解？我打个比方：内核先把写入数据放在内存的“脏页”里，然后后台慢慢刷到磁盘。dirty_background_ratio是水位的低线，到了就开始后台刷，这时候进程还能继续写不阻塞；dirty_ratio是高线，到了就必须同步刷，进程写入会被卡住。对于追求低写入延迟的业务（比如小文件频繁写入），可以把两个值都调低，让回写更频繁、单次回写量更小，避免突发的长时间卡顿。但有代价：回写太频繁会增加磁盘I/O压力，SSD还好，HDD就明显吃力了。
I/O调度器这事值得单独拿出来说。早年Linux的I/O调度器主要是noop、deadline、cfq三选一，CFQ是默认。后来内核引入多队列机制后，新的调度器变成了mq-deadline、kyber、bfq，而NVMe固态硬盘和一些高性能SSD干脆选择none（也就是不调度，直接交给硬件）。
查看和修改当前I/O调度器的方法：
bash复制# 查看某个磁盘当前的调度器
cat /sys/block/nvme0n1/queue/scheduler
# 临时修改为none
echo none > /sys/block/nvme0n1/queue/scheduler
对于NVMe盘，none通常是性能最优的选择，因为NVMe本身就是高队列深度的设备，硬件自己就能把I/O调度得很好，内核再插一手反而增加延迟。SATA SSD可以用mq-deadline或kyber，HDD建议保持mq-deadline以兼顾吞吐和延迟。注意，这个修改是临时的，重启就没了，要实现持久化，需要配置udev规则或者在系统启动脚本里写入，后面我会讲。
3.4 CPU调度与内核参数：让进程待在它该待的地方
CPU这块最影响业务感知的，是进程调度器的行为方式。RockyLinux默认使用CFS（完全公平调度器），正常情况下它表现很好。但你可以在sysctl里微调一些全局行为，比如kernel.numa_balancing。
bash复制# 启用或关闭NUMA平衡，默认开启
kernel.numa_balancing = 1
NUMA balancing是内核自动把进程迁移到它正在访问的内存在同一NUMA节点上的机制。听起来很美，但某些高吞吐场景下，频繁的页面迁移和进程迁移反而带来额外开销。我实测跑Redis多实例的时候，关闭numa_balancing并手动绑核，性能波动明显变小。不过这是个“因机器而异”的参数，先在测试环境用perf bench numa跑一下再决定，别一上来就关。
另外提一个经常出现在各类调优文章里的参数：kernel.sched_autogroup_enabled。这个参数控制是否按终端会话自动分组调度，新内核默认开启。对桌面用户来说，开自动分组可以防止一个终端里的任务把系统卡死，但对服务器上的批处理任务，分组反而可能导致不同会话的进程不公平竞争CPU。我的建议是服务器上设0关闭它：
bash复制kernel.sched_autogroup_enabled = 0
4. 内核版本升级：从4.18到5.x的完整实操流程
4.1 为什么升级内核？旧核心版本解决不了的新问题
RockyLinux 8自带的4.18内核虽然稳定，但毕竟是2018年发布的老内核了。如果你要在生产环境上跑更新的硬件驱动（比如最新的网卡、GPU驱动、NVMe固件特性），或者需要用到新内核才有的网络功能（比如更完善的eBPF支持、更新的TCP拥塞控制算法BBR），那升级内核就是绕不开的路。
我举一个实际遇到的场景：在RockyLinux 8上用Intel I225/I226 2.5G网卡，4.18内核自带的igc驱动比较老，跑满速的时候偶发断流，升级到5.15以后稳定多了。这就是硬件厂商对新内核适配更积极的典型案例。另外，容器场景下，新内核的cgroup v2支持更完整，Kubernetes节点如果用的containerd，升级内核能获得更好的资源隔离表现。
4.2 通过ELRepo安装长期支持版内核并配置双启动
升级内核最省事的方式是使用ELRepo仓库。ELRepo提供两个内核包：kernel-lt（长期支持版）和kernel-ml（主线最新版）。生产环境我强烈建议选kernel-lt，比如5.4或5.15系列，而不是kernel-ml去追最新。原因很简单：长期支持版经过了厂商和社区更长时间的回归验证，坑明显少。
完整操作流程：
bash复制# 1. 导入ELRepo的GPG密钥并安装仓库
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
dnf install -y https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
# 2. 安装长期支持版内核
dnf install -y kernel-lt
# 3. 查看已安装的内核包
rpm -qa | grep kernel
安装完成后，新内核不会自动成为默认启动项。你需要确认GRUB的配置：
bash复制# 查看当前默认启动的内核条目
grubby --info=ALL | grep -E "^kernel|^index"
# 将默认内核设为最新安装的5.15版本
grubby --set-default=/boot/vmlinuz-5.15.*.el8.x86_64
# 验证默认启动项
grubby --default-kernel
这里有个我建议养成的习惯：升级内核后不要马上把旧内核删掉。保留最近两个版本的内核，万一新内核和你的某个驱动程序不兼容，重启后还能从GRUB菜单里选旧内核救回来。等新内核稳定运行两周以上，再清理旧内核释放/boot空间。
重启进入新内核后，第一件事是确认：
bash复制uname -r
然后跑一遍你业务的日常负载和压测，重点观察dmesg里有没有异常报错，比如驱动加载失败、固件缺失、某个模块版本不匹配。生产环境切内核，怎么谨慎都不为过。
4.3 自编译内核：哪些场景才值得手动来
自己编译内核在服务器场景下其实用得不多，但确实有值得动手的场景：一是需要定制内核特性集，把不需要的驱动和功能裁剪掉，减小内核体积、加快启动；二是应用特定的第三方内核补丁，比如某些实时内核补丁、数据中心专用网络栈优化补丁；三是强迫症想全程掌控内核构建过程，把优化选项开到-O3。
RockyLinux上自编译内核的流程和Ubuntu类似但细节不同：
bash复制# 1. 安装编译依赖
dnf groupinstall -y "Development Tools"
dnf install -y ncurses-devel openssl-devel elfutils-libelf-devel bc flex bison dwarves
# 2. 下载内核源码（以5.15.y最新补丁版本为例）
cd /usr/src
curl -LO https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.165.tar.xz
tar -xf linux-5.15.165.tar.xz
cd linux-5.15.165
# 3. 使用当前系统内核的配置作为起点
cp /boot/config-$(uname -r) .config
# 4. 调整配置选项（建议新选项保持默认）
make menuconfig
# 5. 编译并安装（按CPU核数并行编译）
make -j$(nproc)
make modules_install
make install
# 6. 更新GRUB
grub2-mkconfig -o /boot/grub2/grub.cfg
自编译内核最容易翻车的坑是配置系统里新增的编译选项没选，导致某个驱动或某个功能不可用，或者根本编译不过去。我的土办法是：先cp /boot/config-$(uname -r)拿现成配置当底子，跑一遍make olddefconfig让新选项自动用默认值，除非明确知道要改什么，否则不去动menuconfig里的东西。这样编译出来的内核基本能保证兼容性。
5. 配置持久化与批量节点调优：让改动真正落地
5.1 sysctl配置的正确打开方式与优先级
很多新手改内核参数喜欢直接执行sysctl -w net.core.somaxconn=65535，好一点的是修改/etc/sysctl.conf，但这两种方式都不够严谨。真正规范的做法是在/etc/sysctl.d/目录下创建独立配置文件。
原因有两个：第一，/etc/sysctl.d/里的文件按文件名排序加载，你可以用60-tuning.conf这种命名方式控制加载顺序和优先级；第二，独立文件方便追溯每一项改动是谁在什么时间加的，比一大坨sysctl.conf好维护多了。
我的标准做法：
bash复制# 1. 新建调优配置文件
vim /etc/sysctl.d/95-rocks-tuning.conf
# 2. 按分类写入参数，例如：
# Network
net.core.somaxconn = 65535
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 1024 65535
# Memory
vm.swappiness = 10
vm.max_map_count = 262144
vm.dirty_background_ratio = 5
vm.dirty_ratio = 30
# Kernel
kernel.numa_balancing = 0
# 3. 应用配置
sysctl --system
sysctl --system会按照/etc/sysctl.d/下的文件排序依次加载，最后再读/etc/sysctl.conf。这里有个隐藏的“优先级陷阱”：如果同一个参数在多个文件里出现，排序靠后的文件会覆盖靠前的文件。所以我习惯把所有自定义参数集中在一个编号靠后的文件里，避免和其他软件包安装时生成的配置冲突。
另外，某些参数（比如I/O调度器的修改）不是sysctl管理的，不能写进这个目录。那种改动要放到systemd unit文件里，或者用udev规则。我提供一个systemd单位的参考配置：
bash复制# 新建 /etc/systemd/system/io-scheduler-tuning.service
[Unit]
Description=Set IO scheduler to none for NVMe devices
After=systemd-modules-load.service
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo none > /sys/block/nvme0n1/queue/scheduler'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
# 启用服务
systemctl daemon-reload
systemctl enable --now io-scheduler-tuning.service
5.2 批量调优：几十台机器怎么一遍过
单机调优是基本功，生产中真正考验人的是多台机器的批量部署。我以前用Ansible写过一个角色来处理内核调优，整体思路分三步：模板化配置、幂等执行、结果校验。
Ansible的sysctl模块自带了持久化能力，比直接写文件优雅得多：
yaml复制- name: 应用内核参数到所有节点
ansible.posix.sysctl:
name: "{{ item.key }}"
value: "{{ item.value }}"
state: present
reload: yes
sysctl_file: /etc/sysctl.d/95-rocks-tuning.conf
loop: "{{ kernel_tuning_params | dict2items }}"
主机变量文件里维护参数清单：
yaml复制kernel_tuning_params:
net.core.somaxconn: "65535"
net.ipv4.ip_local_port_range: "1024 65535"
vm.swappiness: "10"
vm.max_map_count: "262144"
这个方案的好处是：参数清单集中在一个文件里，新机器加入集群后自动应用；Ansible会检查当前值和目标值，差异才执行修改，不会每次都重写；执行完自动reload，不用SSH到每台机器手动敲命令。
批量调整之后，千万别忘了验证。我通常会在playbook末尾加一个任务，批量检查关键参数是否生效：
bash复制ansible all -m shell -a "sysctl net.core.somaxconn vm.swappiness net.ipv4.ip_local_port_range"
输出看看每个节点的值是否一致，不一致就说明有节点没走完流程，或者配置文件被谁覆盖了。这一步虽然简单，但能省下不少排查时间。
6. 调优后的验证与常见问题排查实录
6.1 怎么用压测工具确认调优真的有效果
调优不验证等于白调。我自己的实操习惯是：调优前后各跑一轮相同的压测，然后拿数据对比。工具不需要多花哨，sysbench和fio就够用。
网络层的验证，用nginx + wrk或者ab最简单。比如模拟一个高并发短连接场景：
bash复制# 用wrk压测本地Nginx服务，1000个并发连接，持续60秒
wrk -t8 -c1000 -d60s http://127.0.0.1/index.html
调优前后对比两个核心指标：Requests/sec（每秒请求数）和Latency（延迟分布）。我实测过一台8核16G的虚拟机跑Nginx，默认配置下1000并发时请求数大概在8万左右，把somaxconn、tcp_max_syn_backlog、tcp_tw_reuse调优后能到12万左右，延迟尾部（p99）下降更明显。当然，不同硬件和业务场景数据差异很大，但趋势可以参考。
内存和CPU层面的验证，用sysbench：
bash复制# CPU基准测试
sysbench cpu --threads=16 --time=60 run
# 内存基准测试
sysbench memory --threads=16 --time=60 run
看调优前后的事件总耗时和延迟数据。
磁盘I/O的验证用fio：
bash复制# 4K随机写，队列深度32，持续60秒
fio --name=randwrite --rw=randwrite --bs=4k --iodepth=32 --size=1G --runtime=60 --numjobs=4 --group_reporting
# 4K随机读
fio --name=randread --rw=randread --bs=4k --iodepth=32 --size=1G --runtime=60 --numjobs=4 --group_reporting
重点关注IOPS和延迟。换I/O调度器前后对比，你能直观看到none调度器对NVMe盘IOPS的提升，以及对延迟毛刺（tail latency）的改善。
6.2 我踩过的几个调优“坑”和排查思路
第一个坑是改了net.ipv4.tcp_tw_reuse以后，有些长连接服务出现奇怪的断连。排查了半天发现，这台服务器上同时跑了Nginx和Java微服务，Nginx主动断开连接产生了大量TIME_WAIT，而Java服务作为客户端复用了这些端口去连下游系统，碰到对端刚关了旧连接还没完全释放的情况，握手就失败了。解决方案是把不同的服务拆到独立主机上，或者用iptables/ipvs做连接隔离，而不是一味依赖tcp_tw_reuse。
第二个坑是vm.max_map_count调大后，Java进程反而OOM了。原因是这个参数只增加了进程可映射的内存区域数量，并没有给进程增加实际内存配额，如果JVM堆本身就超出了物理内存，照样会死。排查时要结合dmesg里的OOM日志和/var/log/messages一起看，别只盯一个参数。
第三个坑和内核升级有关。有一次我在一台跑着旧版NVIDIA GPU驱动的机器上升级内核，重启后GPU驱动加载失败，应用直接起不来。后来才想起NVIDIA的驱动模块是预编译的，内核升级后必须重新编译安装对应版本的驱动。所以升级内核之前，一定要先确认有没有第三方预编译内核模块（GPU驱动、网卡厂商驱动、安全软件内核模块等），有的话要先去厂商官网找兼容新内核的驱动版本。
第四个容易踩的坑是sysctl配置不生效。检查顺序是这样的：先sysctl <参数名>看当前值，再cat /etc/sysctl.d/*.conf确认配置文件和内容都存在，最后确认你的配置文件名排序不是被其他文件覆盖了。有些云平台的初始化脚本会在启动时重写/etc/sysctl.conf，你需要确认自己的配置加载顺序是否在它的后面。
6.3 新内核启动失败的回滚策略
升级内核最怕的就是重启后系统起不来。虽然概率不高，但一旦发生，需要有预案。我们的回滚步骤非常简单：
- 在GRUB启动菜单出现时，快速选择“Advanced options for RockyLinux”进入旧内核条目。
- 系统启动后，用
grubby --set-default=<旧内核>把默认启动项改回旧内核。 - 然后用
dnf remove kernel-lt卸载新内核，或者先保留新内核包但不再作为默认启动项，等排查清楚再说。
这里有个细节：GRUB菜单的显示时间默认可能只有几秒，如果你人不在机房、是通过远程控制台重启，很容易错过选菜单的时机。我的建议是升级内核后、重启之前，先把GRUB超时时间改长一点：
bash复制# 修改 /etc/default/grub 中的 GRUB_TIMEOUT
GRUB_TIMEOUT=15
# 重新生成GRUB配置
grub2-mkconfig -o /boot/grub2/grub.cfg
等新内核稳定运行几天后，再把超时时间改回5秒或1秒。
个人在多次内核调优和升级过程中体会到一件事：这套东西看着琐碎，但每一环都是有因果关系的。你改了somaxconn，就必须确认Nginx的backlog配了多大；你升级了内核，就必须确认所有第三方模块都有对应的新版本；你做了批量调优，就必须有配套的校验机制。调优是个系统性工程，不是改几个参数就完事了。这篇手册里的命令和配置，拿过去要根据自己业务的实际情况再验证一遍，特别是生产环境，先灰度几台机器观察一两天，再推全量，永远比直接批量操作要稳妥得多。