记一次服务器负载飙高排查过程

记一次服务器负载飙高排查过程

问题描述

在前天呢,我们公司的三台部署着php项目的线上服务器A、B、C,其中一台服务器A出现了CPU负载飙高,与其他两台服务器相差好几倍,并且在前天之前都没有出现过这么高的情况,所以需要针对问题进行排查
A服务器负载异常第一天
A服务负载异常第二天

排查过程

首先第一件事,找日志,看看异常的时候到底在干什么,找到服务器top日志,找到对应负载上升和下降的连续时间的日志(下面截图已做处理)
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
上面三个截图对应的是第一个负载图顶点附近的日志,可以看到,28688这个进程占用了大量的CPU

继续查看日志,A服务器在第二天负载突增的时间点,也是这个28688,截图我就不放了,那看起来就是这个进程的原因?

遗憾的是,这个28688的进程是一个监控程序,运维在几

### CPU 使用率过问题排查与解决 当系统出现 CPU 使用率过的问题时,通常需要结合系统监控工具与线程级分析手段进行定位。排查过程中,应重点关注用户态(user)、系统态(system)和进程/线程的 CPU 占用情况,以区分是应用逻辑问题、系统调用问题还是资源竞争导致的负载。 #### 系统级排查 使用 `top` 命令可以快速识别 CPU 使用率较的进程,具体操作如下: ```shell top ``` 在输出结果中找到 CPU 使用率较的进程 PID。如果发现 system 占用率过,而系统中存在大量 IO 操作(如文件服务器、数据库服务器),则可能是 IO 密集型任务导致。若 system 占比持续较(例如超过 20%)且无明显 IO 活动,则可能涉及内核或驱动模块异常 [^1]。 #### 进程与线程级排查 找到 CPU 使用率的进程后,进一步分析其内部线程的执行情况。使用以下命令查看具体线程的 CPU 占用情况: ```shell ps H -eo pid,tid,%cpu | grep <PID> ``` 随后将线程 ID(TID)转换为十六进制格式,以便与 `jstack` 输出匹配: ```shell printf '%x' <TID> ``` 最后使用 `jstack` 查看线程堆栈信息,结合十六进制线程 ID 进行定位: ```shell jstack <PID> | grep <HEX_TID> -A100 ``` 此方法可识别具体是哪个方法或代码段导致了 CPU 使用率的异常升 [^2]。 #### 日志与性能分析工具辅助 除了命令行工具外,还可以借助 APM(应用性能管理)工具如 SkyWalking、Pinpoint 或 JProfiler 等对线程执行路径、方法调用耗时进行可视化分析。这些工具能够提供更直观的性能瓶颈定位。 #### 常见问题与优化方向 - **线程死循环或频繁 GC**:线程中存在无限循环或资源泄漏可能导致 CPU 持续负载。 - **同步竞争**:多个线程频繁争夺锁资源可能导致大量上下文切换和阻塞。 - **算法复杂度过**:不合理的算法实现可能导致计算密集型操作持续占用 CPU。 - **外部调用阻塞**:频繁调用外部服务或数据库操作未合理异步化也可能间接导致 CPU 负载。 优化建议包括重构热点代码、引入缓存机制、合理使用线程池、减少锁粒度、避免不必要的同步操作等。 ---
评论 3
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值