概述
性能调优不是"把所有参数调到推荐值"，而是根据业务场景的瓶颈特征，针对性地调整相关参数。盲目套用参数可能导致性能下降甚至系统不稳定。
本文按常见业务场景组织，针对每个场景给出：
场景特征（什么样的业务属于这个场景）
调优要点（调什么、怎么调）
注意事项（什么情况下不要调）
调优前提
在调整任何参数之前，先建立性能基线：
# 安装基准测试工具dnf install -y unixbench sysbench iperf3# 建立综合性能基线unixbench ./Run# 建立 CPU/内存基线sysbench cpu runsysbench memory run# 建立 I/O 基线sysbench fileio --file-test-mode=seqwr preparesysbench fileio --file-test-mode=seqwr run# 建立网络基线iperf3 -s # 服务端iperf3 -c <服务端IP> -t 60 # 客户端
每次调优后重新测试，对比基线确认是否有效。单次调优只改一个变量，避免无法判断哪个参数起了作用。
场景一：数据库（MySQL/PostgreSQL/Redis）
场景特征
大内存占用，依赖文件系统缓存或直接 I/O
对延迟敏感，尤其是 OLTP 场景
通常是写密集型或混合读写型
NUMA 架构下跨节点访问会显著影响性能
调优要点
1. 透明大页（THP）设为 madvise
数据库的访问模式以随机访问为主，THP 的 always 模式可能导致内存碎片整理开销增大：
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
永久生效：编辑
/etc/rc.d/rc.local 添加上述命令并赋予执行权限。2. 降低 swappiness，减少 swap 倾向
数据库对延迟敏感，swap 会导致不可预期的性能抖动：
# 写入 sysctl 配置cat > /etc/sysctl.d/99-database-perf.conf << 'EOF'vm.swappiness = 5vm.dirty_ratio = 10vm.dirty_background_ratio = 3EOFsysctl -p /etc/sysctl.d/99-database-perf.conf
说明：
建议您降低
dirty_ratio 参数值，可使脏页更早触发回写，避免大量写 I/O 集中堆积，从而降低瞬时 I/O 阻塞的风险。3. NUMA 绑定（多 NUMA 节点服务器）
跨 NUMA 节点访问内存的延迟比本地访问高 50%-100%。将数据库进程绑定到单个 NUMA 节点：
dnf install -y numactl# 查看 NUMA 拓扑numactl --hardware# 将数据库进程绑定到 NUMA 节点 0numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld
4. I/O 调度器选择
数据库使用 SSD：建议
none（直接提交，减少调度开销）数据库使用 NVMe：默认
none 即可，无需调整数据库使用机械盘：建议
mq-deadlineecho none > /sys/block/sda/queue/scheduler
注意事项
如果数据库使用 O_DIRECT（绕过 page cache），dirty_ratio 调优效果有限。
NUMA 绑定后如果单个节点内存不足，反而会触发更多 swap，需确认节点内存充裕。
THP 设为 never 也是常见做法（部分数据库官方文档建议直接关闭），需根据具体数据库版本测试。
场景二：Web 服务器 / API 服务（Nginx/Tomcat/自研框架）
场景特征
高并发短连接或长连接
网络收发为主要瓶颈
对吞吐量要求高，单请求延迟可接受毫秒级
通常是多核多线程模型
调优要点
1. 增大 TCP 缓冲区和连接队列
高并发场景下，默认的 TCP 缓冲区和连接队列容易成为瓶颈：
cat > /etc/sysctl.d/99-web-perf.conf << 'EOF'# 增大 TCP 收发缓冲区上限net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216# 增大连接队列（需同时调整应用层 listen backlog）net.core.somaxconn = 65535net.ipv4.tcp_max_syn_backlog = 8192# TIME_WAIT 优化（短连接场景）net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_fin_timeout = 30EOFsysctl -p /etc/sysctl.d/99-web-perf.conf
注意：
somaxconn 需要与 Nginx/Tomcat 等应用的 listen backlog 配合，取两者较小值生效。2. 网卡中断绑核
高流量场景下网卡中断可能集中在单个 CPU 核，成为瓶颈。推荐使用
irqbalance 自动均衡：dnf install -y irqbalancesystemctl enable --now irqbalance
如需手动绑定（例如将网卡中断固定到特定核，避免影响业务核）：
# 查看网卡中断分布cat /proc/interrupts | grep eth0# 将某中断绑定到 CPU0-CPU3echo "0000000f" > /proc/irq/<IRQ号>/smp_affinity
3. CPU 频率设为
performanceWeb 服务通常 CPU 利用率较高，固定最高频率可避免频率切换延迟：
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
或使用
tuned：dnf install -y tunedtuned-adm profile throughput-performance
注意事项
tcp_tw_reuse = 1 仅对出站连接复用有效，不影响入站连接。缓冲区调大不会自动生效，应用需通过
setsockopt(SO_RCVBUF/SO_SNDBUF) 设置或依赖系统自动调整。tcp_tw_recycle 已在内核 5.12+ 移除，请勿使用（NAT 环境下会导致丢包）。场景三：高吞吐网络传输（跨地域文件同步/数据备份/大文件传输）
场景特征
单连接大文件传输，追求带宽打满。
通常跨地域，RTT 较高（20ms-200ms）。
带宽利用率是核心指标。
调优要点
1. 根据带宽时延乘积（BDP）调整 TCP 窗口
这是高延迟链路下最常见的瓶颈。计算公式：
BDP = 带宽(bps) × RTT(s)所需窗口大小 = BDP / 8
例如：1 Gbps 带宽、50ms RTT，所需窗口 = 1000000000 × 0.05 / 8 ≈ 6.25 MB
cat > /etc/sysctl.d/99-wan-perf.conf << 'EOF'# 将缓冲区上限设为 BDP 的 2 倍以上net.core.rmem_max = 67108864net.core.wmem_max = 67108864net.ipv4.tcp_rmem = 4096 87380 67108864net.ipv4.tcp_wmem = 4096 65536 67108864# 确保窗口扩展已开启（默认开启）net.ipv4.tcp_window_scaling = 1EOFsysctl -p /etc/sysctl.d/99-wan-perf.conf
2. 拥塞控制算法选择
内网/低延迟链路：cubic（默认）即可
跨地域/高延迟链路：尝试 BBR
# 查看可用算法sysctl net.ipv4.tcp_available_congestion_control# 启用 BBRsysctl -w net.core.default_qdisc=fqsysctl -w net.ipv4.tcp_congestion_control=bbr
说明：
BBR 在高延迟、有丢包的链路上效果显著。但在内网低延迟无丢包环境下，BBR 与 cubic 差异不大，且 BBR 的带宽探测可能导致内网短促的
bufferbloat，需测试后决定。注意事项
BBR 需要内核 4.9+ 支持，TencentOS Server 4 默认支持。
调整缓冲区后用
ss -ie 检查 rwnd_limited 和 sndbuf_limited 占比是否下降。详细诊断方法请参见 TCP 传输速率与性能分析。
场景四：实时/低延迟应用（金融交易/游戏/媒体流）
场景特征
对延迟极度敏感（微秒级）
对吞吐量要求不高
需要可预测的响应时间，拒绝毛刺
调优要点
1. CPU 隔离与调度优化
将业务进程独占特定 CPU 核，避免被其他进程抢占：
# 使用 tuned 的 cpu-partitioning profilednf install -y tuned-profiles-cpu-partitioning# 编辑隔离配置vi /etc/tuned/cpu-partitioning-variables.conf# 设置需要隔离的 CPU 核，如隔离 CPU 2-15isolated_cores=2-15# 启用tuned-adm profile cpu-partitioningreboot
2. 关闭 THP
THP 的内存整理会导致不可预期的延迟毛刺：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
3. CPU 频率固定
避免频率切换引入的延迟：
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
4. 检查预加载库影响
某些安全 Agent 通过
/etc/ld.so.preload 注入动态库，会在每次进程创建时引入额外开销，对 fork/exec 密集型低延迟应用影响明显：# 查看预加载配置cat /etc/ld.so.preload
说明：
如发现预加载库影响性能，建议与安全运营团队沟通评估，不要擅自移除。
注意事项
CPU 隔离后，被隔离的核不参与系统调度，需确保系统服务不会被分配到隔离核。
低延迟调优通常以牺牲吞吐量为代价，不适合高吞吐场景混用。
实时场景建议使用
chrt 或 taskset 进一步控制调度策略和亲和性。场景五：通用服务器（业务负载未明确）
如果尚未明确业务类型，或服务器承载多种混合负载，建议使用 tuned 的通用 profile：
dnf install -y tuned# 查看 tuned 推荐tuned-adm recommend# 启用推荐 profile（通常是 virtual-guest 或 throughput-performance）tuned-adm profile $(tuned-adm recommend)# 验证tuned-adm activetuned-adm verify
通用场景下，以下参数保持默认即可，不建议盲目调整：
参数 | 默认值 | 建议 |
vm.swappiness | 60 | 保持默认，除非明确需要减少 swap |
vm.dirty_ratio | 20 | 保持默认 |
net.ipv4.tcp_congestion_control | cubic | 保持默认，除非跨地域传输 |
THP | always | 保持默认，除非数据库或低延迟场景 |
磁盘 I/O 通用优化
以下与具体业务场景关联较弱，按磁盘类型选择即可：
磁盘调度器
磁盘类型 | 推荐调度器 | 原因 |
NVMe | none | NVMe 自带多队列，无需额外调度 |
SSD | none 或 mq-deadline | 随机访问快，调度开销无收益 |
机械盘 | bfq | 公平分配带宽，避免饿死 |
# 查看当前调度器cat /sys/block/sda/queue/scheduler# 临时修改echo none > /sys/block/sda/queue/scheduler# 永久配置（udev 规则）cat > /etc/udev/rules.d/60-scheduler.rules << 'EOF'# SSD/NVMe 使用 noneACTION=="add|change", KERNEL=="sd[a-z]|nvme[0-9]n[0-9]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"# 机械盘使用 bfqACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"EOF
预读优化
仅对顺序读密集型场景有效（如日志分析、大文件读取）：
# 查看当前预读（单位：512 字节扇区）blockdev --getra /dev/sda# 增大预读（顺序读场景）blockdev --setra 8192 /dev/sda
说明：随机读场景（如数据库）不要调大预读，反而会增加无用的 I/O。
性能检测工具总览
工具 | 用途 | 安装命令 |
unixbench | 综合性能基准测试 | dnf install -y unixbench |
sysbench | CPU/内存/IO/数据库压测 | dnf install -y sysbench |
iperf3 | 网络带宽测试 | dnf install -y iperf3 |
perf | CPU 性能分析（函数级） | dnf install -y perf |
fio | 存储 I/O 精细化测试 | dnf install -y fio |
lmbench | 微基准测试（延迟/带宽） | dnf install -y lmbench |
