Linux(2)---记录一次线上服务 CPU 100%的排查过程

【Linux(2)---记录一次线上服务 CPU 100%的排查过程】的更多相关文章

Linux(2)---记录一次线上服务 CPU 100%的排查过程

Linux(2)---记录一次线上服务 CPU 100%的排查过程当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢是通过日志输出错误信息: 得知websocket时时重新连接的信息,然后找到原因解决了. 当然这里幸好能通过日志大致分析出原因那么我就在思考如果日志没有告诉任何信息但线上CPU还是接近100%那么如何排查呢.所以学习了下排查过程. 通过查阅资料并实践后,这里总结了两种办法.第一种博客满天飞的方法…

记一次线上服务CPU 100%的处理过程

告警正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误.查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%. 赶紧从会上下来,SSH登录服务器,使用 top 命令查看,几个Java进程CPU占用达到180%,190%,这几个Java进程对应同一个业务服务的几个Pod(或容器). 定位使用 docker stats 命令查看本节点容器资源使用情况,对占用CPU很高的容器使用 docker exec -it <容器ID> bash…

线上服务 CPU 100%？一键定位 so easy！

转自: https://my.oschina.net/leejun2005/blog/1524687 摘要: 本文主要针对 Java 服务而言 0.背景经常做后端服务开发的同学,或多或少都遇到过 CPU 负载特别高的问题.尤其是在周末或大半夜,突然群里有人反馈线上机器负载特别高,不熟悉定位流程和思路的同学可能登上服务器一通手忙脚乱,定位过程百转千回. 对此,也有不少同学曾经整理过相关流程或方法论,类似把大象放进冰箱要几步,传统的方案一般是4步: top oder by with P:…

原创记录一次线上Mysql慢查询问题排查过程

背景前段时间收到运维反馈,线上Mysql数据库凌晨时候出现慢查询的报警,并把原始sql发了过来: --去除了业务含义的sql update test_user set a=1 where id=1; 表数据量200W左右,不是很大,而且是根据主键更新. 问题排查排查Mysql数据库我看到sql后第一反应就是是不是数据库出问题了,每个小时都有业务,偏偏白天业务高峰时间段正常,凌晨业务量很少时候出问题,让运维先检查了数据库的状态,反馈是数据库正常. 排查业务代码(第一次) 这块业务代码比较复杂…

线上服务的FGC问题排查，看这篇就够了！

线上服务的GC问题,是Java程序非常典型的一类问题,非常考验工程师排查问题的能力.同时,几乎是面试必考题,但是能真正答好此题的人并不多,要么原理没吃透,要么缺乏实战经验. 过去半年时间里,我们的广告系统出现了多次和GC相关的线上问题,有Full GC过于频繁的,有Young GC耗时过长的,这些问题带来的影响是:GC过程中的程序卡顿,进一步导致服务超时从而影响到广告收入. 这篇文章,我将以一个FGC频繁的线上案例作为引子,详细介绍下GC的排查过程,另外会结合GC的运行原理给出一份实践指南,希望…

线上服务的FGC问题排查

转载:https://blog.csdn.net/g6U8W7p06dCO99fQ3/article/details/106088467 线上服务的GC问题,是Java程序非常典型的一类问题,非常考验工程师排查问题的能力.同时,几乎是面试必考题,但是能真正答好此题的人并不多,要么原理没吃透,要么缺乏实战经验. 过去半年时间里,我们的广告系统出现了多次和GC相关的线上问题,有Full GC过于频繁的,有Young GC耗时过长的,这些问题带来的影响是:GC过程中的程序卡顿,进一步导致服务超时从而影…