北京云主机系统优化问题分析?

去年冬天，北京一家在线教育公司的运维负责人大刘，约我在中关村附近的一家咖啡馆见面。他说他们公司把核心业务系统部署在北京某云服务商的主机上，配置看起来不低，可每到晚上七点到九点的上课高峰期，系统就变得特别慢。学员看课件卡顿，老师讲课的声音断断续续，技术后台的告警消息更是一条接一条。“我已经把云主机的配置升过两次级了，CPU从四核升到八核，内存从八G升到十六G，可问题依旧。钱花了，效果没看到，老板已经很不耐烦了。”大刘把咖啡杯往桌上一放，满脸写着无奈。

大刘遇到的情况，说白了就是典型的“系统优化没做到位”。很多人对云主机有一种错觉，觉得“云”就意味着弹性、智能、不用操心。花钱买了更高配置的云主机，软件和系统层面的问题就应该自动消失了。可现实恰恰相反，云主机只是给你提供了一个计算资源的底盘，底盘再大，你要是把货物堆得乱七八糟，跑起来的效率照样上不去。北京的云主机市场在全国来说都是最成熟、竞争最充分的区域之一。这里汇聚了几乎所有主流云服务商的骨干节点，网络延迟低，带宽资源丰富，很多央企、互联网大厂、金融总部都把核心业务放在北京的云上。但越是高手云集的地方，对你的系统优化能力要求反而越高，因为用户已经被低延迟、高响应的服务惯坏了，任何卡顿和延迟都会被放大。

在北京这种一线城市的云环境下做系统优化，跟你在小机房里面自己捣鼓一台物理服务器完全是两回事。云主机的底层是虚拟化，虚拟化本身就带来了额外的资源开销和不确定性。CPU是不是被同一台物理机上的邻居争抢了，磁盘IO是不是因为共享存储而出现波动，网络包在经过虚拟交换机的时候有没有额外的延迟，这些都是你在优化的时候需要考虑进去的因素。下面我把在北京云主机上做系统优化最常遇到的几类问题，结合真实的案例，一个一个地拆开来讲。

内存占用居高不下，到底是谁在吃内存

大刘最开始排查的方向是CPU。他觉得系统卡顿肯定是CPU不够用了，所以一口气把云主机从四核升级到了八核。可升级之后，上课高峰期CPU的占用率依然只有不到百分之三十，卡顿却一点没改善。这就说明问题不在CPU上。后来他用top命令仔细看内存那一栏，发现八G内存已经被用掉了七点五个G，剩余可用内存不到五百兆。系统开始频繁使用SWAP交换分区，把内存里不常用的数据临时写到磁盘上。而磁盘的读写速度跟内存比起来差了至少两个数量级，一旦开始频繁换页，整个系统的响应速度自然就大幅下降了。

那么问题来了，八个G的内存到底被谁吃掉了?大刘用ps aux --sort=-%mem命令把进程按内存占用从高到低排了个序，发现排在前面的是几个Java进程，每个都占了一两个G。他们的在线教育平台是用Java开发的，启动参数里设置了最大堆内存为四个G。但问题在于，这四个G只是一个“上限”，Java进程一启动就会向操作系统申请这么大一块虚拟内存，哪怕实际只用了一半，操作系统也会把这四个G标记为“已分配”。再加上操作系统自身的缓存、日志进程、数据库进程、Nginx进程，二十多G的内存就这么被吃掉了。虽然实际使用的物理内存可能没有这么多，但操作系统的内存管理机制会倾向于尽量把已分配的内存保持在物理内存中，导致可用内存越来越紧张。

找到了症状，解决方案并不难。大刘调整了Java应用的启动参数，把最大堆内存从四个G降低到两个G，同时调整了年轻代和老年代的比例，让垃圾回收的频率降低。然后关闭了系统中一些不必要的服务，比如Postfix邮件服务、某些不需要的系统日志采集器。最后给云主机开启了一个简单的内存监控脚本，当可用内存低于百分之二十的时候就发送告警。这一套组合拳打下来，同样八G的内存配置，系统即使在高峰期也基本不再使用SWAP分区了，卡顿问题得到了明显缓解。你看，有时候不是内存不够大，而是内存被“浪费”的方式不对。

磁盘IO瓶颈，云硬盘的隐藏陷阱

北京一家做图片社交的创业公司，把用户上传的图片直接存储在云主机的系统盘上。用户量增长之后，他们发现上传图片的速度越来越慢，有时候一张几百KB的图片要传好几秒。他们首先怀疑是带宽不够，把带宽升了一档，没有改善。又怀疑是程序代码写得有问题，让开发团队优化了一周，也没有明显效果。最后我帮他们看了一下磁盘IO的情况，用iostat -x 1命令发现，系统盘的写IOPS经常达到上限。他们购买的是性能级别的云硬盘，标称的最大IOPS是三千。但他们的业务高峰时，图片上传加上日志写入加上数据库操作，平均每秒需要四千多次IOPS。这就好比一条设计时速八十公里的公路，车流量达到了一百二十公里每小时的速度，不堵才怪。

问题的关键在于，很多人不太清楚云硬盘的IOPS和吞吐量是有上限的，而且不同类型、不同容量的云硬盘上限差异很大。他们把图片、数据库、操作系统、日志全部塞在同一个系统盘里，各种IO请求互相争抢，加上云硬盘的底层本来就是多租户共享的，邻居业务的高IO操作也会影响到你的性能表现。这就是云环境下最常见的“邻居干扰”效应。

解决方法其实很清晰：数据分层，把不同类型的IO请求分开处理。操作系统和应用程序放在系统盘上，数据库的数据和日志放在单独购买的高IO云盘上，用户上传的图片则挂载一个大容量的普通云盘。如果条件允许，可以把最热门的图片通过CDN分发出去，或者用云上的对象存储来存放图片，这样云主机只需要处理上传的请求，而不需要承担存储和读取的压力。那家公司按照这个方案调整之后，图片上传的平均耗时从两秒多降到了四百毫秒以内，用户再也没有抱怨过上传慢的问题。

网络参数未优化，高并发下的隐形瓶颈

北京有一家做实时行情推送的金融数据公司，他们的云主机上运行着一个WebSocket服务，同时保持数万条长连接，向客户推送股票、期货的实时行情。业务刚上线的时候一切正常，但随着客户数量增长，他们发现连接数超过一万五千之后，新建连接的成功率就会明显下降，而且已经建立的连接也会偶尔断线。他们排查了带宽、CPU、内存，都没有发现异常。

后来用netstat -s命令看了一下网络协议栈的统计信息，发现问题出在内核参数上。Linux系统默认的 somaxconn 参数只有128，意思是一个端口上等待被应用程序accept的已完成队列的长度只有128。当大量客户端同时尝试建立连接时，如果应用程序来不及处理，多余的连接请求就会被直接丢弃。另一个参数是 tcp_max_syn_backlog，默认值也只有256左右，这是半连接队列的长度。对于高并发场景来说，这两个默认值实在太小了。另外，他们的云主机上没有开启TCP的快速回收和重用机制，大量短连接在等待TIME_WAIT状态时消耗了过多的端口资源。

把这些参数调整了之后，效果立竿见影。他们修改了/etc/sysctl.conf文件，把net.core.somaxconn调整到了四万，net.ipv4.tcp_max_syn_backlog调整到了两万，开启了net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle，并且调整了本地端口的可用范围。这些参数的值不是越大越好，要根据你的业务场景和内存大小来合理设置。调整之后，同样配置的云主机，稳定支撑的连接数从一万五千提升到了四万以上，而且新建连接的成功率稳定在百分之九十九点九以上。这就是系统优化的魅力——不增加一分钱的硬件成本，只是把操作系统中那些“为了兼容老旧硬件而设置的保守默认值”改成适合你业务的数字，就能带来几倍的性能提升。

CPU平均负载过高，但CPU使用率却很低，什么情况

这是一个比较容易让人困惑的现象。北京一家做日志分析的SaaS公司，他们的云主机上用rsyslog收集和处理大量的日志数据。监控图表显示，CPU的使用率只有百分之四十左右，但系统的平均负载(load average)却经常达到十几甚至二十几。他们一直搞不明白，CPU明明还闲着很多，为什么系统却卡得要命。

这个现象背后的技术原因，叫做“等待IO导致的负载升高”。平均负载这个指标不但包括了正在使用CPU的进程，还包括了正在等待CPU的进程，以及最重要的——正在等待磁盘IO的进程。也就是说，即使CPU完全空闲，如果有很多进程因为等待磁盘读写而被阻塞在队列里，平均负载一样会飙升到很高的水平。在那家日志分析公司的场景下，rsyslog进程把接收到的日志写到一个机械性质的云硬盘上，写入速度跟不上日志产生的速度，导致大量写请求在队列里排队，这些排队的进程都被计入负载了。而CPU使用率看起来不高，是因为CPU大部分时间其实都在闲着等磁盘响应，根本没有活干。

解决方法还是从优化入手。他们把日志写入的目标从普通云盘换成了高性能的SSD云盘，实测IOPS和写入延迟都大幅改善。同时在rsyslog的配置里开启了异步写入模式和内存缓存，让日志先攒一批再一次性写入，减少了磁盘的频繁操作。他们还在应用层面做了分流，把不同来源、不同重要程度的日志写到不同的磁盘分区上，避免因为某一种日志的突发高峰而影响到整体。做完这些之后，平均负载从二十左右降到了三以下，CPU使用率也升到了百分之六十以上——这次才是真正在好好干活了。

内核参数与并发连接的矛盾

北京的一家弹幕互动直播平台，每到热门比赛或者热门剧集上线的时候，服务器就会频繁出现“Too many open files”的错误。他们查了很久，以为是程序有文件句柄泄漏，检查了好几遍代码，没有发现问题。后来才意识到，这个错误不一定是指真的打开了太多文件，而是指打开了太多网络连接。在Linux系统里，“一切皆文件”，每个TCP连接在操作系统中也会占用一个文件描述符。

系统的默认限制是1024，也就是说，单个进程最多同时打开1024个文件或者网络连接。对于直播平台这种动辄上万并发连接的场景，1024这个数字连塞牙缝都不够。他们需要修改两个层面的限制：一个是系统级别的硬限制和软限制，通过修改/etc/security/limits.conf文件，把nofile参数调整到65535或者更高。另一个是进程级别的限制，对于像Nginx、Redis这些高性能服务，往往需要在它们的配置文件中单独设置最大并发连接数。这个案例说明，系统优化很多时候不是去折腾什么高深莫测的东西，而是先把那些显而易见的基础配置做对。

优化之后，别忘了持续观察和迭代

北京云主机的系统优化，从来不是一锤子买卖。你今天调好了内核参数，明天业务流量分布变了，那些参数可能又不合适了。你今天把数据库和图片分开放在了不同的云盘上，后天业务模式调整了，新的IO热点可能又出现了。所以持续观察和迭代的能力，比一次性把优化做到底的能力更重要。

建议每个月或每个季度，挑一个业务低峰期，系统地检查一下云主机的各项性能指标。看CPU的usage和load的比值是否合理，看内存的可用量是否充足、swap使用量是否正常，看磁盘的IOPS和延迟是否在预期范围内，看网络的丢包率和重传率是否出现了异常。把这些指标跟历史数据做对比，你会发现很多问题的苗头在酿成事故之前就已经显露出来了。

还要养成一个习惯：任何一次系统优化之后，都要记录下来。你调整了哪些参数，原来的值是多少，修改后的值是多少，修改之后业务表现有什么变化。这样做的原因有两个：一是方便你将来回溯，搞清楚某个优化措施到底产生了多大效果;二是万一哪天改错了，你能快速恢复到之前的状态。

总结

大刘的在线教育平台，在经过内存参数调整、磁盘IO优化、内核参数调优等一系列操作之后，同样还是那台八核十六G内存的云主机，上课高峰期的系统响应速度提升了三倍以上，学员和老师的投诉几乎降为零。大刘后来在电话里跟我说：“我以前真的不懂什么叫系统优化，以为优化就是升级配置。现在才明白，升级配置只是买更大的房子，优化才是学会怎么把家具摆得更合理。”

北京云主机的系统优化问题，说到底就是一件“把不合适的默认值改成合适的值”的事情。操作系统的设计者为了兼容成千上万种不同的硬件和应用场景，把很多参数的默认值定得很保守。这些保守的参数在绝大多数情况下都能让系统“跑起来”，但如果你想让系统“跑得快”、“跑得稳”，你就得根据你自己业务的脾气，对这些参数做一次全面的校准。内存、磁盘、网络、内核、进程，每一个层面都有优化的空间，也都值得你去认真对待。

希望读到这篇文章的朋友，下次再遇到云主机卡顿、延迟、不稳的时候，不要只想着升级配置。先静下心来看看，到底是哪个层面拖了后腿。很多时候，答案就藏在那些被你忽略的系统参数里，藏在那些不合理的IO分布里，藏在那些被浪费的内存资源里。把这些问题一个个找出来解决掉，你会发现你的北京云主机其实远比你想的要强大。