TencentOS Server 性能调优概述

概述
性能调优不是"把所有参数调到推荐值"，而是根据业务场景的瓶颈特征，针对性地调整相关参数。盲目套用参数可能导致性能下降甚至系统不稳定。
本文按常见业务场景组织，针对每个场景给出：
场景特征（什么样的业务属于这个场景）
调优要点（调什么、怎么调）
效果验证（用什么工具确认调优有效）
注意事项（什么情况下不要调）
适用版本：TencentOS Server 4（内核 6.6 系列）
调优前提
在调整任何参数之前，先建立性能基线：
dnf install -y unixbench lmbench sysbench iperf3
dnf install -y tuned && systemctl enable --now tuned     # 后文各场景使用 tuned-adm 切换 profile
unixbench：综合基准，把 12 个子项加权成一个 Index 分数，适合整体评估调优前后的变化。
unixbench                                   # 标准跑法：1 份拷贝 + nproc 份拷贝
unixbench -c 1 -i 3 execl spawn shell8      # 只跑单项
unixbench --print-workdir                   # 查看结果所在目录
lmbench：微基准，单独测量系统调用、上下文切换、进程创建、内存延迟等单一操作，适合评估延迟敏感型业务。TencentOS Server 4 中需通过 lmbench <程序名> 调用。
lmbench lat_ctx -s 0 2                # 上下文切换延迟（微秒）
lmbench lat_tcp -s; lmbench lat_tcp localhost; lmbench lat_tcp -S localhost   # TCP 回环延迟（微秒）
lmbench lat_proc exec                 # 进程创建延迟（微秒）
lmbench bw_mem 1g rd                  # 内存读带宽（MB/s）
sysbench：多线程压测工具，可以按线程数施加 CPU、内存、文件 I/O 负载，并自带 OLTP 测试脚本，支持 MySQL 和 PostgreSQL（--db-driver=pgsql）。
sysbench cpu --threads=$(nproc) run
sysbench memory --memory-block-size=1M --memory-total-size=10G run
sysbench fileio --file-total-size=4G --file-test-mode=rndrw prepare
sysbench fileio --file-total-size=4G --file-test-mode=rndrw --time=60 run
sysbench fileio --file-total-size=4G cleanup
iperf3：网络带宽测试。
iperf3 -s                       # 服务端
iperf3 -c <服务端IP> -t 60      # 客户端
每次调优后重新测试，对比基线确认是否有效。单次调优只改一个变量，避免无法判断哪个参数起了作用。每组测试建议运行多次取中位数，收益小于测试本身的波动时视为无效。
场景一：数据库（MySQL/PostgreSQL/Redis）
场景特征
大内存占用，依赖文件系统缓存或直接 I/O
对延迟敏感，尤其是 OLTP 场景
通常是写密集型或混合读写型
NUMA 架构下跨节点访问会显著影响性能
调优要点
1. 透明大页（THP）设为 madvise 或 never
数据库以随机访问为主，THP 的 always 模式可能导致内存整理开销增大。TencentOS Server 4 默认已是 madvise，先确认：
cat /sys/kernel/mm/transparent_hugepage/enabled
部分数据库（如 Redis、MongoDB）官方文档建议直接设为 never。持久化方式见"调优结果持久化"一节，不建议写在 rc.local 中。
2. 降低 swappiness 和脏页阈值
cat > /etc/sysctl.d/99-database-perf.conf << 'EOF'
vm.swappiness = 5
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
EOF
sysctl -p /etc/sysctl.d/99-database-perf.conf
3. NUMA 绑定（多 NUMA 节点服务器）
进程在 NUMA 节点之间被调度时，跨节点访问内存会导致性能明显波动。将数据库进程绑定到单个 NUMA 节点：
dnf install -y numactl
numactl --hardware
numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld
如果数据库所需内存超过单个节点的容量，改为把内存交错分配到所有节点，避免单节点内存耗尽：
numactl --interleave=all /usr/sbin/mysqld
4. 使用静态大页（PostgreSQL/Oracle 等共享内存型数据库）
按数据库共享内存的大小预留大页，例如 PostgreSQL shared_buffers = 16GB，使用 2MB 大页时约需 8192 个，再留少量余量：
grep Hugepagesize /proc/meminfo
echo "vm.nr_hugepages = 8400" > /etc/sysctl.d/99-hugepages.conf
sysctl -p /etc/sysctl.d/99-hugepages.conf
grep HugePages_ /proc/meminfo           # 确认 HugePages_Total 达到预期
然后在数据库中开启大页：PostgreSQL 设置 huge_pages = on，Oracle 设置 USE_LARGE_PAGES = ONLY。
I/O 调度器：NVMe/SSD 使用 none；机械盘使用 mq-deadline。
混部时保护数据库内存、降低后台任务的 I/O 优先级
# 内存紧张时优先回收其他进程的内存，保留数据库缓存
systemctl set-property mysqld.service MemoryLow=32G
﻿
# 备份、导出等后台任务使用最低 I/O 优先级
ionice -c3 <备份命令>
效果验证
# MySQL OLTP 混合读写（脚本位于 /usr/share/sysbench/，需先创建测试库）
mysql -u<用户> -p -e "CREATE DATABASE sbtest"
sysbench oltp_read_write --mysql-user=<用户> --mysql-password=<密码> \\
    --tables=10 --table-size=100000 prepare
sysbench oltp_read_write --mysql-user=<用户> --mysql-password=<密码> \\
    --tables=10 --table-size=100000 --threads=$(nproc) --time=60 run
﻿
# Redis（redis-benchmark 随 redis 包安装）
redis-benchmark -n 100000 -c 50 -t set,get
﻿
# PostgreSQL（pgbench 由 postgresql-contrib 包提供）
pgbench -i -s 100 <数据库名>
pgbench -c $(nproc) -j $(nproc) -T 60 <数据库名>
重点关注 TPS/QPS 和 95% 延迟，NUMA 绑定后还应关注多次测试之间的波动是否变小。
注意事项
使用 O_DIRECT（绕过 page cache）的数据库，dirty_ratio 调优效果有限。
NUMA 绑定后如果单个节点内存不足，反而会触发更多 swap，需确认节点内存充裕。
静态大页预留后不能被其他进程使用，预留过多会挤占系统内存；运行时分配可能因内存碎片无法凑够，此时需重启后尽早分配。
ionice 只在 bfq、mq-deadline 调度器下生效，none 下无效。
不要设置 vm.zone_reclaim_mode = 1：开启后本节点内存不足时，内核会先回收本节点的页面缓存，而不是从其他节点分配，导致缓存频繁被清掉，对数据库通常不利。
场景二：Web 服务器 / API 服务（Nginx/Tomcat/自研框架）
场景特征
高并发短连接或长连接
网络收发为主要瓶颈
对吞吐量要求高，单请求延迟可接受毫秒级
通常是多核多线程模型
调优要点
1. 增大 TCP 缓冲区和连接队列
cat > /etc/sysctl.d/99-web-perf.conf << 'EOF'
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
EOF
sysctl -p /etc/sysctl.d/99-web-perf.conf
somaxconn 需要与 Nginx/Tomcat 的 listen backlog 配合，取两者较小值生效。
2. 文件描述符上限
系统级上限 fs.file-max 在 TencentOS Server 4 上默认已经足够大，不需要调整，需要调整的是进程级上限。systemd 管理的服务通过 unit 文件设置，/etc/security/limits.conf 对 systemd 服务不生效：
mkdir -p /etc/systemd/system/nginx.service.d
cat > /etc/systemd/system/nginx.service.d/limits.conf << 'EOF'
[Service]
LimitNOFILE=1048576
EOF
systemctl daemon-reload && systemctl restart nginx
3. 网卡中断绑核
dnf install -y irqbalance
systemctl enable --now irqbalance
需要手动绑核时（例如把中断固定到非业务核）：
systemctl stop irqbalance    # 否则 irqbalance 会覆盖手动设置
grep eth0 /proc/interrupts
echo 0-3 > /proc/irq/<IRQ号>/smp_affinity_list
4. 网卡队列与收包处理
# 增大网卡收发 ring buffer（不超过 ethtool -g 显示的最大值）
ethtool -g eth0
ethtool -G eth0 rx 4096 tx 4096
﻿
# /proc/net/softnet_stat 每行对应一个 CPU，第 2 列（十六进制）持续增长说明软中断来不及处理而丢包，此时增大收包队列
cat /proc/net/softnet_stat
sysctl -w net.core.netdev_max_backlog=16384
网卡队列数少于 CPU 数时（虚拟机常见），可开启 RPS/RFS，把收包处理分散到更多 CPU 上：
ethtool -l eth0                                              # 查看队列数
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus         # 每个 rx 队列都需设置，掩码按实际 CPU 数计算
sysctl -w net.core.rps_sock_flow_entries=32768
echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt     # rps_sock_flow_entries / 队列数
5. 出站连接较多时扩大本地端口范围（反向代理、网关、调用大量后端服务）
cat > /etc/sysctl.d/99-web-ports.conf << 'EOF'
net.ipv4.ip_local_port_range = 10000 65000
# 预留本机监听的业务端口，避免被出站连接占用（按实际端口替换）
net.ipv4.ip_local_reserved_ports = 8080,9000-9100
EOF
sysctl -p /etc/sysctl.d/99-web-ports.conf
6. 长连接保活：经过负载均衡或 NAT 的长连接，空闲超时往往短于内核默认的 2 小时，可缩短保活探测时间，及时发现失效连接：
cat > /etc/sysctl.d/99-web-keepalive.conf << 'EOF'
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
EOF
sysctl -p /etc/sysctl.d/99-web-keepalive.conf
只对设置了 SO_KEEPALIVE 的连接生效。
7. CPU 频率：tuned-adm profile throughput-performance。
效果验证
# HTTP 压测（在另一台机器上执行）
dnf install -y httpd-tools
ab -n 1000000 -c 1000 -k http://<服务端IP>/
﻿
# 单机多核吞吐（关注多拷贝 Index）
unixbench -c $(nproc) -i 3 syscall context1 pipe
注意事项
tcp_tw_reuse = 1 仅对出站连接复用有效，不影响入站连接。
缓冲区调大不会自动生效，应用需通过 setsockopt(SO_RCVBUF/SO_SNDBUF) 设置或依赖系统自动调整。
tcp_tw_recycle 已在 Linux 4.12 中移除（NAT 环境下会导致丢包），TencentOS Server 4 上不存在该参数。
不要在做转发、桥接的机器上开启网卡 LRO，会导致转发异常；GRO 保持默认开启即可。
场景三：高吞吐网络传输（跨地域文件同步/数据备份/大文件传输）
场景特征
单连接大文件传输，追求带宽打满
通常跨地域，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 = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 131072 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_window_scaling = 1
# 长连接空闲后不重新慢启动，间歇性传输时能更快恢复到满速
net.ipv4.tcp_slow_start_after_idle = 0
EOF
sysctl -p /etc/sysctl.d/99-wan-perf.conf
拥塞控制算法
内网/低延迟链路：cubic（默认）即可
跨地域/高延迟链路：尝试 BBR
cat > /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl -p /etc/sysctl.d/99-bbr.conf
sysctl net.ipv4.tcp_congestion_control       # 确认已切换为 bbr
tcp_bbr 模块默认未加载，tcp_available_congestion_control 中看不到 bbr 属正常现象，设置时内核会自动加载该模块。
BBR 在高延迟、有丢包的链路上效果显著；在内网低延迟无丢包环境下与 cubic 差异不大，需测试后决定。
2. 开启 MTU 探测（经过隧道/VPN 的链路）
链路中某段 MTU 较小且 ICMP 被过滤时，大包会被静默丢弃，表现为连接建立正常但传输卡住。开启 MTU 探测后，内核会在检测到黑洞时自动减小报文大小：
sysctl -w net.ipv4.tcp_mtu_probing=1
效果验证
iperf3 -c <对端 IP> -t 60          # 单流带宽
iperf3 -c <对端 IP> -t 60 -R       # 反向
ss -ti dst <对端 IP>               # 查看 rwnd_limited / sndbuf_limited 占比（未受限时不显示）
注意事项
调整缓冲区后 rwnd_limited 和 sndbuf_limited 占比应明显下降，否则瓶颈不在窗口。
上面的缓冲区上限是单连接的，连接数较多时所有 TCP 连接的总内存还受 net.ipv4.tcp_mem（单位为页）限制，可通过 cat /proc/net/sockstat 中 TCP 的 mem 值确认是否接近上限。
详细诊断方法请参见 TCP 传输速率与性能分析。
场景四：实时/低延迟应用（金融交易/游戏/媒体流）
场景特征
对延迟极度敏感（微秒级）
对吞吐量要求不高
需要可预测的响应时间，拒绝毛刺
调优要点
1. CPU 隔离
dnf install -y tuned-profiles-cpu-partitioning
vi /etc/tuned/cpu-partitioning-variables.conf
# isolated_cores=2-15
tuned-adm profile cpu-partitioning
reboot
cpu-partitioning 会自动设置 nohz_full、rcu_nocbs 启动参数，并让 irqbalance 不再把中断分配到隔离核上。如果不使用该 profile、手动隔离 CPU，需要自行在 /etc/sysconfig/irqbalance 中排除隔离核：
# /etc/sysconfig/irqbalance
IRQBALANCE_BANNED_CPULIST=2-15
修改后执行 systemctl restart irqbalance。
业务进程绑定到隔离核时，需要绑定所有线程（-a），否则只有主线程生效：
taskset -a -cp 2-15 <PID>
2. 业务进程与网卡在同一 NUMA 节点
cat /sys/class/net/eth0/device/numa_node        # 网卡所在节点，-1 表示无 NUMA 信息
numactl --cpunodebind=<节点> --membind=<节点> <业务命令>
网卡中断也应绑定到同一节点的 CPU 上。
3. 减小网卡中断合并
网卡默认会把多个包合并后再产生中断，以降低 CPU 占用，但会增加收包延迟。低延迟业务可以减小合并时间：
ethtool -c eth0                                  # 查看当前设置
ethtool -C eth0 adaptive-rx off rx-usecs 0
部分虚拟网卡不支持修改，以 ethtool -c 的输出为准。
关闭 THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled（持久化见“调优结果持久化”一节）。
限制 C-state、固定频率
物理机使用 latency-performance 或 network-latency profile。KVM 虚拟机内 cpuidle 驱动通常为 none，vCPU 空闲后唤醒较慢，可启用 TencentOS Server 4 内核已内置的 haltpoll（会增加宿主机侧 CPU 占用，适合独占物理核的实例）：
cat /sys/devices/system/cpu/cpuidle/current_driver     # none 表示未启用
grubby --update-kernel=ALL --args="cpuidle_haltpoll.force=1"
reboot
4. 实时调度策略
chrt -f -p 50 <PID>        # SCHED_FIFO 优先级 50
不要把 kernel.sched_rt_runtime_us 设为 -1，默认值为普通任务保留了 5% 的 CPU 时间，防止实时任务把系统卡死。
效果验证
taskset -c 2,3 lmbench lat_ctx -s 0 2      # 上下文切换延迟
lmbench lat_tcp -s; taskset -c 2 lmbench lat_tcp localhost; lmbench lat_tcp -S localhost
除平均值外，更要关注业务自身的 P99/P999 延迟是否下降。
注意事项
CPU 隔离后，被隔离的核不参与系统调度，需确保系统服务不会被分配到隔离核。
低延迟调优通常以牺牲吞吐量和功耗为代价，不适合与高吞吐场景混用。
减小中断合并会显著增加中断次数和 CPU 占用，只在延迟优先的机器上使用。
场景五：批处理/构建任务（编译、CI/CD、脚本密集型任务）
场景特征
大量短生命周期进程，fork/exec 频繁
CPU 密集，追求整体完成时间
对单次延迟不敏感
调优要点
CPU 频率：tuned-adm profile throughput-performance。
构建目录放在 tmpfs（内存充足时）
mkdir -p /build
mount -t tmpfs -o size=32G tmpfs /build
1. 控制资源分配
与在线业务混部时，降低构建任务的优先级并设置上限，避免影响在线业务：
# CPUWeight 默认 100，调低后在 CPU 争抢时让出资源；TasksMax 防止进程数失控；MemoryHigh 超过后开始限流
systemd-run --scope -p CPUWeight=20 -p TasksMax=8192 -p MemoryHigh=16G -- make -j$(nproc)
﻿
# 或使用 nice/ionice 降低 CPU 和 I/O 优先级
nice -n 10 ionice -c3 make -j$(nproc)
专用构建机上则相反，对其他服务设置 CPUQuota/CPUWeight 限制，把资源留给构建任务。
效果验证
unixbench -c 1 -c $(nproc) -i 3 execl spawn shell1 shell8
lmbench lat_proc exec
最终以实际构建/任务的总耗时为准。
注意事项
tmpfs 中的数据重启后丢失，只适合放中间产物。
场景六：虚拟化宿主机（KVM）
场景特征
宿主机上运行多台 KVM 虚拟机
关注虚拟机性能是否稳定、虚拟机之间是否互相干扰
需要在性能与部署密度之间取舍
调优要点
1. 使用宿主机 profile
tuned-adm profile virtual-host
2. vCPU 绑核并与 NUMA 节点对齐
将虚拟机的 vCPU 固定到同一 NUMA 节点的物理核上，内存也从该节点分配：
dnf install -y libvirt numactl
numactl --hardware                                       # 查看各节点的 CPU 与内存
virsh vcpupin <虚拟机> <vCPU 编号> <物理 CPU> --config
virsh emulatorpin <虚拟机> <物理 CPU 列表> --config         # QEMU 自身线程
virsh numatune <虚拟机> --mode strict --nodeset 0 --config
3. 虚拟机内存使用大页
在宿主机上预留大页（数量按虚拟机内存总量计算，方法同场景一），并在虚拟机 XML 中启用：
<memoryBacking>
  <hugepages/>
</memoryBacking>
4. 网卡使用 virtio 多队列
多 vCPU 的虚拟机，网卡使用多队列，可以让收发包分散到多个 vCPU 上处理：
<interface type='network'>
  <model type='virtio'/>
  <driver name='vhost' queues='4'/>
</interface>
虚拟机内执行 ethtool -L eth0 combined 4 启用全部队列。
5. 按需关闭 KSM
KSM 会合并多台虚拟机中相同的内存页，提高部署密度，但扫描和合并会消耗 CPU，并增加内存访问延迟。性能优先时关闭：
cat /sys/kernel/mm/ksm/run            # 0 表示未运行，无需处理
echo 2 > /sys/kernel/mm/ksm/run       # 停止 KSM 并拆分已合并的页面
拆分已合并页面后内存占用会上升，执行前确认宿主机内存充足。
效果验证
在虚拟机内运行 unixbench 或 sysbench，对比调优前后的结果；再让多台虚拟机同时压测，观察每台的结果波动是否变小。
unixbench -c 1 -c $(nproc) -i 3
sysbench cpu --threads=$(nproc) run
注意事项
vCPU 绑核后失去调度灵活性，CPU 超分配（vCPU 总数大于物理核数）的环境不适合绑核。
宿主机预留大页后，这部分内存不能再给宿主机进程使用。
场景七：通用服务器（业务负载未明确）
如果尚未明确业务类型，可以先在业务高峰期查看压力信息（PSI），判断主要瓶颈在 CPU、内存还是 I/O，再参考对应场景调优：
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
some 表示至少有一个任务因等待该资源而停顿的时间占比，full 表示所有非空闲任务同时停顿的时间占比（CPU 的 full 在系统级别恒为 0，只看 some）；avg10、avg60、avg300 分别为 10 秒、60 秒、300 秒内的平均值。哪一项持续偏高，瓶颈就在哪一类资源上。
如果服务器承载多种混合负载，建议使用 tuned 的通用 profile：
dnf install -y tuned
systemctl enable --now tuned
tuned-adm recommend
tuned-adm profile $(tuned-adm recommend)
tuned-adm active
tuned-adm verify
TencentOS Server 4 自带的 tuned profile 主要设置如下：
Profile
主要设置
适用场景
throughput-performance
governor=performance，readahead≥4096，dirty_ratio=40，swappiness=10
物理机通用高吞吐
virtual-guest
继承 throughput-performance，dirty_ratio=30，swappiness=30
虚拟机通用
latency-performance
governor=performance，限制 C-state，dirty_ratio=10，swappiness=10
低延迟
network-latency
继承 latency-performance，关闭 THP 和 NUMA 自动平衡，busy_poll=50
低延迟网络
hpc-compute
继承 latency-performance，THP=always，关闭 NUMA 自动平衡
HPC 计算
通用场景下，以下参数保持默认即可，不建议盲目调整：
参数
TencentOS Server 4 默认值
建议
vm.swappiness
60
保持默认，除非明确需要减少 swap
vm.dirty_ratio
20
保持默认
net.ipv4.tcp_congestion_control
cubic
保持默认，除非跨地域传输
THP
madvise
保持默认，除非数据库或低延迟场景需要 never
上表为内核默认值，镜像或其他软件可能已修改，调整前先用 sysctl <参数名> 确认当前值。
效果验证
unixbench          # 对比切换 profile 前后的单拷贝和多拷贝 Index
调优结果持久化
验证有效的参数统一写入一个自定义 tuned profile，避免 sysctl.d、rc.local、tuned 多处配置互相覆盖：
mkdir -p /etc/tuned/my-db
cat > /etc/tuned/my-db/tuned.conf << 'EOF'
[main]
summary=数据库业务调优
include=throughput-performance
﻿
[vm]
transparent_hugepages=never
﻿
[sysctl]
vm.swappiness=5
vm.dirty_ratio=10
vm.dirty_background_ratio=3
EOF
﻿
tuned-adm profile my-db
tuned-adm verify
include 继承的父 profile 中的同名参数会被子 profile 覆盖。
TencentOS Server 4 的 tuned 默认开启 reapply_sysctl（见 /etc/tuned/tuned-main.conf），应用 profile 后会重新加载 /etc/sysctl.d/ 中的配置，同名参数以 sysctl.d 为准。改用 tuned 管理后，应删除前面各场景写入的同名 sysctl.d 文件，避免两处配置不一致。
常见调优建议在 TencentOS Server 4 上的适用性
以下常见调优建议基于较老的内核或其他发行版，在 TencentOS Server 4（6.6 内核）上无效或有风险：
常见建议
在 TencentOS Server 4 上的情况
建议做法
通过 sysctl 调整 kernel.sched_latency_ns、kernel.sched_min_granularity_ns
5.13 起这些参数已从 sysctl 移到 debugfs，只作调试用途；6.6 内核使用 EEVDF 调度器，min_granularity 已被 base_slice_ns 取代
业务调优中不需要调整
设置 net.ipv4.tcp_tw_recycle
Linux 4.12 已移除
只使用 tcp_tw_reuse
I/O 调度器设为 noop，或使用启动参数 elevator=
blk-mq 下对应的是 none；elevator= 启动参数已无效
通过 udev 规则设置
vm.dirty_ratio=40
大内存机器上脏页堆积过多，回写时容易造成 I/O 卡顿
按场景设置
修改 /etc/pam.d/common-session 启用 pam_limits
Debian 系路径，TencentOS Server 4 的 system-auth 已启用
systemd 服务使用 LimitNOFILE
intel_idle.max_cstate=1
AMD 机器上无效
使用 tuned latency-performance
vm.panic_on_oom=1
OOM 时直接重启整机
仅在有高可用切换机制时使用
磁盘 I/O 通用优化
磁盘调度器
磁盘类型
推荐调度器
原因
NVMe
none
NVMe 自带多队列，无需额外调度
SSD
none 或 mq-deadline
随机访问快，调度开销无收益
机械盘（数据库/吞吐型）
mq-deadline
保证请求延迟上限，开销低
机械盘（多用户混合负载）
bfq
公平分配带宽，避免饿死
cat /sys/block/sda/queue/scheduler
﻿
cat > /etc/udev/rules.d/60-scheduler.rules << 'EOF'
ACTION=="add|change", KERNEL=="sd[a-z]*|nvme[0-9]*n[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
EOF
udevadm control --reload && udevadm trigger --type=devices --action=change
云服务器的 virtio 磁盘（vda、vdb 等）通常报告为机械盘（rotational 为 1），但后端多为云存储，保持默认的 none 即可，不要按机械盘处理。
预读优化
仅对顺序读密集型场景有效（如日志分析、大文件读取）：
blockdev --getra /dev/sda          # 单位：512 字节扇区
blockdev --setra 8192 /dev/sda
随机读场景（如数据库）不要调大预读，反而会增加无用的 I/O。
SSD 定期 TRIM
SSD 需要定期告知哪些块已经不再使用，以维持写入性能。建议启用定时 TRIM，而不是在挂载选项中使用 discard（每次删除文件都同步执行 TRIM，会拖慢删除和写入）：
systemctl enable --now fstrim.timer      # 默认每周执行一次
RAID 条带对齐
在软 RAID 或硬件 RAID 上创建文件系统时，按条带参数对齐，避免一次写入跨越两个条带：
# su 为条带单元大小，sw 为数据盘个数（如 RAID5 的 4+1 盘为 4）
mkfs.xfs -d su=256k,sw=4 /dev/md0
软 RAID（/dev/md*）上的 XFS 通常会自动识别条带参数，硬件 RAID 需要手动指定。
性能检测工具总览
工具
用途
安装命令
unixbench
综合性能基准测试
dnf install -y unixbench
lmbench
微基准测试（延迟/带宽）
dnf install -y lmbench
sysbench
CPU/内存/IO/数据库压测
dnf install -y sysbench
iperf3
网络带宽测试
dnf install -y iperf3
fio
存储 I/O 精细化测试
dnf install -y fio
perf
CPU 性能分析（函数级）
dnf install -y perf

常见建议	在 TencentOS Server 4 上的情况	建议做法
通过 sysctl 调整 `kernel.sched_latency_ns`、`kernel.sched_min_granularity_ns`	5.13 起这些参数已从 sysctl 移到 debugfs，只作调试用途；6.6 内核使用 EEVDF 调度器，`min_granularity` 已被 `base_slice_ns` 取代	业务调优中不需要调整
设置 `net.ipv4.tcp_tw_recycle`	Linux 4.12 已移除	只使用 `tcp_tw_reuse`
I/O 调度器设为 `noop`，或使用启动参数 `elevator=`	blk-mq 下对应的是 `none`；`elevator=` 启动参数已无效	通过 udev 规则设置
`vm.dirty_ratio=40`	大内存机器上脏页堆积过多，回写时容易造成 I/O 卡顿	按场景设置
修改 `/etc/pam.d/common-session` 启用 `pam_limits`	Debian 系路径，TencentOS Server 4 的 `system-auth` 已启用	systemd 服务使用 `LimitNOFILE`
`intel_idle.max_cstate=1`	AMD 机器上无效	使用 tuned `latency-performance`
`vm.panic_on_oom=1`	OOM 时直接重启整机	仅在有高可用切换机制时使用

Profile	主要设置	适用场景
`throughput-performance`	governor=performance，readahead≥4096，dirty_ratio=40，swappiness=10	物理机通用高吞吐
`virtual-guest`	继承 throughput-performance，dirty_ratio=30，swappiness=30	虚拟机通用
`latency-performance`	governor=performance，限制 C-state，dirty_ratio=10，swappiness=10	低延迟
`network-latency`	继承 latency-performance，关闭 THP 和 NUMA 自动平衡，busy_poll=50	低延迟网络
`hpc-compute`	继承 latency-performance，THP=always，关闭 NUMA 自动平衡	HPC 计算

参数	TencentOS Server 4 默认值	建议
`vm.swappiness`	60	保持默认，除非明确需要减少 swap
`vm.dirty_ratio`	20	保持默认
`net.ipv4.tcp_congestion_control`	cubic	保持默认，除非跨地域传输
THP	madvise	保持默认，除非数据库或低延迟场景需要 never

磁盘类型	推荐调度器	原因
NVMe	none	NVMe 自带多队列，无需额外调度
SSD	none 或 mq-deadline	随机访问快，调度开销无收益
机械盘（数据库/吞吐型）	mq-deadline	保证请求延迟上限，开销低
机械盘（多用户混合负载）	bfq	公平分配带宽，避免饿死

工具	用途	安装命令
unixbench	综合性能基准测试	`dnf install -y unixbench`
lmbench	微基准测试（延迟/带宽）	`dnf install -y lmbench`
sysbench	CPU/内存/IO/数据库压测	`dnf install -y sysbench`
iperf3	网络带宽测试	`dnf install -y iperf3`
fio	存储 I/O 精细化测试	`dnf install -y fio`
perf	CPU 性能分析（函数级）	`dnf install -y perf`

性能调优概述

本页目录：

概述

调优前提

场景一：数据库（MySQL/PostgreSQL/Redis）

场景特征

调优要点

效果验证

注意事项

场景二：Web 服务器 / API 服务（Nginx/Tomcat/自研框架）

场景特征

调优要点

效果验证

注意事项

场景三：高吞吐网络传输（跨地域文件同步/数据备份/大文件传输）

场景特征

调优要点

效果验证

注意事项

场景四：实时/低延迟应用（金融交易/游戏/媒体流）

场景特征

调优要点

效果验证

注意事项

场景五：批处理/构建任务（编译、CI/CD、脚本密集型任务）

场景特征

调优要点

效果验证

注意事项

场景六：虚拟化宿主机（KVM）

场景特征

调优要点

效果验证

注意事项

场景七：通用服务器（业务负载未明确）

效果验证

调优结果持久化

常见调优建议在 TencentOS Server 4 上的适用性

磁盘 I/O 通用优化

磁盘调度器

预读优化

SSD 定期 TRIM

RAID 条带对齐

性能检测工具总览