⭐ 推荐

VPS 性能优化完全指南 2026：从 AES-NI 到内核调优的实战手册

从重新启用 AES-NI 到内核参数、NVMe 存储优化和 TCP BBR 网络调优，附真实基准测试数据。

2026年7月13日 | 2 分钟阅读 | 238 次浏览

你的 VPS 为什么比你预期的慢

买了 4 核 8GB 的 VPS，配置单看起来不错。跑个基准测试，结果却让人失望。这种情况太常见了。

好消息是，大多数 VPS 实例都有隐藏的性能可以挖掘。坏消息是，没人主动告诉你怎么释放这些性能。

2026 年 7 月，LowEndTalk 社区成员 @forest 发布了一项技术，可以在 VPS 上重新启用被服务商屏蔽的 AES-NI 硬件加速。效果惊人：AES-128-GCM 吞吐量在 8192 字节块大小下从约 250MB/s 提升到 440MB/s 以上。这不是小幅提升，而是 75% 的加密吞吐量改进，只需要一个环境变量。

原理是 QEMU 仅通过修改 CPUID 指令来隐藏 AES-NI 支持，但 AES-NI 指令本身无法被拦截。如果宿主机硬件支持，虚拟机内的 AES-NI 指令仍会正常执行。

这个发现促使我整理了这份完整指南。涵盖 CPU 特性透传、存储 I/O 调优、内核参数、网络栈优化和基准测试工具。所有内容都在真实硬件上验证过。

第一步：检查 CPU 特性

在调优之前，先搞清楚你的 VPS 到底有什么。服务商提供的是虚拟化 CPU，你在 /proc/cpuinfo 中看到的 flags 可能不反映底层物理硬件的真实能力。

读取 CPU Flags

运行以下命令查看 VPS 暴露的指令集：

cat /proc/cpuinfo | grep flags | head -1

对性能影响最大的几个 flag：

aes — AES-NI 硬件加密加速。缺少这个 flag 意味着每次 TLS 握手和磁盘加密都走软件计算，速度差很多。
avx / avx2 — 向量扩展指令集，加速数值计算、视频编码和机器学习推理。
vmx / svm — 硬件虚拟化透传，嵌套虚拟机或硬件加速容器需要。
fma — 融合乘加指令，科学计算和部分加密操作需要。

AES-NI 缺失怎么办

不要在虚拟机内强制应用使用 AES-NI，也不要伪造 CPUID 特性位。aes flag 缺失可能表示该指令没有透传或不可用；强行启用可能触发 illegal instruction（非法指令）崩溃，或得到误导性的跑分。先向服务商确认暴露的 CPU 型号与指令集，再按正常方式测试应用。若硬件加密是刚性需求，应选择明确说明该特性的套餐，并在开通后用 lscpu 和实际应用基准测试验证。

第二步：存储 I/O 优化

存储是大多数 VPS 浪费性能的地方。配置良好的 NVMe 与默认安装之间的随机读取差距可以达到 3 到 5 倍。

NVMe vs SSD vs HDD

如果服务商提供 NVMe，一定要选。SATA SSD 大约提供 500MB/s 顺序读取和 5-10 万 IOPS。NVMe 可以达到 3000MB/s 和 50 万以上 IOPS。数据库工作负载下，IOPS 的差距比顺序吞吐量更关键。

用以下命令检查实际性能：

fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --size=1G --runtime=30 --time_based

结果低于 10000 IOPS 的"NVMe VPS"可能存在超售或 I/O 调度器配置问题。

I/O 调度器调优

检查当前调度器：

cat /sys/block/sda/queue/scheduler

切换到 noop（适合 NVMe）：

echo none > /sys/block/sda/queue/scheduler

NVMe 设备有内部调度逻辑，内核调度器只增加延迟。SATA SSD 建议用 mq-deadline。

第三步：内核与内存调优

大多数 Linux 发行版的默认 sysctl 值偏保守，优先稳定性而非吞吐量。

Swap 行为

默认 swappiness 为 60，意味着内存使用到 60% 就开始换页。对于 VPS 来说过于激进：

sysctl vm.swappiness=10

关闭透明大页（数据库场景）

Redis、PostgreSQL 等数据库在 THP 开启时容易出现延迟抖动：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

第四步：网络栈优化

启用 TCP BBR

Google 开发的拥塞控制算法，在高延迟、有丢包的链路上明显优于默认的 CUBIC：

sysctl net.core.default_qdisc=fq
sysctl net.ipv4.tcp_congestion_control=bbr

法兰克福的 VPS 服务新加坡用户时，切换 BBR 可在高负载下降低 20-40% 延迟。需要内核 4.9 以上版本。

TCP 缓冲区大小

千兆或万兆上行链路的 VPS 需要更大的 TCP 缓冲区：

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

第五步：基准测试验证

不测量就是瞎调。以下是实测有效的工具：

CPU：sysbench cpu --cpu-max-prime=20000 --threads=4 run
存储：fio 混合读写测试（70% 读 / 30% 写）
网络：iperf3 -c 目标IP -P 4 -t 30（4 路并行流）

每次调优前后都要跑一遍基准测试，记录数据对比。唯一比不调优更糟的是盲目调优且不知道有没有效果。

服务商差异

不同虚拟化技术决定了你能调什么：

KVM（Hetzner、Vultr、DigitalOcean 等）：近原生性能，本指南所有调优步骤均适用
OpenVZ / LXC：共享内核，sysctl、TCP BBR、swappiness 等参数由宿主节点控制，容器内无法修改。性能差的根因通常是超售
独服：完全硬件访问，CPU 特性透传不是问题，所有调优选项可用

合理预期

性能调优不是魔法。2 核 4GB 的 VPS 不可能因为改了 I/O 调度器就突然扛住百万请求。调优的作用是移除服务商或发行版为了兼容性而设置的人为瓶颈。

最大的收益来自把配置匹配到实际工作负载。数据库服务器和静态文件服务器的调优方向完全不同。代理服务器和计算节点的网络参数也不一样。花点时间搞清楚你的 VPS 到底在做什么，再开始改参数。

每次改动都跑基准测试，用数据说话。