云主机性能异常如何优化?

说起云主机的性能问题，我脑子里立刻浮现出几年前的一次惨痛经历。那时候我们搞了一个在线考试系统，开考前三十分钟，所有学生同时登录，服务器瞬间像被点了穴一样。页面加载转圈圈，十几分钟过去了，第一批学生还没看到考题，群里已经炸开了锅。我们一群人手忙脚乱地加配置、重启服务、切流量，折腾了快一个小时才勉强稳住。那次之后我痛定思痛，开始认认真真地琢磨一件事：云主机性能出了问题，到底该怎么优化?

后来我慢慢发现，性能优化这件事，七分靠诊断，三分靠动手。你连瓶颈在哪儿都没搞清楚就瞎调参数，跟闭着眼修车没什么区别。今天我就把自己这些年踩过的坑、试过的方法、总结出来的经验，一条一条地跟你聊聊。希望能让你在面对一台“卡得要命”的云主机时，有一套清晰的优化思路。

优化之前，先搞清楚“谁”把性能吃掉了

很多人一听说性能异常，第一反应就是升级配置。CPU高了加核，内存少了加容量，磁盘慢了换SSD。这种做法有时候管用，但更多时候就像往一个破了洞的桶里加水，加再多也留不住。优化的第一步，永远是定位瓶颈。

我接过一个咨询案例：对方说他们的CRM系统一到下午就慢得受不了，已经连续升级了两次云主机配置，从两核四GB升到四核八GB，后来又升到八核十六GB，问题依旧。我登录服务器一看，CPU和内存使用率都不高，磁盘也没写满，但负载平均值却高得离谱。再用iostat一看，磁盘的await值达到了两百多毫秒，这说明虽然配置上去了，但磁盘的IOPS性能跟不上了。他们用的是普通云盘，而CRM系统里有大量涉及报表生成的频繁读写操作。最终解决方案不是继续加CPU，而是换成了高性能的SSD云盘，并且把一些统计查询从主库挪到了只读从库上。性能问题迎刃而解，成本反而比之前还低了。

这个例子说明，优化之前必须要做一件事：测量。用top看CPU，用free看内存，用iostat看磁盘，用iftop看网络。哪一个指标冲破阈值，哪一个就是你的主要矛盾。不要凭感觉去猜。

CPU使用率高的优化策略

当top命令里显示us(用户态CPU)长时间超过80%，说明你的应用代码是真正的“吃CPU大户”。这时候升级CPU核数可能会有帮助，但更值得做的是优化代码本身。

我曾经优化过一个图片处理服务，它接收用户上传的图片后会进行裁剪、压缩、添加水印等一系列操作。最初是用PHP的GD库同步处理的，每张图片平均消耗0.3秒的CPU时间。高峰期并发上来，CPU直接打满。我们的优化思路是把同步处理改成异步，用户上传后先把原图存下来，返回一个“处理中”的状态，后台再用一个独立的工作进程池来处理。这样Web前端不再被CPU密集操作阻塞，而工作进程可以根据CPU负载动态调整并发数。调整之后，同样配置的云主机，吞吐量提高了将近四倍。

还有一种情况是CPU高但应用本身没什么复杂的计算，这时候就要警惕是不是有死循环或者不必要的重试。我遇到过一台Nginx代理，CPU使用率莫名其妙到了90%，strace一看，进程在内核态疯狂做文件操作。结果发现Nginx的access日志配置了一个不存在的目录，每次请求都尝试写入日志但写不进去，然后反复重试。把日志路径修正之后，CPU瞬间降到了5%以内。

对于CPU优化，我的建议是：先看是用户态高还是内核态高。用户态高就优化业务代码，加上缓存，减少不必要的计算内核态高就检查系统调用是否频繁，比如过多的文件读写、网络收发，或者某些驱动程序出了问题。

内存不足的优化思路

内存报警或者性能下降，并不总是因为物理内存不够用。有时候是内存分配不合理，有时候是缓存策略有问题，还有时候是程序发生了内存泄漏。

有一个电商客户，他们的购物车服务运行在四GB内存的云主机上，每隔两三天就要重启一次，否则就会报OutOfMemoryError。我们从监控看到，内存使用率每天增长大约百分之十五，典型的泄漏曲线。用MAT分析了堆转储文件之后，发现是一个Session管理类在用户退出登录后没有正确清除Session对象，导致数以万计的过期Session堆积在内存里。修复这个bug之后，同样的云主机连续运行了一个多月，内存占用一直稳定在百分之六十左右。

云主机内存优化的另一个常见手段是调整缓存。Linux系统会自动把空闲内存用作磁盘缓存(cache)，这在大多数情况下是好事，因为它能加快文件读取速度。但有一种场景下这个机制反而添乱：你的应用程序需要大量内存来处理实时数据，而操作系统却固执地占着大量缓存不肯释放。这时候你可以通过修改vm.drop_caches参数手动清理缓存，或者调整vm.vfs_cache_pressure让内核更积极地回收缓存。不过说实话，最省心的办法还是直接给云主机增加内存。云上的内存扩容通常只需要几分钟，线上业务不停机就可以完成，性价比往往比花几天时间去抠代码细节高得多。

另外，要注意swap的使用。free -h命令输出里的“used swap”如果持续大于零，说明物理内存真的不够用了。在云主机上，swap默认放在云盘上，而云盘的延迟比内存高好几个数量级。一旦开始用swap，整个系统的响应速度会直线下降。临时解围的办法是降低swap的“积极性”，通过调整vm.swappiness参数让系统尽量不使用swap，但治本之道依然是加内存或者排查内存泄漏。

磁盘IO成为瓶颈时的优化方法

磁盘性能问题在云主机上特别常见，尤其是那些大量读写本地文件或者使用云盘作为数据库存储的场景。磁盘IO瓶颈的典型表现是：系统负载高但CPU空闲，命令执行有延迟，数据库查询突然变慢。

先说一个我自己踩过的坑。有一台跑MySQL的云主机，业务量增长之后，每天晚高峰都会出现写入延迟飙升。用iostat一看，磁盘写IOPS已经达到了云盘规格的上限，写延迟从两三毫秒暴涨到了上百毫秒。当时第一反应是升配，换成更高IOPS的云盘。但是换了之后确实好了，可成本涨了一大截。后来我们认真分析了一下写入的来源，发现有一个统计表每隔五秒就执行一次INSERT ON DUPLICATE UPDATE，对同一行数据频繁更新，产生了大量的小写入。我们把统计频率从五秒改成了三十秒，并且把实时写入改成了批量写入，IOPS直接降到了原来的三分之一。这样一来，原来的云盘规格其实完全够用，根本不需要升级。

磁盘IO优化的几个方向，我总结了一下：第一，减少不必要的读写。比如关闭重复的日志记录，合并小文件的写入操作。第二，把随机写变成顺序写。很多数据库和应用在默认配置下会产生大量随机IO，换成追加写的日志结构或者使用SSD云盘这种对随机IO友好的存储，会有明显改善。第三，合理使用内存缓存。像Redis这样的缓存层可以把热数据放在内存里，减少对磁盘的访问频率。第四，如果是临时文件或者中间结果的读写，可以考虑使用内存文件系统tmpfs，但要注意数据易失性和内存容量的限制。

还有一个容易被忽略的点：云主机的磁盘性能往往和你创建磁盘时选择的类型以及大小有关。有些云平台，较大的磁盘容量会自动分配到更高的IOPS上限。如果你需要高性能但不是大容量，这种设计就有点尴尬。通常建议在购买云盘之前，仔细阅读云服务商的性能文档，选择最适合你应用场景的磁盘类型。

网络延迟和带宽的优化技巧

网络性能异常的表现往往是：服务响应时快时慢，丢包率高，或者跨地域访问很不稳定。优化网络性能比优化CPU和内存更复杂，因为它涉及的因素超出了你的云主机本身。

我处理过一个视频点播业务的网络问题。服务器在华北，大部分用户在华南，用户普遍反映视频缓冲时间长、拖动进度条卡顿。从服务器端看，带宽使用率并不高，CPU也很闲。用ping从华南的机器测试，往返延迟大概四十毫秒，丢包率不足百分之一，看起来一切正常。但是用traceroute一看，路由路径上绕了好几个不必要的中转节点。最后我们启用了云服务商的“Anycast加速”服务，相当于为公网流量专门优化了路由。同时把视频文件从云主机直接分发改成了通过CDN加速，用户的平均加载时间从三秒多降到了零点八秒。

对于普通的Web服务，如果遇到网络延迟偏高，有几个简单有效的优化手段：启用HTTP/2或者HTTP/3，它们支持多路复用和头部压缩，能显著减少连接建立的开销开启TCP BBR拥塞控制算法，这个对于有一定丢包率的网络环境特别管用，很多Linux发行版的内核都支持，只需要简单配置就能开启另外，合理设置TCP的keepalive参数和TIME_WAIT回收，可以减少连接的重复建立。

如果你发现云主机的出带宽经常跑满，而业务并不需要那么大的流量，那就要检查一下有没有异常的大文件传输或者流量攻击。用nethogs或者iftop可以根据进程实时查看流量占用。我们之前遇到过一台云主机出带宽持续在五十兆左右，排查发现是一个备份脚本把压缩包同时上传到了三个不同的对象存储桶，造成了三倍的冗余流量。优化脚本之后，带宽占用降到了不到二十兆。

还有一点，云主机的内网网络往往要比公网网络稳定得多，延迟也低。如果你的多个服务需要频繁通讯，尽量把它们部署在同一个VPC内，使用内网IP进行通信。有些业务场景甚至可以完全不走公网，比如数据库和应用服务器之间，就完全没有必要暴露公网端口。

应用层和架构层面的优化

前面说的都是操作系统和资源层面的优化，但在很多情况下，单台云主机的硬件指标再怎么调，也解决不了架构设计上的缺陷。这时候要考虑的是更高层面的优化。

举个例子，我们有一个新闻资讯类的客户，高峰期并发请求接近两万，单台云主机即使配置再高也扛不住。他们最初的做法是不断升级主机的配置，到最后已经升到了三十二核六十四GB，价格昂贵不说，一次重启就要好几分钟，而且单机依然有性能天花板。我们的优化方案是把单体架构拆解成微服务，把静态资源、动态请求、用户鉴权、数据库访问分别部署到不同的云主机上，再用负载均衡把流量分发到多台Web服务器。这样一来，每一台的负载都降下来了，而且可以按需弹性伸缩。大促的时候临时增加几台云主机，活动结束再释放掉，既保证了性能又控制了成本。

还有一次，一个SaaS平台的报表生成接口响应特别慢，直接原因是一个SQL关联了七张表，每次查询要跑十几秒。我们的DBA花了半天时间重写了这个查询，拆成了两次查询并且在应用层做关联，又给关键字段加了复合索引，查询时间降到了零点三秒。这种代码级别的优化，比给云主机加任何配置都管用。

所以，当你发现单机优化已经走到尽头的时候，不妨退一步想想：是不是可以从架构上做文章?是不是可以用缓存把热点数据提前加载好?是不是可以异步处理而不是同步等待?是不是可以把计算任务拆分到多台机器上并行?

监控和持续优化的习惯

说了这么多优化方法，我觉得最有必要强调的是：优化不是一次性工作，而是一个持续的过程。今天调好的参数，明天业务量翻倍了可能又不够用。去年合理的架构，今年可能出现新的瓶颈。

我养成了一个习惯，每周一上午会花半个小时看一遍所有云主机的性能趋势图。重点关注那些在过去一周里出现过“尖刺”的指标，以及那些稳步增长的指标。比如说，如果某台主机的磁盘使用率每周增长百分之五，那我知道再过两三个月就要面临扩容或者数据归档的问题。如果某台主机的平均CPU使用率从百分之二十慢慢涨到了百分之四十，我会去查到底是业务增长带来的，还是代码效率在下降。

有一次通过这种趋势监控，我发现一台数据库云主机的IO延迟在过去两周里悄悄增加了百分之三十。表面上看还在正常范围内，但我觉得不对劲，深入检查之后发现是云盘所在的物理存储节点出现了性能抖动。我们提前把数据库迁移到了新的云盘上，避开了后面一次持续了三天的大范围性能劣化。如果等到用户投诉了再处理，损失就大了。

另外，一定要设置合理的性能告警。告警阈值不能太灵敏，否则你会被淹没在无意义的报警里也不能太迟钝，否则等收到报警时性能已经严重影响了业务。我一般会按照历史基线的百分之一百五十来设阈值，并且要求持续超过五分钟才触发，这样可以过滤掉大部分的瞬时抖动。

总结

云主机性能异常优化，说到底是一道证明题。你要先证明瓶颈在哪里，再去选择合适的优化手段。CPU高了，可以考虑升级核数、优化代码、或者分散计算压力。内存不足，排查泄漏、调整缓存策略、或者干脆加容量。磁盘IO慢，减少读写、合并小IO、或者换高性能云盘。网络延迟高，优化协议、开启加速、或者调整架构。

但我想说的最重要的一句话是：不要迷恋单机优化。云最大的优势是弹性、是分布式、是你可以用一群普通的机器来支撑一个不普通的业务。当你在单台云主机上折腾了半天仍然达不到理想效果的时候，不妨抬头看一看整个架构。很多时候，更好的优化不是把一台机器变得多强，而是让十台普通机器一起分担工作，彼此互补，互为主备。

最后，请一定养成记录和复盘的习惯。每一次优化改动之前，记下当时的性能指标优化之后，再记录下来对比的结果。这些数据是你未来做决策的依据，也是你成长的见证。云主机的性能优化路上没有终点，但每往前走一步，你的系统就会更稳一点，你的用户就会更满意一点，而你自己也会比昨天的自己更专业一点。