服务器CPU和内存占满通常意味着系统资源耗尽,这会导致业务中断、响应缓慢甚至系统崩溃，必须立即排查进程异常、资源泄漏或遭受攻击等根本原因，并采取限制、扩容或优化代码等措施来恢复服务稳定性，面对这一紧急状况，运维人员需保持冷静，依据系统化的排查路径，从表象深入内核，迅速定位问题源头并实施精准处置。
核心诊断：快速定位资源瓶颈
当服务器出现卡顿或无响应时,首要任务是登录系统获取实时状态，由于系统负载过高，常规SSH连接可能受阻，此时建议通过控制台VNC或带外管理接口进行访问。
-
查看系统负载与进程状态
使用top或htop命令是诊断的第一步，观察load average数值，如果其值超过逻辑CPU核心数的70%，则表明系统处于高负荷状态。- CPU分析：在
top界面中，按下P键按CPU使用率排序，重点关注%CPU列数值持续居高不下的进程，若单进程占用超过90%，极有可能是程序陷入死循环或存在计算密集型任务。 - 内存分析：按下
M键按内存使用率排序，观察%MEM列，若某个进程（如Java应用、MySQL数据库）占用了物理内存的80%以上，且不释放，可能存在内存泄漏。
- CPU分析：在
-
检查僵尸进程与线程锁
有时CPU占用率高并非业务进程导致，而是僵尸进程或内核线程所致。- 使用
ps aux | grep Z筛选状态为Z的僵尸进程，这些进程虽然不占用CPU计算资源，但会占用进程表项，大量堆积会影响系统调度。 - 若
top中显示大量D状态（不可中断睡眠）进程，通常意味着I/O瓶颈，导致进程等待磁盘响应而挂起，进而拖垮整体性能。
- 使用
深度剖析：CPU与内存耗尽的四大诱因
解决服务器CPU和内存占满问题,不能仅靠重启，必须深究其因。
-
应用程序代码缺陷
这是导致资源耗尽最常见的原因。- 死循环与复杂算法：代码中存在未正确退出的循环逻辑，或算法复杂度过高（如O(n^3)级别的大数据处理），会导致CPU满载。
- 内存泄漏：程序在申请内存后无法释放已不再使用的内存空间，在Java、Python等带有垃圾回收机制的语言中，若对象引用未被正确置空，或非托管语言（如C/C++）中
malloc后未free，内存占用会随时间线性增长，最终触发OOM Killer，导致进程被强制终止。
-
并发请求过载与CC攻击
服务器硬件资源有限，当并发连接数超过阈值时，系统会因频繁的上下文切换而耗尽CPU。- 突发流量：营销活动或热点事件导致正常流量激增，超出服务器承载极限。
- 恶意攻击：DDoS攻击中的CC攻击（Challenge Collapsar）会模拟大量真实用户请求，持续占用服务器连接池和计算资源，导致CPU长期处于100%状态，正常用户无法访问。
-
数据库查询效率低下
数据库往往是服务器性能的短板。
- 慢SQL语句：缺乏索引的
SELECT或复杂的关联查询，会导致数据库服务器CPU飙升。 - 全表扫描：在大数据表中执行全表扫描，不仅消耗大量CPU周期，还会占用内存缓存，导致磁盘I/O激增，形成性能恶性循环。
- 慢SQL语句：缺乏索引的
-
系统配置与内核参数不当
默认的系统配置往往无法适应高并发生产环境。- 文件句柄限制：Linux默认的
open files限制较低，高并发下会报“Too many open files”错误，导致进程卡死。 - TCP连接参数：
tcp_tw_reuse、tcp_tw_recycle等参数配置不当，会导致大量TIME_WAIT状态的连接堆积，占用内核资源。
- 文件句柄限制：Linux默认的
专业解决方案：从应急到根治
针对上述诊断结果,需采取分级治理策略。
应急止损：快速恢复业务可用
在业务受影响的紧急时刻,首要目标是恢复服务，而非彻底解决问题。
- 终止异常进程
确认非核心业务进程占用资源过高时，使用kill -9 [PID]强制终止，若是核心业务进程，需评估是否可以通过重启服务释放资源。 - 服务降级与限流
通过Nginx或网关层配置限流策略，限制每秒请求数（QPS），牺牲部分非核心流量以保全核心业务，开启服务降级开关，关闭非关键功能模块，减少资源消耗。 - 临时扩容
在云环境下，利用弹性伸缩服务快速增加临时节点，通过负载均衡分担流量压力。
根治优化：构建稳定运行环境
应急处理后,需进行深层次的优化，防止问题复发。
-
代码层面优化
- 代码审查与重构：修复死循环逻辑，优化算法复杂度，引入代码质量检测工具，扫描潜在的内存泄漏风险。
- 内存管理：对于Java应用，调整JVM堆内存参数（
-Xms,-Xmx），避免频繁Full GC导致的CPU飙升；对于C/C++应用，使用Valgrind工具检测内存泄漏。
-
数据库性能调优
- 索引优化：分析慢查询日志，为高频查询字段添加索引，避免全表扫描。
- 读写分离与缓存：引入Redis缓存热点数据，减少数据库直接查询压力；配置主从复制，实现读写分离。
-
架构与安全加固
- WAF防护：部署Web应用防火墙，识别并拦截CC攻击流量，防止恶意请求耗尽服务器资源。
- 资源监控告警：部署Prometheus+Grafana或Zabbix监控系统，设置CPU、内存使用率阈值告警，当使用率超过80%时，自动发送通知，实现故障早发现、早处理。
预防机制：建立长效运维体系
解决当前问题只是第一步,建立预防机制才能确保长治久安。
- 定期压力测试
在业务上线前及重大活动前，使用JMeter或LoadRunner进行压力测试，摸清服务器性能上限，找出瓶颈点。 - 容器化部署
采用Docker+Kubernetes架构，利用容器的资源限制功能防止单个应用耗尽宿主机资源，并利用K8s的自动扩缩容能力应对流量波动。 - 日志分析常态化
定期分析系统日志和应用日志，识别异常访问模式和潜在错误，将隐患消除在萌芽状态。
相关问答
问：服务器CPU和内存占满时，为什么无法通过SSH连接？
答：当服务器资源耗尽时，系统会优先将CPU时间片分配给已运行的高优先级进程或内核任务，SSH服务进程需要CPU和内存资源来处理加密握手和创建会话，如果系统处于极度繁忙状态（如Load Average远超核心数），新进的SSH连接请求会因为得不到及时响应而超时断开，此时建议使用服务器提供商提供的VNC控制台或带外管理口进行连接，这些方式不依赖操作系统内部的网络服务，可以直接访问系统终端。
问：如何区分服务器负载高是由于CPU密集型任务还是I/O密集型任务造成的？
答：可以通过top命令或vmstat命令进行判断，在top命令中，观察%id（idle）数值，若该值很低甚至为0，说明CPU正在满负荷计算，属于CPU密集型，若%id数值较高（如80%以上），但系统负载依然很高，且%wa数值较高，说明CPU在等待磁盘I/O操作完成，此时属于I/O密集型任务导致的负载高，针对CPU密集型需优化计算逻辑或升级CPU，针对I/O密集型则需优化磁盘读写、升级硬盘或优化数据库查询。
如果您在服务器运维过程中遇到过类似的资源瓶颈问题,欢迎在评论区分享您的排查思路与解决方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/162658.html
