北京服务器CPU和内存使用率突然爆满，如何排查是攻击还是程序问题?

在北京的服务器运维场景中，CPU和内存使用率突然飙升至接近百分之百，是一个让人瞬间紧张起来的告警。屏幕上的监控曲线几乎垂直上扬，网站响应变得极其缓慢，甚至SSH远程连接都会出现卡顿和断连。此时运维人员面临一个关键抉择：这是遭到了恶意攻击，还是自己开发的程序出现了代码缺陷或者死循环?两种情况的处理路径完全不同，判断失误会导致宝贵的应急时间被白白浪费。在首都北京的众多互联网公司、金融机构和政务系统运维实践中，总结出了一套行之有效的排查方法。

先看CPU与内存的消耗模式差异

当服务器资源爆满时，第一件事不是重启服务，而是观察CPU和内存的消耗曲线形态。程序问题导致的资源耗尽，通常呈现渐进式或周期性的特征。比如内存泄漏，使用率会像爬楼梯一样逐级上升，每次垃圾回收后略有下降但整体趋势向上，最终在某一个时间点越过临界值。而代码中的死循环往往会让CPU使用率瞬间从百分之十跳到百分之九十以上，并且持续保持在高位不回落。

攻击行为导致的资源爆满则呈现出不同的模式。CC攻击会让CPU使用率呈现锯齿状波动，因为攻击者发送的请求有固定的节奏，被防护系统拦截后又发起新的尝试。如果是DDoS攻击中的连接耗尽型变种，服务器的内存使用率会突然暴涨，因为每个恶意连接都会占用一部分内存来维持会话状态。北京一家游戏公司的服务器曾经在凌晨两点遭遇攻击，监控显示内存占用率在短短四分钟内从百分之二十五飙升至百分之九十八，而CPU反而没有明显波动，这种反常的特征让运维团队迅速锁定了SYN Flood攻击。

利用Top命令锁定嫌疑进程

登录到北京服务器后，立即执行top命令，按下大写P键按CPU使用率排序，按下大写M键按内存使用率排序。这一步能快速告诉您是哪个进程在消耗资源。如果是程序问题，排在顶部的通常是您的应用程序进程，比如Java的Tomcat、PHP的FPM进程或者Node.js服务。进程名称清晰可辨，与您部署的业务直接相关。

如果是攻击行为，情况就不同了。您可能会看到大量名称随机的进程，比如一串无意义的字母组合，或者伪装成系统进程名称的恶意进程，像“sshd”但实际上并非真正的SSH守护进程。还有一种常见情况是，Web服务器的进程如Apache或Nginx本身消耗了全部资源，但通过分析其子进程数量会发现异常庞大，正常配置下只有几十个工作进程，而攻击发生时可能出现了数百个甚至上千个HTTP进程在同时运行。

北京某电商平台在一次大促期间遇到了CPU爆满，top命令显示php-fpm进程占用了百分之三百的CPU(多核累加)，但根据监控平台的数据，当时的在线用户数并没有显著增长。进一步查看php-fpm的状态页面，发现活跃进程数量远超正常值，而且每个进程执行的脚本都是同一个搜索接口。这明显不是正常的用户行为，而是针对搜索功能的CC攻击。

查看系统负载与进程状态分布

top命令输出中有一个关键指标是load average，即系统平均负载。这个数值如果远高于CPU核心数，说明有大量进程在排队等待CPU资源。此时按下top界面中的数字1键，可以查看每个CPU核心的使用情况。如果是程序问题导致的死循环，通常会有一到两个核心被完全占满，其他核心相对空闲，因为单线程的死循环只能跑在一个核心上。而攻击行为往往会均匀地占满所有CPU核心，因为攻击者发起的海量请求会被操作系统的负载均衡机制分散到各个核心上。

另外一个观察点是进程状态。使用ps aux命令查看进程状态码，重点关注处于R状态(正在运行或可运行)和D状态(不可中断睡眠，通常是在等待磁盘I/O)的进程数量。如果存在大量D状态进程，说明程序可能在等待数据库响应或者磁盘读写出现了问题。如果存在大量R状态进程但实际业务流量不大，基本可以判定是攻击行为。

分析网络连接与访问日志

当怀疑是攻击时，网络层的特征往往比进程信息更明显。使用netstat -an命令查看当前网络连接，如果发现大量SYN_RECV状态的连接，说明正在遭受SYN Flood攻击。如果发现大量ESTABLISHED连接数量远超正常业务并发量，且连接持续时间很短，不断新建和销毁，这是CC攻击的典型特征。如果发现大量TIME_WAIT连接，可能是程序没有正确关闭数据库连接或者HTTP连接池配置不当，这属于程序问题。

更精确的判断方法是分析Web访问日志。定位到access.log文件，使用命令行统计单位时间内的请求数量。正常的业务高峰期，每秒请求量可能在几十到几百之间。如果发现每秒请求量达到了数千甚至上万，并且来源IP分布广泛，那就是CC攻击。如果请求量不大但每个请求的处理时间特别长，比如从正常的几百毫秒变成了几十秒，那就是程序内部出现了性能瓶颈或者死锁。

北京一家SaaS服务提供商曾经收到CPU爆满告警，登录服务器后发现网络连接数并不高，但每个PHP进程的执行时间都超过了三十秒。运维人员开启了慢日志记录，发现所有慢请求都卡在同一个数据库查询语句上，这条语句关联了五张表并且没有使用索引。这是典型的程序问题，而不是攻击。优化了SQL语句并增加了缓存后，CPU使用率立即降到了正常水平。

检查内存使用细节与交换分区

内存使用率爆满时，还需要区分是内存泄漏还是大流量冲击。使用free -h命令查看内存使用情况，重点关注buff/cache和available这两项。如果used内存很高但available也保持在一定水平，说明系统在合理使用空闲内存做缓存，这通常是正常的。如果available已经趋近于零，并且swap交换分区开始被大量使用，说明物理内存确实已经耗尽。

通过/proc/meminfo文件可以获取更详细的内存分布。如果发现AnonPages匿名页占用异常高，通常是进程分配了大量堆内存，这可能是程序内存泄漏。如果发现Slab内核缓存占用异常高，可能是内核模块出了问题或者遭受了特定类型的攻击。北京一家视频转码服务商曾经遇到内存使用率持续增长，每次重启服务后恢复正常但几天后又复发，通过分析内存分布最终定位到是一个第三方扩展库没有正确释放内存。

采取临时措施与永久解决方案

确认问题性质后，需要立即采取针对性措施。如果是程序问题导致的资源耗尽，最快速恢复服务的方法是重启相关服务进程，而不是重启整个服务器。重启后观察是否立刻复发，如果立刻复发说明程序启动时就触发了缺陷，需要回滚到上一个稳定版本。

如果是攻击行为，立即在高防管理后台启用CC防护策略，设置单IP访问频率限制，开启JS挑战或者验证码验证。同时联系北京机房的技术支持，请求在骨干层进行流量牵引和清洗。如果攻击流量特别大，临时修改业务入口IP也是一种有效的应急手段。

总结

北京服务器CPU和内存使用率突然爆满，排查的核心在于观察资源消耗的模式差异。程序问题通常表现为单一进程异常、渐进式增长或者与特定操作相关的周期性波动，而攻击行为则表现为大量短连接、请求频率远超正常业务量、资源使用率与真实用户数不匹配等特征。从北京本地多个数据中心的实战经验来看，掌握top、netstat、日志分析这三个工具的组合使用，能够在五分钟内完成初步定性。建议运维团队提前写好排查脚本，一键收集进程列表、网络连接状态、CPU占用排行、内存分布等关键信息，这样才能在告警响起时快速做出正确判断，避免因误判而延误恢复时机。