郑州云主机磁盘性能优化技巧?

今年三月，郑州本地一家做餐饮供应链SaaS平台的运维主管小周，在本地技术社群里发了一句话：“同样的云主机配置，为什么人家的数据库响应只要几毫秒，我的动不动就几十甚至上百毫秒?我查了CPU和内存都很空闲，问题到底出在哪里?”

我那时候正好在群里潜水，就接过话茬聊了几句。小周他们的平台做的是餐饮门店的进销存管理和供应链下单，每天有几百家餐饮店在上面下单采购，早晚两个时段下单非常集中。他们买的云主机配置并不低，可每到中午十一点到一点、下午五点到七点这两个餐饮店集中备货的时间段，订单提交就明显卡顿，店长在手机上下个单，转圈要等五六秒才能弹出“下单成功”的提示。最要命的是，到了月底扎账的时候，财务部门导出一个月的大盘报表，那个SQL查询动不动就跑几分钟，甚至直接超时断开。

我让小周把云主机的配置详情发给我看了一下。CPU和内存确实很充裕，常年占用率不到百分之四十。网卡带宽也绰绰有余。可是当我把iostat -x 1这个命令跑起来之后，问题一下子就暴露出来了。磁盘的%util几乎一直维持在百分之八十以上，await这个指标——也就是平均每次I/O请求从发出到完成所花费的时间——经常跳到三十到五十毫秒。换句话说，不是CPU算不动，不是网络传不动，而是磁盘“写”的速度跟不上业务的节奏了。订单提交的时候，每一笔订单都要写入数据库，数据库要写日志、写数据文件，盘慢了，整个链条就都慢了。

小周的这个问题，在郑州云主机的实际运维场景里实在太常见了。很多人觉得“云主机”就是弹性的、智能的，买多大配置就享受多好的性能。可磁盘这个东西，在云环境里恰恰是最需要你花心思去调的一个环节。郑州这些年数字经济发展得非常快，从中原科技城算力产业园的建设，到河南空港智算中心正式投产，中部地区最大智算中心落地郑州航空港，郑州已经成了全国算力布局中的重要一极。计算资源越来越充沛，可磁盘IO性能跟不上CPU和内存增长速度的问题也暴露得越来越明显。

今天不想讲那些云里雾里的理论，就用小周他们团队踩过的坑和填过的土，把郑州云主机磁盘性能优化这件事从头到尾说清楚。

先搞清楚你的磁盘到底慢在哪儿

很多人一感觉到系统卡顿，第一反应就是“CPU不够了”“内存不够了”，掏出top和free看一圈，发现CPU和内存都没问题，然后就开始怀疑云服务商是不是给虚标了配置。其实磁盘IO这个层面，需要专门用工具去看。不用这些工具，你永远不知道磁盘到底在忙什么。

小周在我们的建议下，在云主机上安装了sysstat工具包，然后执行了iostat -x 1这个命令。这个命令会每一秒刷新一次磁盘的使用情况，能看到好几个非常关键的指标。

首先是%util，这个数字代表磁盘的忙碌程度。如果这个数字持续超过百分之七十甚至接近百分之百，说明磁盘已经被压到接近极限了。小周那边的%util在高峰期常年在百分之八十以上。

其次是await，这是每个I/O请求从提交到完成所花费的平均时间，单位是毫秒。对于SSD云硬盘来说，正常的await应该在几毫秒以内。小周那边高峰期达到了三四十毫秒，这就是明显的瓶颈信号了。

还有一个指标是avgqu-sz，这是I/O请求队列的平均长度。如果这个数字经常大于1，说明磁盘处理不过来，请求在排队。

把这些指标看明白了，你就知道问题的性质了。不是说磁盘“坏了”或者“不行了”，而是你的业务对磁盘的压力超过了它当前配置下能承受的范围。接下来要做的，就是想方设法把这个压力降下来，或者让磁盘的响应效率提上去。

为了找到具体是哪个环节把磁盘给拖慢了，小周又执行了iotop命令。这个工具的好处在于它能精确地告诉你：当前哪一个进程在读写磁盘，读写量有多大。几分钟观察下来，iotop的输出显示MySQL的写入操作占据了磁盘I/O的大头，而且还有好几个后台的日志采集脚本同时在往磁盘上刷日志。

到这一步，小周心里就有数了。不是云服务商给了差的磁盘，而是他的业务架构和系统配置，把同一块磁盘当成了万能的“大仓库”——数据库在这里跑，日志在这里写，操作系统在这里装，备份也临时放在这里。所有I/O都挤在一条独木桥上，不堵才怪。

从根源上解决，不搞“头痛医头”

找到了问题出在MySQL进程的频繁写入、日志进程的频繁写入、以及缺乏合理的读写分离和缓存机制之后，小周他们做了一整套改造。这一整套改造下来，每一步都是有章法的。

第一步：把不同类型的I/O需求拆分开。

以前他们把系统盘当成了所有存储需求的唯一出口。优化之后的做法是：操作系统和应用程序放在系统盘上;MySQL的数据文件和日志文件单独挂载了一块高性能的SSD云盘;那些日志采集脚本产生的日志文件，单独挂了一块吞吐型云盘;至于那些临时性的报表导出文件，直接放进基于内存的tmpfs里，根本不给磁盘增加负担。这个做法的底层逻辑非常清晰：不同的数据有不同的访问模式，数据库需要低延迟随机读写，日志文件是顺序的大块写入，临时文件则压根不需要落盘。用不同的“容器”去承载不同的需求，既避免了I/O路径上的互相干扰，也节省了不必要的配置投入。

这一步做完之后，小周他们再用iostat去看，系统盘的利用率降到了百分之二十以下，数据库专用云盘的利用率大约在百分之五十到六十，日志盘的写负载也在合理范围内。三块盘各司其职，再也没有相互争抢资源的状况了。

第二步：调整数据库的写入策略，减少磁盘压力。

磁盘拆分只是第一步。磁盘本身变快了，但如果你每次提交订单都要立即把数据物理写在盘上，压力依然不小。小周他们在MySQL的配置文件my.cnf里，把innodb_flush_log_at_trx_commit这个参数从默认的1改成了2。这个参数是什么意思呢?设为1的时候，每提交一个事务，MySQL就会强制把日志从内存刷到磁盘上，安全性最高但I/O负载最重。设为2的时候，事务提交时只把日志写到操作系统的缓存里，每隔一秒钟才真正刷到磁盘。这相当于把多个写入请求攒在一起一次性提交，大大减少了磁盘的写入次数。当然代价是如果服务器突然断电，可能会丢失最近一秒钟的数据。对于餐饮供应链平台来说，这个风险是完全可以接受的。

他们还把innodb_buffer_pool_size调整到了物理内存的百分之七十左右，让更多热数据能够常驻在内存里。这样一来，读取订单、查询库存这类高频操作，很多时候直接从内存里拿数据，根本不需要触碰磁盘。

这两处调整之后，数据库专用云盘的%util从之前的百分之七八十降到了四十左右，哪怕在中午高峰期也基本维持在这个水平。订单提交从之前的转圈五六秒缩短到了一秒以内，店长们下单的体验立刻好了很多。

第三步：给服务器挂载参数做“微创手术”。

在操作系统的层面，还有不少不起眼但效果显著的调整可以做。小周他们在挂载数据盘的时候，在/etc/fstab里加上了noatime参数。这个参数的意思是：Linux不再记录文件的最后访问时间。对于云服务器这种高并发场景来说，记录每个文件的访问时间其实意义不大，但每次写操作更新这个时间戳却会实实在在地产生一次额外的写入开销。关掉它，等于省下了一笔小的但是持续存在的I/O支出。

他们做的另一件事是调整了vm.dirty_background_ratio和vm.dirty_ratio这两个内核参数。这两个参数控制着Linux内核在什么时候把内存中的“脏数据”写回磁盘。默认的设置会让内核过早过频繁地把少量数据刷到磁盘上，导致写入操作变得很碎片化。适当调高这两个数值，让数据在内存里攒得多一些再一次性写下去，磁盘的写入次数显著减少，整体吞吐量反而提升了。

还有一处容易被忽略的开销是时间戳的微秒精度。ext4文件系统默认开启了高度精确的时间戳记录(纳秒级)，这个在绝大多数业务场景下都没用，但会额外增加元数据的写入。关闭之后，文件系统层面的写入负载也有一定的下降。

第四步：把I/O调度器换成更合适云环境的那一种。

很多人压根不知道Linux内核里还有一个叫“I/O调度器”的东西在默默工作。简单来说，当多个进程同时向磁盘发读写请求的时候，调度器负责决定哪个请求先执行，哪个请求后执行。机械硬盘时代，调度器需要在“公平性”和“效率”之间反复权衡，因为磁头来回移动的成本很高。但在SSD云硬盘这种没有机械寻道的设备上，传统的调度算法反而成了多余的负担。

小周他们把数据盘的I/O调度器从默认的mq-deadline改成了none。这意味着内核不再对I/O请求做额外的排队和重排，让每个请求尽可能快地直达设备。这个改动配合多队列(blk-mq)机制一起使用后，随机读写4K小文件的延迟直接降低了接近百分之三十。

第五步：用内存来做“加速缓存”。

餐饮平台有一个典型特征：同一个菜品的库存数量在短时间内会被反复查询。后台ERP系统在实时更新，前台下单页面也在不断轮询。这就导致数据库被同样的查询反复“轰炸”，每次都产生磁盘I/O。

小周他们在这个环节上花了不少心思。他们把当天比较热门的菜品数据从MySQL里抽出来，放进了Redis这个内存数据库里。Redis本身是基于内存访问的，读写速度比磁盘快好几个数量级。下单页面先到Redis里查库存，只有少数需要强一致性的写操作才走到MySQL。这样一来，MySQL的读负载至少减轻了百分之六十，磁盘的压力随之大幅度降低。

他们还引入了页面静态化技术。对于菜品的介绍详情、图片这些不经常变动的数据，提前生成静态HTML文件。用户请求过来的时候Web服务器直接返回这些静态文件，不需要再调用PHP或者Java去查数据库。整个请求链路的数据量更少了，磁盘的读操作也化解于无形。

一个郑州物流企业的磁盘优化之路

小周他们的案例持续了差不多两个月的完整技术改造才最终收尾。但我在郑州还碰过另一个让人印象很深的优化案例。

今年年初，郑州一家做同城配送的物流公司，把他们的运单调度系统部署在云主机上。这家公司有几百台配送车辆和上千名骑手，调度系统需要根据实时运单的位置和每个骑手的负载来做动态分配。调度算法本身不算特别复杂，可他们遇到了一个奇怪的问题：每天的运单量都在稳步增长，可是调度系统的运单处理速度却一天不如一天。同样是中午高峰时段，两个月前一个小时能处理八千多单，两个月后连四千单都处理不了了，调度后台的反应越来越慢，骑手手机上的抢单界面有时候迟迟不显示新单。

他们自己排查了很久，CPU使用率很正常，内存够用，网卡带宽也远没跑满。他们甚至怀疑是调度算法的代码写得太差，重构成本又太高，进退两难。

后来我介入看了一下监控面板，发现他们的磁盘写入延迟从三个月前的平均八毫秒，变成了现在的平均六十七毫秒。这是一个非常危险的信号。深入了解之后才弄明白，他们用的是普通SATA云硬盘，三个月前读写IOPS指标对于当时的运单量来说确实够用。可是三个月来他们的运单量从每天两万单增加到了每天六万多单，订单数据加上GPS位置上报数据大量写入磁盘，SATA云硬盘的IOPS上限被彻底打穿了。而且GPS调度车辆的位置数据是不断在更新的更新文件，大量的小文件随机写入占用了大量I/O队列，导致调度系统核心的运单写入请求迟迟得不到处理。

我给这家物流公司的方案很简单，核心就一句话：给磁盘减负。首先将GPS位置数据的写入目标从SATA云盘迁移到了一个专门的低成本对象存储，这个存储内部自带高并发写入能力且容量无限，直接释放了云主机磁盘的压力。其次将调度系统的运单数据从SATA云盘迁移到了一块NVMe SSD云盘上面，这块NVMe盘的IOPS是原来SATA云盘的七到八倍，随机写入延迟也大幅降低。两块盘的分工和用途非常明确——NVMe盘用来存放核心的运单和调度数据，对象存储用来存放海量的GPS日志数据。前后不过两个小时的迁移工作完成之后，调度系统的单小时处理能力从四千多单直接跃升到了九千多单，骑手抢单的延迟也恢复了正常。

这个案例让我意识到，郑州很多中小企业在选云主机的时候，很容易犯的一个错误就是“一块磁盘包打天下”。一开始运行是很顺畅的，可业务量上来之后，磁盘成为性能瓶颈的局面就会暴露无遗。并不是你家业务太复杂，也不是云服务商给你的性能不够，而是你的存储分层策略设计一直没有跟随业务的增长同步迭代。

把磁盘性能优化常态化

写完上面这些案例，我觉得有必要补充一点：磁盘性能优化不是一锤子买卖，不是什么玄学，而是一套应该贯穿在日常运维中的常态化工作思路。不是每次出了卡顿才急急忙忙去查，而是从一开始就建立起磁盘性能的基线数据，让后续的每一次性能变化都有据可查。

我建议每个月用fio工具对所有业务盘做一次基准测试。测试命令不复杂，可以读取4K随机读写的IOPS和延迟数值，跟上个月的数据做个比对。一旦发现某个盘的IOPS或者延迟出现显著劣化，就需要引起警觉了——很可能是磁盘本身的性能衰减，也可能是你的应用对磁盘的使用模式发生了变化。

还要留心一件事：云硬盘在使用久了之后会出现空间碎片化和TRIM(定期清理无效数据块)指标不理想带来的性能衰减。尤其是频繁删除和写入的数据盘，一个有效的补救措施是定期执行文件系统的fstrim命令，让操作系统通知底层存储哪些数据块已经废弃、可以回收重用。这个做法的维护成本不高，但对长期性能的保持很有意义。

另外，郑州目前数字基础设施非常丰富，包括郑东新区的算力产业园、河南空港智算中心的陆续投产，云服务商在本地可提供的存储产品线也越来越丰富，有普通SATA云盘、SSD云盘、极速型NVMe SSD云盘、还有专门的对象存储服务。不同的存储产品有不同的IOPS上限和延迟特征，价格和性能也成比例地拉开差异。选盘的时候不要只看容量大小，而是要结合你的业务读写模式来做选择。

不要忽视数据库这一层

所有的磁盘性能优化，最终都会追溯到最上面的应用层和数据库层。数据库怎么写数据、怎么读数据、怎么用索引，直接决定了磁盘的I/O负载有多重。我见过郑州一家跨境电商平台，他们的架构师把磁盘从SSD换成了极速型NVMe SSD，性能瓶颈依然没有解决。最终通过慢查询日志分析才发现，有个核心SQL没有命中索引，每次执行都要扫描全表几百万行数据，相当于每次查询都要把整张表从磁盘读到内存里。磁盘再快也架不住这种毫无底线的暴力索取。给那个查询加上复合索引之后，执行时间从三秒降到了八毫秒，磁盘的压力也随之消失了。

所以优化磁盘性能，但不应该止步于磁盘。建议同时把数据库慢查询日志打开，定期分析那些执行时间比较长的SQL。很多时候你会发现，导致磁盘累垮的罪魁祸首，往往不是磁盘本身，而是那些写得不够好的SQL语句。

最后聊几句真心话

回到小周那个餐饮供应链SaaS平台。经过差不多一个月的持续优化和调整，数据盘的%util从之前的百分之八十降到了高峰期百分之四十左右，订单提交的响应时间缩短到了以前的五分之一。最让小周感到惊喜的是，财务部门月底导报表的那个SQL查询，优化之后从原来的三分多钟缩短到了不到三十秒，财务主管特意在群里给他们点赞，说终于不用忍受报表导出的无限等待了。

小周后来在技术社群里分享经验的时候，说了这么一句话：“以前总觉得买云主机就是拼配置，配置越大越好。现在想来真的是太天真了。资源本身是原材料，系统优化才是厨师的手艺。饭做得好不好吃，七成在厨子，三成在食材。”

这句话我越想越觉得说在点子上了。郑州云主机的磁盘性能优化，说白了就是一套从“用资源”到“用好资源”的思路转换。不要去迷信盲目升级配置，因为那样往往解决不了根本问题。真正的解决路径是沉下去把瓶颈找出来，从磁盘拆分的合理布局，到文件系统挂载参数的细节微调，到I/O调度器和内核参数的精细打磨，再到应用层和数据库层的整体调优。每一层的优化加在一起所产生的重叠效应，最终带来的性能提升，往往比单纯买一块更贵的盘要强得多。

写到最后，我还是想对同样在郑州跑业务的朋友们多说几句：这个城市的数据中心基础设施已经非常完善，包括郑东新区算力产业园的建设以及河南空港智算中心三期项目的签约落地，郑州的算力资源在国内已经站到了相当靠前的位置。你完全有条件享受到在这个基础上提供的高品质云服务。磁盘性能好不好，关键看你会不会把环境里的潜力挖掘出来。

该拆分就拆分，该调参就调参，该上缓存就上缓存，该写索引就写索引。三百六十行该尝试的路径都试过了，你会发现云主机磁盘性能的优化，根本不是什么复杂的高深学问，而是每一天运维工作里一次实实在在的、看得见成效的修修补补。一台云主机的潜力，远比你想象的要大得多。你需要的只是一点耐心和一些正确的方法，去把它唤醒。