云服务器资源耗尽如何处理?从“宕机边缘”拉回来的实战心法

那天下午，我正在参加一个线上技术会议，突然手机震动个不停。打开一看，是客户发来的语音，声音里带着明显的慌张：“不得了了，我们的后台完全动不了了，用户那边也刷不出东西，是不是服务器炸了?”我赶紧退出会议，连上云服务器的控制台，映入眼帘的监控曲线让我倒吸一口凉气——CPU使用率那条线，直直地顶在了百分之百的格子上，已经持续了快二十分钟。内存占用也飙到了百分之九十多，整个系统像一个快要溺水的人，只剩下最后一点力气在挣扎。

这种场景，但凡用过云服务器的人，或多或少都遇到过。资源耗尽这四个字，听起来好像很专业，说白了就是服务器扛不住了。它可能不是因为你的业务太火爆，也可能是因为某个程序“疯了”，还可能是因为有人在背后搞破坏。今天这篇，我不打算照本宣科地罗列概念，而是想用讲故事的方式，把我在不同场景下处理资源耗尽的经验分享出来。每一个场景，都是我或者朋友实打实踩过的坑。

先讲一个和“面子”有关的案例。

有一次，一位做自媒体的朋友兴冲冲地告诉我，他的个人网站终于上线了，用的是云服务器。结果第二天凌晨，他打电话给我说网站访问不了，页面打开极慢。我登上去一看，CPU正常，内存正常，但是磁盘IO等待值高得离谱。我用了一个叫iostat的命令查看，发现磁盘的读写请求队列长度达到了好几百，也就是说有几百个任务在排队等着磁盘干活。这很奇怪，一个个人网站，怎么会把磁盘搞成这样?

我让他把网站代码发给我看看。翻了一遍之后，我发现他在每个页面里都写了一段代码，用来统计访问次数。这个统计方式很直接：每次有人访问，就打开一个文本文件，把里面的数字加一，再写回去。如果是冷门网站，一天几百个访问，磁盘还能撑得住。但他的文章突然被某个大V转发了，瞬时访问量冲到了每分钟上千次。于是，成百上千个请求同时去读写那同一个文本文件，磁盘瞬间就被打爆了。这就是典型的磁盘IO耗尽，问题根源在于一个糟糕的程序设计。

解决办法很简单，先把那个统计功能临时关掉，网站立刻就恢复了正常。然后我帮他换了一种统计方式，不再每次都写磁盘，而是先把计数缓存在内存里，每隔一段时间批量写入一次。从那以后，再也没有因为统计功能而卡死过。这个案例给我的启示是，很多资源耗尽的问题，本质上不是服务器不够强，而是代码写得不够聪明。

再讲一个和“贪心”有关的案例。

有一家做数据分析的公司，他们的技术负责人找到我，说他们的服务器每到下午两点左右就会变得特别慢，有时候甚至失去响应。他们一直以为是用户访问量增加导致的，已经升级了好几次配置，但问题依然存在。我提出要看看服务器的定时任务。检查之后发现，他们每天下午两点有一个脚本，会去分析过去二十四小时的所有数据。随着数据量越来越大，这个脚本占用的内存也越来越多。一开始数据量小的时候没问题，后来数据量大了，这个脚本一运行就把物理内存吃光，然后系统开始用swap。用swap之后，整个服务器的速度就跌到了谷底，其他所有服务的响应都变得极其缓慢。

他们问我怎么办。我说，两个方向。第一，优化这个分析脚本，不要一次性把全部数据加载到内存里，改成流式处理，读一条分析一条，内存占用就会降到很低。第二，如果暂时改不动代码，就把这个脚本迁移到另外一台专门做数据分析的服务器上，不要和主服务抢资源。他们选择了第二个方案，因为更快捷。从那以后，主服务器再也没有在下午两点卡过了。这个案例教会我，要善于把不同类型的任务分开，别让一个“贪吃”的后台任务把整个系统拖垮。

说起资源耗尽，还有一个让人哭笑不得的“无限增长”案例。

一位创业者运营了一个社群网站，用户可以在上面发布帖子。刚开始一切都好，可是运行了三个月之后，他发现服务器越来越慢，查看磁盘，发现空间被占用了百分之九十以上。他用du命令一层一层地找，发现是网站的访问日志文件占了几十个G。更糟糕的是，这些日志文件从来没有被清理过。从网站上线第一天开始，所有的访问记录都原封不动地保存在那里。磁盘空间被日志填满，数据库没办法写入新的帖子，自然就出问题了。

我当时帮他处理的步骤是这样的。首先，用echo命令临时清空了那个巨大无比的访问日志文件，释放出大量磁盘空间，让网站立刻恢复写入能力。然后，我给他配置了logrotate日志轮转工具，每天自动切割日志，只保留最近七天的，超过七天的自动删除或者压缩归档。再后来，我还帮他把一部分重要的日志发送到了远程的日志服务器，本地只保留短期的。这样一来，磁盘空间就再也没出现过被日志撑爆的情况。这件事以后，他自己也养成了习惯：每半个月登录服务器看一眼磁盘使用率，心里有数。

还有一个不得不提的典型案例，是关于“死循环”的。

有一个朋友做爬虫开发，他的爬虫程序在某一天突然导致服务器CPU爆满。我登录之后用top命令扫了一眼，发现CPU几乎全部被一个Python进程占用了。这个进程的名字看起来很眼熟，就是他的爬虫主程序。我问他发生了什么，他说他改了一段代码，原来是用for循环遍历一批URL，改完之后忘记给循环加退出的条件了，结果变成了一个死循环，不停地重复处理第一个URL。这个死循环把CPU跑满了，导致服务器上运行的其他网站和服务都受到了影响。

找到原因之后，他马上终止了这个进程，修改了代码里的循环逻辑，加上了一个正确的终止条件。重新运行之后，CPU使用率马上回到了正常水平。这个案例让我想到一个道理：代码改动的时候，要格外小心循环和递归，一不小心就会把CPU当成无限燃料来烧。

除了这些程序逻辑层面的问题，还有一个容易被忽视的资源耗尽类型，那就是“连接数”或者“文件句柄”枯竭。

我曾经接手过一个在线客服系统的维护工作。这个系统运行了几个月都很稳定，突然有一天，客服人员反馈说登录不进去了，页面显示连接错误。我检查了CPU和内存，都很正常。磁盘也没满。带宽也足够。我就觉得奇怪了。然后我试着用SSH登录服务器，发现可以登录。进去之后，我用一个命令查看了系统允许的最大进程数和当前打开的进程数。结果发现，这个系统上运行了很多个PHP-FPM子进程，而且状态都是“活跃”的。我用netstat命令一查，发现有成千上万个TCP连接处于“TIME_WAIT”状态，这些连接实际上已经关闭了，但是操作系统还没有回收资源。每一个TIME_WAIT的连接都要占用一个文件描述符。当文件描述符的数量达到系统限制之后，程序就无法再创建新的连接了，所以客服登录不进去。

临时解决办法是调整了系统的内核参数，缩短了TIME_WAIT的超时时间，让连接能够更快地被回收。同时，也提高了文件描述符的上限。长期解决方案是修改应用的连接池配置，让程序复用已有的数据库连接和API连接，而不是每次请求都创建新的连接。改完之后，这个客服系统再也没有出现过因为连接数超限而无法登录的情况。

讲到这里，我想说一个重要的观点：面对资源耗尽，很多人第一反应是“升级配置”，觉得多花点钱把服务器加大就行了。这种想法不能说完全错，但往往是治标不治本。如果是因为程序有内存泄漏，你从4G内存升级到8G，最多也就是从一个月崩溃一次变成两个月崩溃一次，问题并没有真正解决。如果是因为磁盘写满了日志，你从40G升级到100G，也只是把爆炸的时间往后推迟了一些，总有一天还是会满。真正的高手，一定会去找到那个最根本的原因，从代码或者配置层面把它解决掉。

我记得有一个电商网站的案例特别典型。他们的大促期间，服务器总是卡死，技术团队每次的处理办法就是临时重启服务器，或者在云控制台上把实例规格升一档。升完之后，能撑过这一次大促，但下一次大促又会出事。后来他们终于下决心彻底排查，发现问题出在数据库查询上。有一个商品列表页的SQL语句没有加索引，每次查询都要扫描整张表，随着商品数量从几百增长到几万，这个查询消耗的CPU和内存呈几何级数增长。大促期间并发一高，数据库就直接挂掉。他们加了索引之后，同样的查询消耗的资源下降了百分之九十。从那以后，服务器再也没有因为这个问题卡死过。你看，一个索引解决的问题，比升级多少次配置都管用。

那么，当我们遇到云服务器资源耗尽的时候，到底应该遵循一个什么样的处理流程呢?我想把我自己常用的这套方法分享出来。

第一步，先判断是偶发性的还是持续性的。如果只是突然卡了一下马上就恢复了，可能是某个短时任务导致的，不用太紧张。如果是持续卡顿或者周期性卡顿，比如每天固定时间变慢，那就需要认真对待了。

第二步，登录云控制台，查看监控图表。现在的云服务商都提供了比较细致的监控数据，能看到CPU、内存、磁盘、网络的历史曲线。通过曲线可以大致判断是从什么时候开始出问题的，问题发生前后有没有什么变化。

第三步，如果还能通过SSH或者远程终端登录到服务器里边，就立刻执行几个关键命令。用uptime看平均负载，用free -h看内存和swap的使用情况，用df -h看磁盘空间，用iostat -x 1看磁盘IO的繁忙程度，用sar -n DEV 1看网络流量。哪个指标异常，就顺着哪个指标往下查。

第四步，找到消耗资源的“罪魁祸首”。CPU高就用top看哪个进程占CPU多，内存高就用ps aux --sort=-%mem看内存占用排序，磁盘满就用du -sh *一层层找大目录，IO高就用iotop看哪个进程在疯狂读写。

第五步，根据不同的情况采取不同的急救措施。如果是恶意进程或者失控进程，直接kill掉。如果是磁盘满了，清理无用的文件。如果是内存不足，可以考虑重启一些非关键的服务来释放内存。如果情况非常严重，服务器完全没法操作了，那就不要犹豫，直接在云控制台执行重启操作。重启虽然粗暴，但是往往能让服务先恢复起来。

第六步，服务恢复之后，一定不要忘了复盘。把当时的日志和监控数据保存下来，分析为什么会资源耗尽。是代码问题就改代码，是配置问题就调配置，是攻击问题就加强安全，是业务增长带来的正常压力，那就考虑优化架构或者合理的资源扩展。

第七步，根据复盘的结果，建立预防机制。比如设置监控告警，资源使用率达到警戒线就发通知。比如自动化清理日志，避免磁盘被写满。比如对关键进程设置资源限制，用cgroup或者systemd的limit功能，防止单个进程把整个系统的资源都吃完。比如定期进行压力测试，看看系统在什么情况下会资源耗尽，提前做准备。

我还有一个很深的体会，那就是不要把所有的期望都放在“事后处理”上。更聪明的做法是“防患于未然”。我认识一个运维做得特别好的团队，他们每个月都会做一次“资源容量评估”，看看过去一个月CPU、内存、磁盘、带宽的增长趋势，预测未来多久会达到瓶颈。他们会在资源使用率达到百分之七十的时候就开始准备扩容或者优化，所以从来没有出现过因为资源耗尽而导致的故障。

另外，养成良好的编码习惯和部署习惯也非常重要。比如写代码的时候注意关闭文件句柄，注意释放数据库连接，注意使用缓存减少重复计算，注意分批处理大数据集。部署的时候，不要把所有的服务都塞在一台云主机上，按照业务模块或者按照数据流向拆分成多个小的服务，每个服务有自己的资源配置，互相隔离，一个出问题不会拖垮全部。

我想用一个比较有画面感的例子来结束今天的分享。去年有一位做在线教育的小团队负责人找到我，说他们的直播课系统一到上课时间就卡。我帮他看了以后发现，每次上课前半小时，系统会生成大量的课件预览图，这个生成过程吃掉了CPU和IO，导致直播推流和聊天室服务都受到了影响。他们的处理方式很聪明，不是去升级主服务器，而是加了一台专门用于生成预览图的辅助服务器，直播主服务器不再承担这个任务。从那以后，就算同时上十门课，系统也流畅得很。

这个故事告诉我们，处理云服务器资源耗尽，有时候不需要多么高深的技术，需要的是一种思维方式：看清楚问题出在哪个环节，然后针对性地解决。不要被表面的症状迷惑，也不要急于下结论。

总结一下今天的内容。云服务器资源耗尽，按照类型可以分成CPU耗尽、内存耗尽、磁盘空间耗尽、磁盘IO耗尽、网络带宽耗尽、进程和文件描述符耗尽等。每一种类型有不同的表现和排查方法。面对资源耗尽，我们的应对策略应该是：快速识别类型，找到耗尽的根源，采用适当的急救措施恢复服务，然后深入分析原因并彻底解决。事后建立监控告警和自动化的资源管理机制，从源头上减少资源耗尽的发生概率。记住，升级配置是最后的选项，不是首选。绝大多数资源耗尽的问题，都可以通过优化代码、调整配置、拆分服务等方式来解决，性价比更高，效果也更持久。