排查服务假死步骤(源机资源存在)

最新推荐文章于 2023-09-23 18:36:44 发布
最新推荐文章于 2023-09-23 18:36:44 发布
阅读量330 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： java 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/sunRest/article/details/127730446
本文介绍了一种排查服务器上高耗资源问题的方法。首先使用top命令来查看整体资源消耗情况，然后通过top-H1命令定位到具体的高耗资源线程。最后利用jstack命令检查堆内存日志，以确定是否存在大量资源未被释放或发生死锁等问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1.top命令查看当前机器耗资源情况
在这里插入图片描述
2.找出高耗资源线程查看
top -H 1
在这里插入图片描述
3.jstack 查看堆内存日志,是否存在大量资源未被释放或者死锁等情况
jstack 1|grep 1
在这里插入图片描述

微服务假死，一段时间后自动恢复，如何排查处理
**My Coding Family**
01-12 546
🏆本文收录于专栏，主要记录项目实战过程中所遇到的Bug或因后果及提供真实有效的解决方案，希望能够助你一臂之力，帮你早日登顶实现财富自由🚀；同时，欢迎大家！持续更新中，up！up！up！！
k8s节点假死排查记录
weixin_43737711的博客
11-13 2617
k8s节点假死排查记录 k8s节点假死排查记录 说明：节点指部署了k8s相关组件的虚拟机 问题描述 应用方反映在kibana上搜索不到最新日志，未被fluent收集，查看fluent容器的日志 ，报错：can’t create Thread: Resource temporarily unavailable"，在master节点查询节点状态正常，ssh登录节点，报错：fork faild cannot allocate memory 解决并分析问题，找出原因 快速重启节点恢复应用，然后根据出现的报错内容排查
线上服务假死排查
阿杰
03-30 516
3月26号晚上9点上线之后，3月27早上服务假死，无法访问，暂时重启服务，3月29号下午3点服务再次假死，重启服务，3月30日上午8点左右查看服务假死，3月30号下午开始排查 日志查询 日志排查 通过日志分析 锁定了是这个sql导致的查询了3百万条数据，很可能就是这个问题导致服务假死 通过分析sql，知道了是脚手架内嵌的monitor检测的模块，monotor数据库有13个G的数据， 紧急解决方案就是暂时关闭monitor，清空monotor旧数据。 具体问题仍在分析之中 设置服务自启动 ...
服务器假死笔记、内存溢出、日志按时间统计排查
enthan809882的博客
09-23 1405
服务器假死笔记、内存溢出、日志按时间统计排查
记一次线上服务假死排查过程
烤鸭的世界我们不懂的博客
01-12 815
大家好，我是烤鸭：      最近线上问题有点多啊，分享一个服务假死的排查过程。 问题描述 9点10分，收到进程无响应报警(一共6台机器，有1台出现)，后来又有1台出现。 排查思路 首先确认是否误报或者网络抖动，登陆服务器查看进程存在。 查看cat监控，发现gc次数和gc耗时都升高，基本确认是oom导致的。 当时由于优先处理问题，服务重启后，没办法找到oom源头了(进程命令包含oom记录，但是没生成oom日志)。 -XX:+HeapDumpOnOutOfM
Spring Boot2 服务假死排查分析记录
lovelichao12的专栏
06-08 3495
项目部署上线后经过一段时间的运行，发现服务进程正常，可接口请求不通，重启服务就会正常，重启隔断时间还会出现，一般这种情况称之为服务假死。
线上程序假死如何定位呢？
qq_26093341的博客
03-07 1148
分享下我一年中遇到的线上程序假死问题，都是如何排查的 一下分析过程，假设你脱离了apm工具，或者像阿里巴巴提供的工具 其实分析过程挺简单的，基本都是因为线程watting 1、一般先看程序日志是否正常，如果日志没有任何打印 2、curl "127.0.0.1:port"看看服务是否可以正常访问，再ss -s看看连接数什么的 如果无法访问 3、接着用 top 或者 jps -v 或者 ...
SpringBoot线上服务假死：非资源耗尽的故障排查
"本文档探讨了SpringBoot线上服务在CPU和内存正常的...本文提供了一套完整的线上SpringBoot服务假死排查流程，强调了在非典型情况下识别和解决问题的重要性，对于开发人员和运维人员来说，是一份实用的故障排除指南。
服务总是莫名假死如何排查
最新发布
03-25
</think>### 服务假死排查步骤 #### 1. **初步检查系统资源状态** - **监控CPU/内存/磁盘IO**: 使用 `top`（Linux）或 `htop` 查看实时资源占用。若发现CPU持续接近 $100\%$，可能是线程死循环或资源竞争（如...
springcloud服务假死
weixin_43558902的博客
10-30 1万+
记一次springcloud服务假死排查过程 前段时间一直在排查线上服务的假死问题，首先，我们服务用的是springcloud微服务架构，注册中心是eureka，每个微服务都2个实例的，由于一个服务实例假死导致网关负载到假死的那个实例从而导致访问超时，先说说假死的服务处于什么状态吧，这个服务仍然会向注册中心发送心跳，浏览器打开http://172.18.44.120:8761/eureka/ins...
oracle后台服务假死,服务假死问题解决过程实记（一）——问题发现篇
weixin_36027743的博客
04-12 680
一、前言自三月六日起，笔者所在业务组的开发环境上出现了若干次服务假死，页面请求无响应的现象。由于笔者在三月六日之前，对 JVM, Tomcat，以及数据库连接池没有丝毫调优经验，所以从三月六日开始的所有与解决该问题的过程，都会记录到本文，以记录并纪念笔者的第一次服务调优经历。链接：二、03.06 记 Tomcat 的一次假死问题解决经历注：本文是一个前序，记录问题出现的现象，以及猜测的原因。本文中...
服务假死问题解决过程实记（一）——问题发现篇
琦小虾的代码世界
05-01 1万+
一、前言 自三月六日起，笔者所在业务组的开发环境上出现了若干次服务假死，页面请求无响应的现象。由于笔者在三月六日之前，对 JVM, Tomcat，以及数据库连接池没有丝毫调优经验，所以从三月六日开始的所有与解决该问题的过程，都会记录到本文，以记录并纪念笔者的第一次服务调优经历。 链接： 二、03.06 记 Tomcat 的一次假死问题解决经历 注： 本文是一个前序，记录问题出现的现象...
旧版本Druid回收连接引发的'recyle error'
呢喃北上的博客
09-30 9085
公司官网上的心跳交易不执行了，按理说是定时任务做的，怎么会不执行呢，遂去查看日志发现： [ERROR] [2018-09-25 20:30:37,933] (AgtForwardServiceImpl.java,31) - 转发数据推送异常：{}nested exception is org.apache.ibatis.exceptions.PersistenceException: ### E...
java服务程序假死（进程存在但请求无响应）的几种原因
热门推荐
liaomingwu的专栏
06-10 2万+
java服务程序假死（进程存在但请求无响应）的几种原因
（一）使用Presto中的Druid报错：recyle error 和 abandon connection 来深入研究Druid的底层实现原理
王伟的博客
03-18 4205
（1）本文主要是使用Druid作为Presto的连接池，所遇到的问题，以及的错误和解决方法 先看一下我的Druid的配置 - druidDataSource.setTestWhileIdle(true); - druidDataSource.setTestOnBorrow(true); - druidDataSource.setTestOnReturn(false); - druid...
服务器运维---服务器假死
johnrui的博客
07-12 2355
在线上环境中，经常会出现服务卡顿，造成数据无法更新、获取的现象。对于这种现象现，个人一自身的工作经历总结如下： 一、定时任务时间间隔短，造成服务卡顿，线程池爆满，线程锁无法释放，进而服务崩溃： 设定的时间间隔内，程序未执行完成，又开始进行下一轮的程序执行，这样的幂等性执行最终造成线程池爆满，服务崩溃； 解决办法：根据业务量计算程序执行一次耗时，科学合理设定时间间隔； 二、定时任务，程序中存在HTTP请求，但是请求地址已经改变或者因为其他原因无法访问，这样累计起来的无响应请...
服务假死现象原因排查
xi_yu_yue的博客
06-01 1504
1.修改日志的级别，已达到看到更多的信息 2.重新启动看控制台日志，最后一行附近就是问题所在 3.看改服务注册的zk是否正常 --------------------------总结------------------- 了解日志的级别 ...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值