480GB SATA SSD香港服务器如何测试入门级站点常规业务读写性能？

配480GB SATA SSD的香港服务器，不能只看一次顺序读写速度来判断入门级站点是否够用。更有参考价值的做法是：先固定测试目录、系统和业务数据，再分别测4K随机读写、同步写入、顺序吞吐、I/O延迟、并发变化以及真实网页请求，最后把磁盘指标与CPU、内存、网络延迟和应用响应时间对应起来。

对常规企业展示站、轻量博客、内容管理系统或访问量不高的动态站点，低队列深度下的4K随机读写、p95/p99延迟和同步写入能力通常比“顺序读取达到多少MB/s”更能说明体验。下面的命令和数据用于建立可复现的测试方法；示例数值是解释口径的参考，不代表某台香港服务器的当前实测结果。

一、先定义要验证的业务问题

一次有效的存储测试，至少要回答以下几个问题：

1. 单个网页请求涉及的小文件、PHP文件、模板文件和数据库索引，能否在低队列深度下快速完成随机读写？
2. 多个访问请求同时到达时，磁盘延迟是否会明显上升？
3. 数据库提交、日志写入等需要确认落盘的操作，是否会拖慢业务？
4. 站点运行一段时间后，内存缓存失效、磁盘空间减少或并发增加，性能是否仍有余量？
5. 当前瓶颈到底来自SSD、CPU、内存、虚拟化资源，还是香港服务器与访问端之间的网络路径？

如果只运行一次顺序写入测试，即使得到较高的MB/s，也无法证明动态站点的数据库提交速度。同样，4K随机读写的峰值IOPS很高，也不代表高并发时的p99延迟稳定。

1. 先画出站点负载画像

可以从访问日志、应用监控或业务记录中整理出以下信息：

• 静态页面与动态页面的比例；
• 是否使用对象缓存、页面缓存或CDN；
• 数据库主要是查询还是写入；
• 峰值并发连接数；
• 峰值请求率，即每秒请求数；
• 上传、图片处理、备份等大文件操作是否与网页访问同时发生；
• 日志、数据库二进制日志和任务队列是否频繁落盘。

没有日志时，可以先设置一组小规模的对照负载，例如1、5、10、20和40个并发连接，再观察响应时间曲线。这里的并发数只是测试阶梯，不能直接当作站点容量结论。

2. 区分三种不同的“读写”

业务中常见的读写大致分为三类：

入门级站点通常以随机读写和少量同步写入为主，顺序吞吐更适合用来判断备份、批量导入或媒体文件操作。三者不能互相替代。

二、固定测试环境，避免结果失真

1. 确认业务路径确实位于目标SSD

480GB是标称容量，不等于系统中可以自由使用的容量。操作系统、文件系统、预留空间、快照和其他数据都会占用空间。先确认网站目录、数据库目录和测试目录是否在同一个挂载点：

findmnt -T /var/www
findmnt -T /var/lib/mysql
df -hT /var/www
lsblk -o NAME,SIZE,ROTA,TYPE,FSTYPE,MOUNTPOINTS

将 /var/www 和 /var/lib/mysql 替换为实际路径。如果网站文件在一个挂载点、数据库在另一个挂载点，就不能用网站目录上的测试结果代表数据库目录。

lsblk中的ROTA=0只能说明系统将设备识别为非旋转介质，不能单独证明底层一定是某种物理SSD。香港服务器使用虚拟化存储时，实际硬件、共享存储和宿主机负载可能无法从客户系统完全确认。因此，测试报告应记录系统看到的设备名称和挂载关系，不要仅凭设备名推断底层硬件。

2. 记录软件和资源状态

测试前记录操作系统、内核、文件系统、内存和CPU信息：

uname -a
cat /etc/os-release
free -h
nproc
df -hT
fio --version

同时开启资源观测。测试期间不要只看fio最后输出的IOPS，还要观察系统是否出现CPU等待、内存交换或虚拟化抢占：

iostat -xz 1
vmstat 1
pidstat -d 1

常见字段的含义如下：

• await：I/O从提交到完成的大致等待时间，包含排队时间；
• %util：设备忙碌程度，在虚拟化设备上只能作为辅助指标；
• r/s、w/s：每秒读写请求数；
• wa：CPU等待I/O的比例；
• si、so：内存交换进出量；
• st：虚拟机被宿主机抢占的时间比例，若系统提供该字段；
• rkB/s、wkB/s：实际读写吞吐量。

测试时如果st突然升高，或者多个测试轮次的await一起波动，问题可能不只在SSD本身，还可能与宿主机共享资源有关。

3. 选择安全的测试目录

不要把测试命令直接指向生产数据库文件、网站根目录下的业务文件，更不要把设备路径写成原始磁盘，例如/dev/vda。应在确认过的同一文件系统中建立专用目录：

TEST_DIR=/var/tmp/ssd-test
mkdir -p "$TEST_DIR"
findmnt -T "$TEST_DIR"
df -h "$TEST_DIR"

如果/var/tmp不在目标SSD上，应将TEST_DIR换成同一挂载点下的专用目录。测试前应确认至少有足够空间保存测试文件，并保留日常运行所需的容量。480GB盘不宜长期接近满载，实际部署时可把保留15%至20%可用空间作为内部管理线，而不是等到磁盘只剩很少空间才处理。

三、需要采集哪些指标

1. IOPS、吞吐和延迟要一起看

IOPS表示每秒完成的I/O操作次数，吞吐表示每秒传输的数据量，延迟表示单次请求等待多久。三者的关系受块大小影响：

吞吐量约等于IOPS乘以单次I/O数据量。

例如，4KiB块大小下达到10,000 IOPS：

• 每秒数据量为10,000 × 4,096字节；
• 换算后约为40.96 MB/s；
• 按二进制单位计算约为39.06 MiB/s。

所以，4K随机读写只有几十MB/s并不一定很低，因为它可能已经对应较高的IOPS。反过来，顺序读写达到500 MB/s，也不能推导出4K随机读写同样出色。

延迟至少要记录以下分位数：

• p50：一半请求低于该延迟；
• p95：95%的请求低于该延迟；
• p99：99%的请求低于该延迟；
• max：最大延迟，用于发现偶发卡顿，但不宜单独作为结论。

平均延迟容易掩盖少量慢请求。动态站点出现“多数页面很快，偶尔打开很慢”时，p99往往比平均值更有解释力。

2. 推荐的指标清单

四、用分层方法进行测试

1. 先测顺序读写，建立基础线

顺序测试主要用于了解大块I/O能力。下面以16G测试文件、每轮120秒为例，测试文件大小应根据剩余空间调整。direct=1用于尽量绕过操作系统页缓存，观察存储路径本身。

fio --name=seqwrite \
  --filename=/var/tmp/ssd-test/seqwrite.bin \
  --size=16G \
  --rw=write \
  --bs=1M \
  --ioengine=libaio \
  --iodepth=8 \
  --numjobs=1 \
  --direct=1 \
  --runtime=120 \
  --time_based=1 \
  --group_reporting=1 \
  --percentile_list=50:95:99:99.9

写入完成后再测试顺序读取：

fio --name=seqread \
  --filename=/var/tmp/ssd-test/seqwrite.bin \
  --size=16G \
  --rw=read \
  --bs=1M \
  --ioengine=libaio \
  --iodepth=8 \
  --numjobs=1 \
  --direct=1 \
  --runtime=120 \
  --time_based=1 \
  --group_reporting=1 \
  --percentile_list=50:95:99:99.9

重点记录带宽、平均延迟和p99延迟。若命令提示当前系统不支持libaio，先通过fio --enghelp确认可用的I/O引擎，再使用系统支持的引擎重新测试，不要在不同引擎的结果之间直接比较。

顺序写入一开始较高、运行数分钟后明显下降，可能与SSD内部缓存耗尽、温度升高或宿主机共享资源变化有关。应把前60秒和后60秒分开记录，而不是只保留一个平均值。

2. 测4K随机读写和混合负载

动态站点更接近以下几种模式：

• QD1：单个请求或少量请求逐个等待，最接近日常低并发访问；
• QD4：多个页面请求或后台任务同时访问；
• QD16：用于观察压力增加后的上限和延迟拐点；
• 70%读、30%写：仅作为一个示例混合比例，实际应根据日志调整。

4K随机读：

fio --name=randread_qd1 \
  --filename=/var/tmp/ssd-test/randread.bin \
  --size=16G \
  --rw=randread \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=1 \
  --numjobs=1 \
  --direct=1 \
  --runtime=180 \
  --time_based=1 \
  --group_reporting=1 \
  --percentile_list=50:95:99:99.9

把--iodepth=1依次改为4和16，观察IOPS增加的同时，p95和p99是否快速上升。高队列深度下IOPS提升，但延迟也明显增加，通常说明设备已经接近其处理能力。

4K混合读写：

fio --name=randrw_70r30w_qd1 \
  --filename=/var/tmp/ssd-test/randrw.bin \
  --size=16G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=1 \
  --numjobs=1 \
  --direct=1 \
  --runtime=180 \
  --time_based=1 \
  --group_reporting=1 \
  --percentile_list=50:95:99:99.9

这一轮同样可以用QD4和QD16复测。若业务以读为主，可改为90/10；若后台写入、订单、评论或日志较多，可提高写入比例。混合比例必须写进测试记录，否则不同测试结果没有可比性。

3. 单独测试同步写入

数据库提交和日志确认可能要求数据真正落盘。此时应用关注的不只是缓存中的写入速度，还包括同步操作的完成时间。可以使用专用测试文件进行小块同步写入：

fio --name=syncwrite \
  --filename=/var/tmp/ssd-test/syncwrite.bin \
  --size=4G \
  --rw=randwrite \
  --bs=4k \
  --ioengine=sync \
  --iodepth=1 \
  --numjobs=1 \
  --direct=0 \
  --fsync=1 \
  --runtime=60 \
  --time_based=1 \
  --group_reporting=1 \
  --percentile_list=50:95:99:99.9

这项结果不要与direct=1的随机写结果混为一谈。fsync=1每次写入后执行同步操作，能够更接近部分数据库提交行为，但实际数据库还会受到日志格式、事务大小、索引更新、锁等待和应用连接池的影响。

如果同步写入延迟较高，而普通随机写入很快，常见解释是写缓存不能掩盖真正的持久化等待。对于只读展示站，这项指标的影响可能较小；对于频繁更新数据库的站点，则应优先关注。

4. 用应用层测试验证磁盘结果

直接跑fio只能说明测试文件所在文件系统的表现，还不能证明网页端一定有同样体验。应在测试环境或业务低峰期准备三类请求：

1. 静态文件请求，用于观察缓存命中时的基础响应；
2. 动态读取请求，用于触发模板、应用代码和数据库查询；
3. 受控的读写请求，用于观察数据库提交和日志写入。

静态或只读接口可以用wrk做短时递增并发测试：

wrk -t2 -c5 -d180s --latency http://127.0.0.1/test-static
wrk -t2 -c10 -d180s --latency http://127.0.0.1/test-static
wrk -t2 -c20 -d180s --latency http://127.0.0.1/test-static

/test-static只是示例路径，应替换为不会修改业务数据的测试页面。对于动态读写接口，不要直接对生产订单、评论或用户数据发压测请求，应使用测试数据库、专用账号和可回收的数据集。测试期间同步记录：

• 请求数和实际RPS；
• 平均响应时间、p95、p99；
• HTTP错误率和超时数；
• 应用进程CPU；
• 数据库查询延迟；
• iostat中的await、读写速率和队列；
• vmstat中的内存交换和CPU等待。

如果静态页面很快、动态页面明显变慢，问题可能在数据库、应用代码或缓存命中率，而不是单纯的SSD顺序读取能力。反过来，如果请求一增加，应用CPU仍然不高，但await、p99和wa同时升高，存储等待的可能性更大。

五、如何解释一组测试结果

下面是一组用于说明记录方式的示例数据，并非当前香港服务器的实测结果：

这组数据应这样读，而不是简单地认为“42,000 IOPS就是日常性能”：

• QD1的4K读写更接近单个请求逐步访问文件和索引的情况；
• QD16虽然吞吐和IOPS更高，但p99已明显增加，说明并发压力在排队；
• 同步写入只有普通随机写入的一部分，符合持久化操作需要等待的特点；
• 1M顺序读取速度较高，只能说明大块连续读取能力，不能替代动态页面测试；
• 如果应用层20并发时p99仍稳定，而40并发时突然出现排队，应把20并发附近视为当前测试环境的性能拐点，而不是把40并发的峰值当作常规容量。

1. 用CPU和内存排除误判

结果解释应结合资源监控：

• iowait高、await高、磁盘队列变长：存储等待较明显；
• 用户态CPU接近满载、磁盘利用率不高：应用代码、压缩、脚本或CPU可能是瓶颈；
• si/so持续非零：内存不足或缓存压力正在干扰测试；
• st升高：虚拟机可能受到宿主机资源争用影响；
• 磁盘指标平稳，但网页p99升高：应检查数据库锁、应用线程池、连接池和网络，而不是立即更换SSD；
• 第一次访问较慢、后续访问很快：可能是页缓存或应用缓存命中，不能把热缓存结果当作冷启动性能。

2. 区分网络延迟和磁盘延迟

香港服务器的网页总响应时间还包含访问端到服务器的网络往返时间。可以固定同一个测试客户端，记录测试时间和网络路径，再进行应用压测。网络延迟变化会影响浏览器和HTTP客户端看到的总时间，但不会改变服务器本地fio的磁盘延迟。

因此，报告中应分别写：

• 本地文件系统的I/O延迟；
• 从固定客户端访问时的HTTP响应时间；
• 测试客户端位置、测试时间和并发数；
• 是否启用了页面缓存、对象缓存或CDN；
• 是否有其他任务同时占用磁盘。

不要把一次网络抖动造成的网页p99上升，直接归因于480GB SATA SSD。

六、判断是否适合入门级常规站点

容量判断不能只看某个峰值，而要看“业务目标下的稳定能力”。可以按以下方式建立内部门槛：

1. 先确定可接受的页面p95和p99，例如动态页面p95不超过业务设定目标；
2. 在目标并发下连续运行至少3至5分钟，跳过预热阶段；
3. 记录稳定RPS、错误率、磁盘p99、CPU、内存和网络状态；
4. 逐步增加并发，找到p99开始明显陡增的拐点；
5. 将该拐点对应的稳定RPS与实际峰值RPS比较。

可使用下面的简单估算：

余量倍数 = 可接受延迟下的最大稳定RPS ÷ 实际峰值RPS

余量倍数低于1.2时，业务增长或后台任务很容易触发排队；约1.2至1.5时需要持续监控；高于1.5只能说明当前测试条件下有相对余量，不能保证未来数据量、缓存命中率和并发不变。

对于入门级站点，通常可以优先确认以下边界：

• 目标并发下，p95和p99没有持续爬升；
• 同步写入不会让数据库请求频繁超时；
• 高峰期没有明显swap；
• CPU、I/O等待和虚拟化抢占没有同时接近上限；
• 实际可用空间仍有管理余量；
• 顺序备份任务运行时，网页请求不会出现不可接受的长尾；
• 测试数据与真实数据库规模接近，而不是只用一个很小的空数据库。

如果站点主要是静态内容，顺序读写和缓存命中率的权重可以提高；如果站点有用户登录、评论、订单或频繁更新内容，应把4K随机写和同步写入放在更靠前的位置。480GB容量本身只说明可用空间的大致级别，不能直接推出网站能够承载多少访问量。

七、复测条件与记录格式

性能测试最容易出现的问题，是不同时间、不同目录和不同缓存状态下的结果被放在一起比较。复测时应尽量保持以下条件一致：

• 同一台香港服务器、同一操作系统和内核；
• 同一挂载点、文件系统和测试文件大小；
• 相近的磁盘使用率和剩余空间；
• 相同的应用版本、数据库版本和业务数据量；
• 相同的缓存开关和预热方式；
• 相同的测试客户端、并发数和持续时间；
• 相同的测试顺序，或采用随机顺序避免测试先后造成偏差；
• 测试期间没有备份、批量导入、日志压缩等额外任务。

每个场景建议至少运行3轮，记录中位结果，同时保留异常轮次。若第一轮明显慢，先判断是否处于缓存预热、文件创建或初始化阶段，不要直接删除异常数据。每轮测试之间可留出短暂间隔，若要评估持续负载，还应增加更长时间的连续运行，以观察缓存耗尽、温度变化和延迟抖动。

测试完成后，确认目录内只有测试文件，再清理专用文件。以下命令会不可逆删除指定目录中的测试文件，执行前必须核对路径，不能用于生产目录：

rm -f /var/tmp/ssd-test/*.bin

最终报告至少应包含测试日期、服务器系统信息、测试目录所在挂载点、文件系统、磁盘使用率、fio版本、块大小、队列深度、读写比例、测试时长、p50/p95/p99、CPU与内存状态，以及应用层的并发、RPS、响应时间和错误率。只有这些条件能够对应起来，才能判断配480GB SATA SSD的香港服务器是否适合当前的入门级站点常规业务，而不是被单项顺序速度或一次性IOPS峰值误导。