5、查看线程堆栈 jstack 进程pid | grep 转化后的线程pid ? 6、io情况查看: vmstat: ? “r”:运行中;“b”:io block等待。
bi bo in cs us sy id wa st 3 0 1024 2612868 16 633524 0 0 3 16 3 5 83.33 17时14分48秒 3 14.07 0.00 7.04 0.00 0.00 0.00 0.00 0.00 0.00 78.89 5 00:16:04 java -jar insight-serve-v4-1.0-beta.jar 5 root 2583 1 0 11:40 ? 00:01:11 java -jar insight-cloud-1.0.jar 5 root 5644 1 0 14:35 ? 00:00:39 java -jar insight-iec-server-1.0.jar 5 root 6976 22153 0 17:30 pts/2 00:00:00 grep
id) ==> 6a4 #6a4为输出结果 4、通过jstack讲java信息输出到文本 jstack pid1(进程id) > t.txt 如果jstack报错,请查看 jstack不存在 5、
线上问题排查方法 1 OOM问题 1.1 堆内存OOM 1.2 栈内存OOM 1.3 栈内存溢出 1.4 GC OOM 1.5 元空间OOM 2 CPU100%问题 3 接口超时问题 4 索引失效问题 5 死锁问题 6 磁盘问题 7 MQ消息积压问题 8 调用接口报错 8.1 返回401 8.2 返回403 8.3 返回404 8.4 返回405 8.5 返回500 8.6 返回502 如果生产环境中,出现了这个问题,可以排查一下递归调用是否正常,有可能出现了无限递归的情况。 5 死锁问题 死锁是指两个或多个事务在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,这些事务将无法继续向前推进。 如果MQ生产者没有批量发送消息,则需要排查MQ消费者的业务逻辑中,哪些地方出现了性能问题,需要做代码优化。
前言 最近经常有小伙伴问我,遇到了线上问题要如何快速排查。 这非常考验工作经验了。 有些问题你以前遇到,如果再遇到类似的问题,就能很快排查出导致问题的原因。 但如果某个问题你是第一次遇到,心中可能会有点无从下手的感觉。 这篇文章总结了,我之前遇到过的一些线上问题排查思路,希望对你会有所帮助。 2 CPU100%问题 线上服务出现CPU100%问题,也很常见。 出现这个问题,是由于服务长时间占用CPU资源导致的。 5 死锁问题 如果你使用的是MySQL数据库,在生产环境肯定遇到死锁问题。 死锁是指两个或多个事务在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,这些事务将无法继续向前推进。 增加监控和分析 6 磁盘问题 服务器磁盘问题是众多线上问题中,最好排查的了。 磁盘问题一般有两种: 磁盘坏了 磁盘空间不足 如果是磁盘坏了,运维一般在短时间内,很难及时修复好。
若用户反馈线上服务请求无响应,可以按照以下步骤进行排查。 一、确认服务器内存使用情况 执行free命令,看看服务器内存是否正常。 文件系统 容量 已用 可用 已用% 挂载点 xxxxxxxx 7.8G 0 7.8G 5% /xx … 3562328 java.lang.reflect.Method 4: 28014 2844936 [Ljava.lang.Object; 5: 七、分析内存溢出问题 确定了是哪一个节点有问题,那么先把节点的流量切走。 如果第六步没分析出来是什么导致内存溢出,可以按如下步骤排查。 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,线下无法重现! 是否有一个全局视角来查看系统的运行状况? 表示 5 秒钟输出一次,-c 60 表示 60 秒输出一次。 另外,无论是 Arthas 还是 BTrace ,都是用来排查单机服务问题的,也就是应用内部的代码、性能问题,如果要排查不同服务之间的调用问题,那就是另一个维度上的事儿了。就需要 APM 的帮助了。
正在和同事在外面吃饭,突然钉钉报警,有一个服务的机器内存飙到百分之90%多。和同事大概聊了一下说是队列累积,机器消费不过来,具体原因也没有深问,又一同事,说看一下是那个对象占的内存,使用jmap,jstat。当时我也在旁边围观,由于之前有看过,我就说jmap在生产环境敢使用吗?
因此,快速、准确地排查并解决线上问题变得至关重要。 本文将介绍一些高效的线上问题排查方法,帮助您在面对线上问题时,迅速定位并解决问题。 通过这些策略的实施,您将能够提高线上问题的解决速度,减少对业务的影响,并提高用户满意度。 请继续阅读,以了解更多关于如何排查线上问题的详细信息。 本文是链式风格,循序渐进! 四、排查经验 4.1 我的经验 知道了问题的现象之后,就需要根据经验排查可能是哪块出了问题了。 话虽如此,这也只是我这几年的定位问题的模式,也未必对,也不知道有没有缺少了哪一个重要的环节。 五、总结 线上问题排查是运维人员的重要职责之一,它涉及到对系统性能、稳定性、安全性等方面的监控和排查。 通过问题定位、分析、解决和预防等步骤的实践经验总结出一些有效的排查方法。同时需要不断学习和提升自己的技能水平以更好地应对各种线上问题。
作者:霞落满天 第一部分 是我以前公司的一则正式案例: 第二部分 是我另一个博客上写的主要是最近发现大家问的比较多就写了此文 第一部分 线上真实故障案例 下面是一个老系统,代码写的有点问题导致出现这样一个 线上问题当时的CPU占用情况如图所示: ? 下面是当时java内存dump ? ? ? ? ? 需要具体jdk对应的bin/java 参考: gcore 获取程序core dump file 但程序不用退出,gdb 分析core java程序性能分析之thread dump和heap dump 5. windows用jdk自带工具jps、jstack找出性能最差的代码 【windows下的比较实用】 JVM 发生 OOM 的 8 种原因、及解决办法 面试官问:平时碰到系统CPU飙高和频繁GC,你会怎么排查 这些都可以排除掉,而剩下的线程基本上就可以确认是我们要找的有问题的线程。通过其堆栈信息,我们就可以得出具体是在哪个位置的代码导致该线程处于等待状态了。 5.deadlock死锁这种情况基本上很容易发现
https://blog.csdn.net/wh211212/article/details/84866727 java线上服务问题排查 1、业务日志相关 如果应用系统出现异常,一般都会在业务日志中体现 一般通过下面几个工具都能定位出问题。 使用--help,查看命令具体使用 常用: jps -v jstat -gc 118694 500 5 jmap -dump:live,format=b,file=dump.hprof 29170 .html jstat命令查看jvm的GC情况 (以Linux为例):https://www.cnblogs.com/yjd_hycf_space/p/7755633.html java进程CPU过高排查 END {for(a in S) print a, S[a]}' 查看连接某服务端口最多的IP:netstat -na | grep 172.16.70.60:1111 | awk '{print $5}
前言 针对各种常见的线上问题,梳理下排查思路。 测试环境搭建 既然要模拟排查线上问题,就不能使用本地环境。 至少是个 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 # 从所有运行的Java进程中找出最消耗CPU的线程(缺省5个),打印出其线程栈 # 缺省会自动从所有的Java进程中找出最消耗CPU的线程,这样用更方便 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 程序,这里写了一个无限循环,每隔5秒钟输出一组计算结果,内容如下: package kite.lab.utils; /** * NumberUtil * * @author str(result))); jstack(); } } 意思是在执行结束后(location=@Location(Kind.RETURN) 表示执行结束)输出结果和堆栈信息 5. 按ctrl + c ,会给出退出提示,再按 1 退出 使用场景 BTrace 是一个事后工具,所谓事后工具就是在服务已经上线了,但是发现存在以下问题的时候,可以用 BTrace。 注意问题 如果出现 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异常如何排查,类似写入慢或当前使用率较高 第二步:如果此时各项写入指标都很低,基本没有大的写入操作,则需要排查磁盘自身。 转自:架构师之路——线上操作与线上问题排查实战
注:5-16行是堆内存的主要配置,这些参数都可以通过 java -XX:参数名=参数值 来调整其大小,比如: java -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio 无法运行图形化界面,而且也并非所有应用都开启了jmx,所以掌握jstat以命令行方式查看GC情况也是蛮重要的 用法:jstat -gc pid 采样间隔毫秒数,比如: jstat -gc 8544 5000,将每隔5s
不同环境下的问题排查 开发环境 可以随意使用任何熟悉的工具排查。 生产环境 排查难度最大: 生产环境权限管控严格,一般不允许调试工具从远程附加进程 生产环境出现问题要求以恢复为先,难以给你充足时间排查问题。 组件的问题,可以从以下几个方面排查: 排查组件所在主机是否有问题; 排查组件进程基本情况,观察各种监控指标; 查看组件的日志输出,特别是错误日志; 进入组件控制台,使用一些命令查看其运作情况。 这一点我们会在第5篇加餐中详细介绍。 需要注意的是,Java进程对内存的使用不仅仅是堆区,还包括线程使用的内存(线程个数*每一个线程的线程栈)和元数据区。 第四,考虑资源限制类问题。观察各种曲线指标,如果发现曲线慢慢上升然后稳定在一个水平线上,那么一般就是资源达到了限制或瓶颈。