4、线程pid转化为进制 printf '0x%x' 线程pid ? 5、查看线程堆栈 jstack 进程pid | grep 转化后的线程pid ? 6、io情况查看: vmstat: ?
,内存占用情况 [root@localhost ~]# top 2 平均加载时间 [root@localhost ~]# uptime 16:45:18 up 18 days, 45 min, 4 15 14 71 0 0 1 0 1024 2612088 16 633616 0 0 0 10 2846 9886 10 7 83 0 0 4 0.00 0.00 0.00 78.89 5 查看当前系统进程 [root@localhost ~]# ps -ef|grep java root 2564 1 4 00:16:04 java -jar insight-serve-v4-1.0-beta.jar 5 root 2583 1 0 11:40 ? 2531(进程id) Linux 3.10.0-862.el7.x86_64 (localhost.localdomain) 2019年10月07日 _x86_64_ (4
查看占用资源信息以及pid top 2、查看pid下绑定线程 top -Hp pid1(进程id) 3、拿到需要查询的线程pid,转换成16进制 printf '%x' pid2(线程id) ==> 6a4 #6a4为输出结果 4、通过jstack讲java信息输出到文本 jstack pid1(进程id) > t.txt 如果jstack报错,请查看 jstack不存在 5、在t.txt文件中查找6a4 vim t.txt /6a4 6、然后找到自己的collectorl业务代码层具体行数去分析
线上问题排查方法 1 OOM问题 1.1 堆内存OOM 1.2 栈内存OOM 1.3 栈内存溢出 1.4 GC OOM 1.5 元空间OOM 2 CPU100%问题 3 接口超时问题 4 索引失效问题 如果生产环境中,出现了这个问题,可以排查一下递归调用是否正常,有可能出现了无限递归的情况。 4.增加锁等待超时处理。 5.增加监控和分析 6 磁盘问题 磁盘问题一般有两种: 磁盘坏了 磁盘空间不足 如果是磁盘空间不足。 如果MQ生产者没有批量发送消息,则需要排查MQ消费者的业务逻辑中,哪些地方出现了性能问题,需要做代码优化。 如果用正常数据,可能测不出问题,但一旦出现异常数据,就会立即出现死循环。 4.3 无限递归 建议写递归方法时,设定一个递归的深度,比如:分类最大等级有4级,则深度可以设置为4。
前言 最近经常有小伙伴问我,遇到了线上问题要如何快速排查。 这非常考验工作经验了。 有些问题你以前遇到,如果再遇到类似的问题,就能很快排查出导致问题的原因。 但如果某个问题你是第一次遇到,心中可能会有点无从下手的感觉。 这篇文章总结了,我之前遇到过的一些线上问题排查思路,希望对你会有所帮助。 2 CPU100%问题 线上服务出现CPU100%问题,也很常见。 出现这个问题,是由于服务长时间占用CPU资源导致的。 4 索引失效问题 不知道你有没有遇到过,生成环境明明创建了索引,但数据库在执行SQL的过程中,索引竟然失效了。 由于索引失效,让之前原本很快的操作,一下子变得很慢,影响了接口的性能。 增加监控和分析 6 磁盘问题 服务器磁盘问题是众多线上问题中,最好排查的了。 磁盘问题一般有两种: 磁盘坏了 磁盘空间不足 如果是磁盘坏了,运维一般在短时间内,很难及时修复好。
若用户反馈线上服务请求无响应,可以按照以下步骤进行排查。 一、确认服务器内存使用情况 执行free命令,看看服务器内存是否正常。 0x00007f266c5ce320, 0x00007f266c6a3ca0, 0x00007f266c6e9790, 0x00007f266c9297f0, 0x00007f266c92d740, 0x00007f266c95d4a0 163258 3918192 java.lang.String 3: 40481 3562328 java.lang.reflect.Method 4: 七、分析内存溢出问题 确定了是哪一个节点有问题,那么先把节点的流量切走。 如果第六步没分析出来是什么导致内存溢出,可以按如下步骤排查。 1. ,一般会列出有问题的对象; 选择有问题的对象,右键Merge Shortest Paths to GC Roots ---> exclude weak references; 然后再Java Basics
线上问题排查总结 Cpu飙高可能的原因 CAS自旋 没有控制自旋次数;乐观锁 死循环----cpu飙高的问题;控制循环次数 云服务器redis被注入挖矿程序;端口像公网暴露;Redis端口不要被外网访问 } },"晓果冻").start(); } } 指定线程名称 创建新的线程的时候最好指定它的名称不然默认的都是Thread-0、Thread-1这样的,指定名称,在排查问题时也方便在直接在项目 中搜索是哪段代码出了问题。 Linux环境下排查cpu飙高的问题 先模拟一种死锁的情况,让cpu飙高 /** * @author 晓果冻 * @version 1.0 * @date 2021/6/23 7:45 */ public 进程号改变是因为我又重启了程序 通过打印出的信息可以在代码中搜索晓果冻线程名来查询到底是哪段代码出了问题
线上问题排查神器 Arthas 之前介绍过 BTrace,线上问题排查神器 BTrace 的使用,也说它是线上问题排查神器。都是神器,但今天这个也很厉害,是不是更厉害不好说,但是使用起来非常简单。 如果你用 BTrace 的话,需要事先写好探测脚本,然后上传到需要排查问题的服务器,然后执行命令。比方说获取某个方法的参数、返回值、异常等。 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现! 是否有一个全局视角来查看系统的运行状况? 正式交互开始,就到了大展拳脚的时候了,线上出现的问题基本上都可以找到合适的命令。 下面简单的介绍几个,就是为了演示一下使用方式。 另外,无论是 Arthas 还是 BTrace ,都是用来排查单机服务问题的,也就是应用内部的代码、性能问题,如果要排查不同服务之间的调用问题,那就是另一个维度上的事儿了。就需要 APM 的帮助了。
jmap实战 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lQojpBgg-1587553128990)(CF4BE02FA6C941DEB23E041B50C4FAE7
因此,快速、准确地排查并解决线上问题变得至关重要。 本文将介绍一些高效的线上问题排查方法,帮助您在面对线上问题时,迅速定位并解决问题。 通过这些策略的实施,您将能够提高线上问题的解决速度,减少对业务的影响,并提高用户满意度。 请继续阅读,以了解更多关于如何排查线上问题的详细信息。 本文是链式风格,循序渐进! 四、排查经验 4.1 我的经验 知道了问题的现象之后,就需要根据经验排查可能是哪块出了问题了。 话虽如此,这也只是我这几年的定位问题的模式,也未必对,也不知道有没有缺少了哪一个重要的环节。 五、总结 线上问题排查是运维人员的重要职责之一,它涉及到对系统性能、稳定性、安全性等方面的监控和排查。 通过问题定位、分析、解决和预防等步骤的实践经验总结出一些有效的排查方法。同时需要不断学习和提升自己的技能水平以更好地应对各种线上问题。
作者:霞落满天 第一部分 是我以前公司的一则正式案例: 第二部分 是我另一个博客上写的主要是最近发现大家问的比较多就写了此文 第一部分 线上真实故障案例 下面是一个老系统,代码写的有点问题导致出现这样一个 线上问题当时的CPU占用情况如图所示: ? 下面是当时java内存dump ? ? ? ? ? 需要使用MAT工具分析jmap dump的内存 使用jmap和MAT分析JVM堆内存 3.jstat jstat -gcutil pid 250毫秒一次采样4次 ? windows用jdk自带工具jps、jstack找出性能最差的代码 【windows下的比较实用】 JVM 发生 OOM 的 8 种原因、及解决办法 面试官问:平时碰到系统CPU飙高和频繁GC,你会怎么排查 4.waiting on condition 如果该线程本身就应该处于等待状态,比如用户创建的线程池中处于空闲状态的线程,那么这种线程的堆栈信息中是不会包含用户自定义的类的。
https://blog.csdn.net/wh211212/article/details/84866727 java线上服务问题排查 1、业务日志相关 如果应用系统出现异常,一般都会在业务日志中体现 一般通过下面几个工具都能定位出问题。 .html jstat命令查看jvm的GC情况 (以Linux为例):https://www.cnblogs.com/yjd_hycf_space/p/7755633.html java进程CPU过高排查 3.4、gc时间过长 参考:http://www.oracle.com/technetwork/cn/articles/java/g1gc-1984535-zhs.html 4、Server本身问题 排查:CPU、Memory、IO、Network 常用命令:top/htop 、free、iostat/iotop、netstat/ss 关注网络连接: 查看tcp各个状态数量:netstat
前言 针对各种常见的线上问题,梳理下排查思路。 测试环境搭建 既然要模拟排查线上问题,就不能使用本地环境。 至少是个 Linux 操作系统,最好还是个纯粹的 Java 环境。 : docker run -it -v your/path/floder/:/folder/ openjdk:8-jdk /bin/bash 在挂载数据卷下,编写 Main.java 文件(之后模拟的线上问题代码会编写在此文件 通过这一个小例子,可以发现当线上出现 CPU 过高问题时,可以先通过 top 命令定位到问题进程的 id(如果是微服务,即当前服务器对应的 java 进程很少,百分百就确定是某个应用时,也可以通过 jps 一般对于线上问题,都是采用这样的步骤: 先将机器和集群隔离开来 马上调用 jmap -dump 命令将 Java 堆的现场情况保存下来 对问题机器中的进程进行重启,恢复上线 将保存下来的 dump 文件导到本地进行分析 但使用 Java VisualVM 会占用较多资源,所以一般线上环境中不会使用,实在要在线定位问题的话,生产上通常选择前面说到的 Arthas + 原生命令(主要是 jmap 命令)的方式进行。
前言 本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知,免得在遇到实际问题时手忙脚乱。 只不过这里先提示一下。 在线上应急过程中要记住,只有一个总体目标:尽快恢复服务,消除影响。 不管处于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题不一定能够定位问题,也不一定有完美的解决方案,也许是通过经验判断,也许是预设开关等,但都可能让我们达到快速恢复的目的,然后保留部分现场,再去定位问题 show-busy-java-threads -p <指定的Java进程Id> show-busy-java-threads -c <要显示的线程栈数> 方法 C: arthas thread 阿里开源的arthas现在已经几乎包揽了我们线上排查问题的工作 sc:查看 jvm 已加载类信息,可用于排查 jar 包冲突 sm:查看 jvm 已加载类的方法信息 jad:反编译 jvm 加载类信息,排查代码逻辑没执行原因 logger:查看logger信息,更新
技术同学需要经常登录线上的服务器进行操作,58到家架构部/运维部/58速运技术部,联合进行了一次线上操作与线上问题排查实战演练,同学们反馈有收获,特将实战演练的问题和答案公布出来,希望对大家也有帮助。 1.2.3.4' suyun.2017-06-26.log.bz2 | wc -l less suyun.2017-06-26.log.bz2 | grep '10.37.9.11' | wc -l 说明:线上日志文件一般以 /opt/backup/shenjian.tar.gz \ -exclude /opt/web/suyun_web/logs \ /opt/web/suyun_web 说明:这个命令线上应用较为频繁 p' server.conf sed -e '/^#/d' server.conf grep -v "^#" server.conf 七、磁盘IO异常排查 问题:磁盘IO异常如何排查,类似写入慢或当前使用率较高 第二步:如果此时各项写入指标都很低,基本没有大的写入操作,则需要排查磁盘自身。
BTrace 是什么 BTrace 是检查和解决线上的问题的杀器,BTrace 可以通过编写脚本的方式,获取程序执行过程中的一切信息,并且,注意了,不用重启服务,是的,不用重启服务。 可以看到刚刚执行的 java 进程为 10860 4. 按ctrl + c ,会给出退出提示,再按 1 退出 使用场景 BTrace 是一个事后工具,所谓事后工具就是在服务已经上线了,但是发现存在以下问题的时候,可以用 BTrace。 例如要匹配继承或实现了 com.kite.base 的接口或基类的,只要在类前加上 + 号就可以了,例如 @OnMethod(clazz="+com.kite.base", method="doSome") 4. 注意问题 如果出现 Unable to open socket file: target process not responding or HotSpot VM not loaded 这个问题,可能的原因是执行
出现该问题的原因有: 目标服务器防火墙配置更改,已关闭目标端口。 生产者(接口提供方)服务挂掉。 排查思路: 检查目标服务器防火墙配置,开启目标端口,重启防火墙 检查目标服务器服务状态 解决过程: 查看服务器调用者日志,当出现接口拒绝连接时,可参考以下方案: 使用ping IP命令查看目标服务器是否宕机
技术同学需要经常登录线上的服务器进行操作,58到家架构部/运维部/58速运技术部,联合进行了一次线上操作与线上问题排查实战演练,同学们反馈有收获,特将实战演练的问题和答案公布出来,希望对大家也有帮助。 四、查询线程数 问题: 查询服务器运行服务的总线程数,当机器线程数超报警阀值时,能快速查出相关进程及线程信息。 p' server.conf sed -e '/^#/d' server.conf grep -v "^#" server.conf 七、磁盘IO异常排查 问题:磁盘IO异常如何排查,类似写入慢或当前使用率较高 第二步:如果此时各项写入指标都很低,基本没有大的写入操作,则需要排查磁盘自身。 转自:架构师之路——线上操作与线上问题排查实战
Parallel GC with 4 thread(s) //当前使用的GC方式(并行GC) Heap Configuration: //堆内存配置 MinHeapFreeRatio FGCT - (从应用启动算起,到采样时的) Full GC所用时间(秒) GCT - (从应用启动算起,到采样时的) Yong GC + Full GC的总时间 值得一提的是G1垃圾回收器,在大堆(>4G
不同环境下的问题排查 开发环境 可以随意使用任何熟悉的工具排查。 生产环境 排查难度最大: 生产环境权限管控严格,一般不允许调试工具从远程附加进程 生产环境出现问题要求以恢复为先,难以给你充足时间排查问题。 组件的问题,可以从以下几个方面排查: 排查组件所在主机是否有问题; 排查组件进程基本情况,观察各种监控指标; 查看组件的日志输出,特别是错误日志; 进入组件控制台,使用一些命令查看其运作情况。 第四,考虑资源限制类问题。观察各种曲线指标,如果发现曲线慢慢上升然后稳定在一个水平线上,那么一般就是资源达到了限制或瓶颈。 第六,排查网络问题要考虑三个方面,到底是客户端问题,还是服务端问题,还是传输问题。