云服务器资源耗尽如何处理?从“卡死”到“满血复活”的完整攻略

那是一个黑色星期五的下午，我正悠闲地喝着咖啡，突然监控系统发出刺耳的警报。打开一看，云主机的CPU使用率已经飙升到了百分之九十九，内存也所剩无几，网站打开比蜗牛还慢，用户投诉像潮水一样涌来。我赶紧登录服务器，敲个命令都要反应好几秒，感觉整个系统随时都会彻底瘫痪。这种“资源耗尽”的感觉，就像一台老电脑开了几十个大型软件，动一下就卡住，让人心急如焚。

云服务器资源耗尽，说白了就是它的“体力”跟不上了。CPU、内存、磁盘空间、网络带宽、进程数量或者文件描述符，这些资源中的任何一个被耗尽，都会导致服务器响应变慢甚至完全无响应。不同于连接超时那种网络问题，资源耗尽是你明明能连上服务器，但它就像陷在泥潭里一样，动弹不得。今天我就把这些年处理过的各种资源耗尽案例掰开揉碎，从现象识别到应急处理，再到长期优化，一步步说清楚。

我们先来给资源耗尽分分类。云服务器的资源大致可以分为这么几类：CPU资源、内存资源、磁盘空间、磁盘IO、网络带宽、进程数和文件描述符。每一类资源被耗尽，表现出来的症状都不太一样，处理方式也各有侧重。从实际经验来看，CPU和内存的问题最为常见，磁盘空间次之，但每一种都值得认真对待。

第一类，CPU资源耗尽。

CPU就像是服务器的大脑，负责处理所有的计算任务。当CPU使用率长时间接近百分之一百时，服务器就会变得极其迟钝。你敲一个命令，可能要等十几秒才有反应;网站页面的加载时间从几百毫秒变成了几十秒甚至直接超时。这种情况通常由几种原因造成。要么是某个进程出现了死循环，疯狂占用CPU;要么是业务量突然增长，原来的CPU配置不够用了;要么是服务器被植入了挖矿木马，攻击者在拿你的CPU挖虚拟货币。

我处理过一个非常典型的挖矿木马案例。客户的云主机突然变得特别慢，CPU使用率一直居高不下。我用top命令查看，发现一个名字叫做“kdevtmpfsi”的进程占用了几乎所有的CPU。这个进程看起来像是系统进程，但我从来没见过这个名字。我又看了一下它的启动路径，发现是在/tmp目录下的一个隐藏文件夹里。很明显，这是挖矿木马。我立刻用kill命令终止了进程，然后删除了相关的文件和定时任务。但是没过多久，进程又自动启动了。原来木马程序还设置了定时任务，每隔几分钟就会重新下载和运行。我花了半个小时，才把所有后门和计划任务清理干净，然后修改了SSH密码和密钥，还安装了安全软件来防止再次被入侵。这个经历让我深刻体会到，CPU异常飙升时，第一件事就是看看是哪个进程在作怪。

还有一种情况不是恶意程序，而是程序本身有缺陷。比如一个开发者在代码里写了一个while循环，循环条件永远为真，并且循环内部没有sleep或者任何会让出CPU的操作。这个程序一旦运行，就会吃掉一个CPU核心的所有时间片。如果是单核的云主机，整个系统就卡死了。处理方法就是用top找到这个高CPU进程的PID，用kill命令终止它，然后去修复代码。如果是业务量增长导致的CPU不足，那就要考虑优化程序算法、增加缓存、或者升级CPU配置了。

当CPU资源耗尽导致服务器卡得连命令都敲不动时，怎么处理?这时候可以通过云控制台的远程管理终端登录，这个终端通常不经过网络协议栈，在系统极度卡顿的情况下也可能连上。如果连这个都进不去，那就只能强制重启了。虽然重启不算是优雅的解决方案，但在紧急情况下，先恢复服务再说。

第二类，内存资源耗尽。

内存是服务器用来临时存放运行中数据的空间。当物理内存被用光时，Linux系统会启用一个叫做swap的机制，把内存里不常用的数据临时写到磁盘上，以释放一些物理内存。但是磁盘的速度比内存慢成千上万倍，一旦系统开始频繁使用swap，整个服务器的性能就会急剧下降。更糟糕的情况是，当一个进程申请的内存超过了物理内存加swap的总和时，Linux内核会启动OOM Killer，根据一定的规则杀掉一些进程来释放内存。如果你的关键进程被干掉了，服务就挂了。

内存耗尽的常见原因有几种。最常见的是内存泄漏，程序申请了内存使用完之后没有正确释放，随着时间的积累，内存占用越来越高，直到耗尽。还有一种原因是程序一次性加载了过多的数据，比如一个PHP脚本获取数据库里所有用户的信息，如果用户有几十万，这个脚本可能会消耗几百兆甚至几个G的内存。另外，每个并发请求都会占用一部分内存，当并发量过大时，内存也会被吃光。

我记得一个深刻的案例，一个论坛网站每到晚上高峰期就变得奇慢无比，有时候甚至直接报错打不开。查看监控发现，内存使用率在白天慢慢爬升，到晚上八九点就接近百分之百，然后网站就挂了。他们每天晚上都要重启一次服务器来恢复。我帮他排查了之后，发现是PHP-FPM进程池配置不当，每个进程的内存限制设置得过大，而且进程数量也设置得太多。最关键的还是程序里有一个缓存类，会把用户的会话数据保存在内存中，而且从来没有过期清理的逻辑。这些会话数据越积越多，最终把内存撑爆了。解决办法有几个方面：修改PHP-FPM配置，减少同时运行的进程数量，给每个进程设置最大请求数，让进程在处理一定数量的请求后自动销毁并释放内存;修复程序里的缓存逻辑，设置合理的过期时间;引入Redis或者Memcached这类专业的内存缓存服务，并且给它们配置最大内存上限。做完这些之后，服务器连续运行了一个月，内存使用率一直稳定在百分之七十左右，再也没有出现过耗尽的状况。

当你怀疑内存耗尽时，可以用free -h命令查看内存和swap的使用情况。如果看到available的值很小，而swap used的值很大，那就说明物理内存不够用了，系统正在拼命使用swap。这时候可以用top或者ps aux --sort=-%mem命令，找出占用内存最多的进程。如果是正常业务进程，可以考虑优化或者增加内存;如果是异常进程，就终止它。注意，当OOM Killer启动后，你可能会发现某些进程莫名其妙地消失了，这时候可以查看系统日志，用dmesg | grep -i oom或者查看/var/log/messages，能看到OOM Killer的记录。

第三类，磁盘空间耗尽。

磁盘空间耗尽这个问题，看似简单，但很多人都会栽跟头。当磁盘分区写满时，会出现各种各样奇怪的现象。数据库可能会拒绝写入新数据，报错“磁盘已满”;网站可能无法上传图片，因为临时目录写不进去;日志文件无法继续记录，导致排查问题时没有线索;甚至有些服务会因为无法写入pid文件或者锁文件而启动失败。更诡异的是，即使你删除了文件，如果你的程序还保持着这个文件的句柄没有释放，磁盘空间可能并不会立刻释放，因为操作系统认为这个文件还在被使用，只是目录入口被删除了而已。

我遇到过一个电商网站的故障，用户突然无法下单了，但是产品浏览是正常的。技术人员查了很久都没找到原因，因为错误日志里没有明显的报错。最后他们发现订单提交时，程序要往一个日志文件里写入调试信息，而这个日志文件所在的磁盘分区已经百分之百满了，所以写入操作失败，程序又没有处理好这个异常，导致订单无法生成。应急处理的方法是，找到磁盘上最大的那些文件，判断哪些是可以删除的。通常可以清理的包括：旧的系统日志文件、应用程序的访问日志和错误日志、上传到服务器的临时文件、软件包缓存等等。用du和sort命令可以找出占用空间最大的目录和文件。那次他们清理了几十个G的旧日志，磁盘瞬间释放了大量空间，订单功能立刻恢复了。

但是要注意，如果程序正在向一个日志文件写入，你直接rm删除这个文件，磁盘空间可能不会马上释放，因为进程的句柄还开着。正确的做法是，先通过lsof命令找到打开了这个文件的进程ID，然后清空文件而不是删除，比如执行> /path/to/logfile，这样既清空了内容，又不会影响进程的写入。或者优雅地重启应用程序，重建文件句柄。所以定期配置日志轮转工具，比如logrotate，是非常必要的，它能自动压缩、归档和删除旧日志，避免日志无限制增长。

还有一种情况是磁盘的inode耗尽了。inode是用来存储文件元信息的，每个文件或目录都需要一个inode。如果磁盘上有大量的小文件，比如缓存文件或者临时文件，即使磁盘空间还有剩余，inode也有可能先用完。现象就是创建新文件时提示“设备上没有空间”，但用df -h看磁盘还有剩余空间。这时候需要用df -i来查看inode的使用率。清理大量小文件就可以释放inode。

第四类，磁盘IO耗尽。

磁盘IO指的是磁盘的读写能力。当有大量的读写请求同时涌向磁盘时，磁盘会忙不过来，导致读写请求排队等待。这时候你会感觉到系统反应迟钝，即使CPU和内存都很空闲。这种情况常见于数据库密集型的应用，比如频繁的查询和写入，或者某个程序在做大量的文件读写操作。

我曾经帮一家数据分析公司处理过一个问题。他们的数据库查询有时候快有时候慢，慢的时候一个简单的查询都要好几秒。通过监控发现，在慢的时候磁盘的IO等待指标特别高。进一步分析发现，他们的数据库服务器上同时运行了一个每天凌晨的备份任务，这个任务会全量扫描数据目录进行压缩备份，导致磁盘读IO飙升。同时在线用户也在正常查询，这些查询也需要读磁盘。两者叠加，磁盘就忙不过来了。解决办法是把备份任务迁移到从库上执行，不要在主库上运行，这样就隔离了磁盘IO压力。对于无法迁移的情况，可以考虑使用更快的磁盘类型，或者优化查询语句，减少不必要的全表扫描。

第五类，网络带宽耗尽。

网络带宽是云主机的出口和入口流量能力。当你的服务被大量访问，或者遭受了DDoS攻击，或者服务器成了肉鸡向外发送大量数据时，带宽就会被占满。带宽耗尽的表现是，你的网站访问非常慢，但服务器的CPU和内存都很正常。用ifconfig或者nload这些命令可以看到网卡的流量已经达到了上限。

有个做视频分享的创业者遇到了这个问题。他的视频刚开始在一些社交平台上传播，播放量几天内增长了十几倍。由于视频文件比较大，每个用户播放都要占用不小的带宽。他的云主机带宽配额很快就被占满了，新用户看视频非常卡，经常缓冲。他一开始不知道怎么回事，以为是服务器配置太低，后来发现监控里网络出口流量一直维持在带宽上限附近。解决方案不是简单地升级带宽因为成本太高，而是采用了对象存储来存放视频文件，云主机只处理播放页面和接口，视频文件直接通过对象存储的CDN加速分发，这样云主机本身的带宽压力就解除了。对于带宽被恶意攻击占满的情况，则需要开启云服务商提供的DDoS防护服务，把攻击流量在云端清洗掉。

第六类，进程数和文件描述符耗尽。

这两类资源相对隐蔽，但同样会导致服务异常。Linux系统对单个用户和整个系统的最大进程数量是有限制的。如果一个程序频繁创建子进程却不回收，导致僵尸进程累积，最终会超过进程数上限，无法创建新的进程。同样，每个程序打开的文件、网络连接都需要消耗文件描述符。如果你的程序没有正确关闭数据库连接、网络连接或者文件句柄，就会泄漏文件描述符，达到上限后无法打开新的文件或者发起新的网络连接。

我处理过这样一个问题。一个Java应用运行几天后就变得不稳定，有时候报错说“打开的文件太多”。查看进程的文件描述符数量，已经达到了系统限制。因为代码里有一个Bug，每次请求都会打开一个文件输入流读取配置，但是没有在finally块中关闭。随着时间的推移，越来越多的泄漏句柄没有被回收。修复的办法就是在代码中使用try-with-resources语法，或者确保finally中关闭了资源。同时也可以临时调整系统限制，用ulimit -n命令增加单进程的最大文件描述符数，但这只是治标不治本，最终还是要修复代码。

当云服务器资源耗尽的警报响起时，我们该怎么处理?我把应急响应的步骤整理了一下，希望能帮大家建立一套流程。

第一步，快速确认是哪种资源耗尽。登录云控制台查看监控图表，看CPU、内存、磁盘、带宽哪一个指标异常。如果没有监控，就登录服务器用命令查看。free -h看内存，df -h看磁盘，df -i看inode，top看CPU和负载，iftop或nload看带宽，ulimit -a看各种限制。

第二步，如果能定位到具体的异常进程，比如某个陌生进程占了高CPU，或者某个已知进程内存泄漏，就用kill命令终止它。必要的时候，把服务重启一下。在资源耗尽导致系统卡顿时，kill命令可能也要等很久，这时候就要考虑强制重启整个云主机了。在控制台执行重启操作，大部分情况下都能暂时恢复服务。

第三步，服务恢复后，不要以为万事大吉了。要去分析根本原因。查看系统日志和应用程序日志，回顾最近是否有代码变更或者配置变更。如果是被攻击了，要排查入侵途径，修补漏洞，加强安全措施。如果是业务增长导致的资源不足，要考虑优化程序、增加缓存、或者提升配置。但提升配置只是解决眼前问题，长远来看架构优化才是根本。

第四步，建立或者完善监控和告警机制。在资源使用率达到一定阈值时就提前告警，不要等到耗尽了才被动处理。比如CPU连续五分钟超过百分之八十就发警报，磁盘使用率超过百分之八十五就发警报。设置合理的告警规则，能够让你在真正耗尽之前就有时间从容处理。

我还想强调一个非常实用的习惯，那就是定期巡检和归档。每周或者每月定个时间，登录服务器看看磁盘使用趋势，看看有没有异常的日志文件在疯长，看看有没有内存使用不断爬升的进程。把日常维护做好，很多资源耗尽的问题就被消灭在了萌芽状态。

最后，我们用一个完整的案例来结束今天的分享。有一个做在线考试的平台，每个月末是考试高峰期，经常出现服务器卡顿、用户提交试卷失败的问题。我来帮他们排查。第一次出问题时，发现是CPU跑满了，原因是考试结束后系统需要计算所有考生的成绩，这个计算任务用了一个很慢的循环算法，把所有数据都放在内存里处理。临时解决是把计算任务延迟到凌晨执行，避开用户高峰期。之后我帮他们优化了算法，改用分批处理和数据库聚合查询，CPU占用从百分之百降到了百分之二十。第二个月又出现了问题，这次是磁盘写满了，因为所有考生的答题记录都写在了同一个大表里，没有做分区归档。临时清理了三个月前的数据释放了空间。后来他们每天自动把历史数据迁移到归档表，磁盘使用率一直稳定在百分之六十以下。第三个月，系统又出现了连接缓慢的问题，这次是数据库的最大连接数不够用了，因为每个考试进程都开启了一个长连接，高峰期达到了上限。解决方案是在应用层使用连接池，重用数据库连接，而不是每次新建。经过这三轮优化，这个在线考试平台再也没有出现过资源耗尽导致服务不可用的情况。

总结一下，云服务器资源耗尽并不可怕，只要我们能够快速识别出是哪种资源出了问题，采取对应的应急措施恢复服务，然后深入分析根本原因，从代码、配置、架构等多个层面进行优化，就能从根本上解决问题。同时，建立完善的监控预警机制，养成定期巡检的习惯，可以让你在这些问题还没有真正影响到用户之前就发现并处理掉。服务器资源就像我们的体力和精力，透支了就要及时调整和补充，平时也要注意保养和维护。