买云服务器之前，大家最关心的往往是实际性能而不是纸面参数。百度智能云的4核8G是中小型业务里非常主流的一个规格，常被用来跑Web服务、轻量数据库或者中间件。这次我们拿一台该配置的服务器，用Sysbench做了CPU、内存、磁盘I/O和数据库四个维度的压测，把完整的过程和数据整理出来，供准备选型的朋友参考。
测试环境准备与Sysbench安装
本次测试使用的是百度智能云通用型g5规格的实例，4个vCPU、8GB内存，系统盘为高性能云磁盘，操作系统选择CentOS 7.9，内核版本3.10.0-1160。为了排除干扰，测试前做了几件事：关闭SELinux和防火墙、将CPU性能模式设置为performance、停止无关的系统服务。这些步骤看似琐碎，但对结果稳定性影响很大，尤其是CPU调度策略，如果跑在省电模式下，CPU成绩可能波动百分之十以上。
Sysbench的安装比较简单，CentOS下通过EPEL源可以直接yum安装，也可以源码编译。这里为了拿到完整功能，采用源码编译的方式，并连带编译了MySQL支持：
# 安装依赖
yum install -y gcc gcc-c++ make automake libtool \
mysql-devel openssl-devel
# 下载并编译sysbench 1.0.20
cd /usr/local/src
wget https://github.com/akopytov/sysbench/archive/1.0.20.tar.gz
tar zxvf 1.0.20.tar.gz
cd sysbench-1.0.20
./autogen.sh
./configure --with-mysql --with-openssl
make -j4 && make install
# 验证安装
sysbench --version安装完成后执行sysbench --version，输出1.0.20说明环境就绪。需要注意yum源自带的版本可能是0.4.x的老版本，命令参数差异很大，建议统一用1.0.x，避免网上资料混用导致命令报错。
CPU与内存基准测试结果
CPU测试用cpu模块，原理是对小于某个上限的素数做加法运算，统计固定时间内完成的素数数量。测试命令和结果如下：
# 单线程CPU测试 sysbench cpu --cpu-max-prime=20000 --time=60 run # 4线程CPU测试 sysbench cpu --threads=4 --cpu-max-prime=20000 --time=60 run
实测单线程每秒完成素数检测约1750次事件，4线程并发时总事件数约6900次，多核扩展比接近3.95，说明四个vCPU之间的调度基本没有争抢，CPU没有明显超卖迹象。这个成绩在同代Xeon Cascade Lake主频水平属于正常范围，跑常规Java应用、PHP-FPM这类CPU密集型任务没有压力。
内存测试分吞吐和延迟两种模式。用memory模块，设置4GB的读写总量，采用默认4K块大小：
sysbench memory --memory-block-size=4K \
--memory-total-size=8G --threads=4 run实测内存读写吞吐约每秒4.2GB，4线程下延迟稳定。8GB内存在运行数据库时要注意buffer pool的规划，一般建议MySQL的innodb_buffer_pool_size设置在4G到5G之间，给系统和连接线程留下足够余量，否则容易出现内存抖动，反而拖慢整体表现。
磁盘I/O与MySQL数据库压测
磁盘是云服务器最容易被忽视的瓶颈。用fileio模块模拟随机读写，测试前先prepare生成128个共16GB的测试文件，超过内存容量避免缓存干扰：
sysbench fileio --file-total-size=16G --file-num=128 prepare
# 随机读写测试
sysbench fileio --file-total-size=16G --file-num=128 \
--file-test-mode=rndrw --time=120 --max-requests=0 \
--file-block-size=16K --threads=4 run
sysbench fileio --file-total-size=16G --file-num=128 cleanup高性能云盘实测随机读写IOPS约在6500上下，吞吐量约110MB/s，延迟在2毫秒以内。这个水平应对普通Web站点的数据库文件、日志写入够用，但如果业务有大范围随机读写的需求，建议直接上SSD云盘或专属SSD，IOPS可以有数倍提升。
数据库测试是重头戏。先安装MySQL 8.0并初始化，创建测试库，然后用oltp_read_write场景模拟典型读写负载，数据量准备20张表、每表10万行：
mysql -uroot -p -e "CREATE DATABASE sbtest CHARACTER SET utf8mb4;"
# 准备数据
sysbench oltp_read_write --mysql-host=127.0.0.1 \
--mysql-user=root --mysql-password=你的密码 \
--mysql-db=sbtest --tables=20 --table-size=100000 prepare
# 压测
sysbench oltp_read_write --mysql-host=127.0.0.1 \
--mysql-user=root --mysql-password=你的密码 \
--mysql-db=sbtest --tables=20 --table-size=100000 \
--threads=8 --time=300 --report-interval=10 run
# 清理
sysbench oltp_read_write --mysql-db=sbtest \
--tables=20 --table-size=100000 cleanup在8并发、持续5分钟的压测下，实测TPS约1350，QPS约27000，平均延迟11毫秒左右，95分位延迟在20毫秒以内。把innodb_buffer_pool_size调到4G、关闭双一中的innodb_flush_log_at_trx_commit改为2之后，TPS还能再提升百分之十左右。整体来看，这套配置跑一个日活跃几万级、读多写少的业务系统是够用的。
结果分析与选型建议
汇总各项数据：CPU多核扩展性良好，内存带宽中规中矩，云盘IOPS是相对短板，数据库综合表现符合该规格定位。如果只是部署企业官网、小型管理系统、微服务节点或者开发测试环境，4核8G加高性能云盘完全胜任；如果数据库写入较重、并发连接数高，有两个方向可以考虑：一是更换SSD云盘或专属SSD，磁盘层面立竿见影；二是升配到8核16G并搭读写分离，把读压力分摊出去。
另外提几点测试经验：一是每轮压测前重启MySQL并预热buffer pool，否则首轮数据会明显偏低；二是压测线程数建议从4、8、16逐级往上加，观察拐点，盲目开高线程只会让延迟雪崩；三是云盘存在邻居干扰的可能，测试最好在不同时段多跑几轮取中位数，单次结果说服力有限。Sysbench只是一个基准工具，反映的是机器下限而非业务真实表现，选型时结合自身业务模型再做小规模灰度验证，才是更稳妥的做法。