一.Arthas简介 Arthas是Alibaba开源的Java诊断工具,功能很强大,它是通过Agent方式来连接运行的Java进程.主要通过交互式来完成功能. https://arthas.aliyun.com/doc/stack.html 首先贴出官方文档,自己使用也不多,主要用于一次线上问题排查 二.运行 java -jar arthas-boot.jar ,运行Arthas 选择要粘附的进程,输入编号即可 使用以下两个命令其中一个查看java程序的进程号ps -efjps 备注:也可以通

JVM 线上故障排查基本操作 CPU 飚高 线上 CPU 飚高问题大家应该都遇到过,那么如何定位问题呢? 思路:首先找到 CPU 飚高的那个 Java 进程,因为你的服务器会有多个 JVM 进程.然后找到那个进程中的 “问题线程”,最后根据线程堆栈信息找到问题代码.最后对代码进行排查. 如何操作呢? 通过 top 命令找到 CPU 消耗最高的进程,并记住进程 ID. 再次通过 top -Hp [进程 ID] 找到 CPU 消耗最高的线程 ID,并记住线程 ID. 通过 JDK 提供的 jstac

JVM 线上故障排查 Linux 1.1 CPU 1.2 内存 1.3 存储 1.4 网络 一.CPU 飚高 寻找原因 二.内存问题排查 三.一般排查问题的方法 四.应用场景举例 4.1 怎么查看某个Java进程里面占用CPU最高的一个线程具体信息? 4.2 统计每种网络状态的数量 4.3 怎么查看哪个进程在用swap 原文地址: 微信公众号: 莫那鲁道 芋道源码:JVM 线上故障排查基本操作 掘金:小姐姐味道:作为高级Java,你应该了解的Linux知识 Linux,关注的是四个元素:内存,c

# 前言 对于后端程序员,特别是 Java 程序员来讲,排查线上问题是不可避免的.各种 CPU 飚高,内存溢出,频繁 GC 等等,这些都是令人头疼的问题.楼主同样也遇到过这些问题,那么,遇到这些问题该如何解决呢? 首先,出现问题,肯定要先定位问题所在,然后分析问题原因,再然后解决问题,最后进行总结,防止下次再次出现. 今天的文章,就如我们的题目一样,讲的是基本操作,也就是一些排查线上问题的基本方法.为什么这么说呢?因为线上问题千奇百怪,就算是身经百战的专家也会遇到棘手的问题,因此不可能在一篇文章

内存问题排查 说完了 CPU 的问题排查,再说说内存的排查,通常,内存的问题就是 GC 的问题,因为 Java 的内存由 GC 管理.有2种情况,一种是内存溢出了,一种是内存没有溢出,但 GC 不健康. 内存溢出的情况可以通过加上 -XX:+HeapDumpOnOutOfMemoryError 参数,该参数作用是:在程序内存溢出时输出 dump 文件. 有了 dump 文件,就可以通过 dump 分析工具进行分析了,比如常用的MAT,Jprofile,jvisualvm 等工具都可以分析,这些工

前言 对于后端程序员,特别是 Java 程序员来讲,排查线上问题是不可避免的.各种 CPU 飚高,内存溢出,频繁 GC 等等,这些都是令人头疼的问题.楼主同样也遇到过这些问题,那么,遇到这些问题该如何解决呢? 首先,出现问题,肯定要先定位问题所在,然后分析问题原因,再然后解决问题,最后进行总结,防止下次再次出现. 本文的排查环境是 Linux. CPU 飚高 问题:线上 CPU 飚高问题大家应该都遇到过,那么如何定位问题呢? 思路:首先找到 CPU 飚高的那个 Java 进程,因为你的服务器会有

前言 本文介绍服务器内运行的 Java 应用产生的 OOM 问题 和 CPU 100% 的问题定位 1. 内存 OOM 问题定位 某Java服务(比如进程id pid 为 3320)出现OOM,常见的原因为: 内存分配的确实小了,而正常业务使用了大量的内存 某个对象被频繁申请,却没有释放,内存不断泄露,导致内存耗尽 某个资源被频繁申请,系统资源耗尽.例如不断创建线程,不断发起网络请求. 资源不够(也是"给的资源耗尽"),资源申请过多导致资源耗尽,资源申请过多不释放导致资源耗尽. 以下为

前言 之前线上有过一两次OOM的问题,但是每次定位问题都有点手足无措的感觉,刚好利用星期天,以测试环境为模版来学习一下Linux常用的几个排查问题的命令. 也可以帮助自己在以后的工作中快速的排查线上问题. jmap命令 jmap -heap pid 输出当前进程 JVM 堆新生代.老年代.持久代等请情况,GC 使用的算法等信息 jmap -histo:live {pid} | head -n 10 输出当前进程内存中所有对象包含的大小 jmap -dump:format=b,file=/usr/

线上问题排查神器 Arthas 之前介绍过 BTrace,线上问题排查神器 BTrace 的使用,也说它是线上问题排查神器.都是神器,但今天这个也很厉害,是不是更厉害不好说,但是使用起来非常简单.如果你用 BTrace 的话,需要事先写好探测脚本,然后上传到需要排查问题的服务器,然后执行命令.比方说获取某个方法的参数.返回值.异常等.而 Athas 方便在不用写脚本,直接用命令行方式就可以,使用它就好像在用安装在服务器上的各种工具一样,比如 top.jps.jmap 等. 他们背后的逻辑都是字节

出处:java:线上问题排查常用手段 一.jmap找出占用内存较大的实例 先给个示例代码: import java.util.ArrayList; import java.util.List; import java.util.concurrent.CountDownLatch; /** * Created by 菩提树下的杨过 on 05/09/2017. */ public class OOMTest { public static void main(String[] args) thro

概述 背景 是不是在实际开发工作当中经常碰到自己写的代码在开发.测试环境行云流水稳得一笔,可一到线上就经常不是缺这个就是少那个反正就是一顿报错抽风似的,线上调试代码又很麻烦,让人头疼得抓狂:而且debug不一定是最高效的方法,遇到线上问题不能debug了怎么办.原先我们Java中我们常用分析问题一般是使用JDK自带或第三方的分析工具如jstat.jmap.jstack. jconsole.visualvm.Java Mission Control.MAT等.但此刻的你没有看错,还有一款神器Art

BTrace简介 GitHub地址:BTrace 下载地址:v1.3.11.3 官方使用教程:Btrace使用教程 使用场景 BTrace 是一个事后工具,所谓事后工具就是在服务已经上线了,但是发现存在以下问题的时候,可以用 BTrace. 比如哪些方法执行太慢,例如监控执行时间超过1s的方法 查看哪些方法调用了 System.gc() ,调用栈是怎样的 查看方法参数或对象属性 哪些方法发生了异常 多说一点,为了更好解决问题,最好还要配合事前准备和进行中监控,事前准备就是埋点嘛,在一些可能出现问

记一次线上bug排查,与各位共同探讨. 概述:使用quartz做的定时任务,正式生产环境有个任务延迟了1小时之久才触发.在这一小时里各种排查找不出问题,直到延迟时间结束了,该任务才珊珊触发.原因主要就是后台有几个5分钟一刷的定时任务,调度器不停的调度后台任务,阻塞了别的任务,出现了问题. 本文主要目的:1.记录排查过程(思路): 2. 分析quartz的线程调度规则: 3. 针对本问题的相关解决方案: 排查过程:1

又一次线上OOM排查经过 最近线上一个服务又出现了频繁Full GC的情况,导致提供的业务经常超时.问题出现非常不稳定,经过两周的时候,终于又捕捉到了一次Full GC,于是联系运维做Heap Dump之后,经过一系列分析,终于解决问题.这次的问题稍微复杂一点,但是也比较有代表性,用到了VisualVM和MAT两个工具,继续记录如下. 现象 这次使用公司的CAT监控平台看到的内存表现如下: 可以看到,具体表现是: 在很长一段时间内(数个小时),New GC比较频繁,Full GC较少(一小时个位

Java架构师线上问题排查,这些命令程序员一定用得到! 线上问题排查,以下场景,你遇到过吗? 一.了解机器连接数情况 问题:1.2.3.4的sshd的监听端口是22,如何统计1.2.3.4的sshd服务各种连接状态(TIME_WAIT/ CLOSE_WAIT/ ESTABLISHED)的连接数. 常见方法: · netstat -n | grep 1.2.3.4:22 | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’ · nets

线上故障主要包括cpu 磁盘 内存 网络等问题 依次排查 1.cpu 1) 先用ps找到进程pid 2) top -H -p pid 找到cpu占用高的线程 3)printf '%x\n' pid 获得16进制的nid 4) jstack pid |grep 'nid' -C5 -color 显示堆栈信息 关注WAITING TIMED_WAITING BLOCKED的信息 2.磁盘 df -hl查看磁盘状态 3.内存 free 检查内存情况 如果内存过多 通过第一步骤找到的异常来分析: Exc

事件回溯 1.7月26日上午11:34,告警邮件提示:tomcat内存使用率连续多次超过90%: 2.开发人员介入排查问题,11:40定位到存在oom问题,申请运维拉取线上tomcat 内存快照dump: 3.开发人员担心服务抗不过下午的业务高峰期,让运维在中午低估期间重启tomcat: 4.11:45,运维人员重启tomcat,内存使用回落. 事件分析 1.根据监控历史数据,发现7月10日后,内存逐步上升,且不能被full GC:怀疑和前一周版本有关,但检查前一周版本内容,不可能导致omm:

作为一个合格的开发人员,不仅要能写得一手还代码,还有一项很重要的技能就是排查问题.这里提到的排查问题不仅仅是在coding的过程中debug等,还包括的就是线上问题的排查.由于在生产环境中,一般没办法debug(其实有些问题,debug也白扯...),所以我们需要借助一些常用命令来查看运行时的具体情况,这些运行时信息包括但不限于运行日志.异常堆栈.堆使用情况.GC情况.JVM参数情况.线程情况等. 给一个系统定位问题的时候,知识.经验是关键,数据是依据,工具是运用知识处理数据的手段.为了便于我们

本文转载自 crossoverJie 的b博客 https://www.cnblogs.com/crossoverJie/p/9282065.html 前言 之前或多或少分享过一些内存模型.对象创建之类的内容,其实大部分人看完都是懵懵懂懂,也不知道这些的实际意义. 直到有一天你会碰到线上奇奇怪怪的问题,如: 线程执行一个任务迟迟没有返回,应用假死. 接口响应缓慢,甚至请求超时. CPU 高负载运行. 这类问题并不像一个空指针.数组越界这样明显好查,这时就需要刚才提到的内存模型.对象创建.线程等相

目录 一.Linux 内存和cpu 网络 磁盘 /proc文件系统 二.JVM Java堆和垃圾收集器 gc日志分析 JVMTI介绍 Attach机制 java自带工具 三.三方工具 jprofile arthas (类似btrace的工具) gceasy 四.实际案例 连接泄漏 String拼接导致内存溢出 堆内存占用过大 CPU占用高问题 aerospike线程阻塞导致内存溢出问题 问题 整体思路:全局观,先从系统层面入手,大致定位方向(内存,cpu,磁盘,网络),然后再去分析具体的进程.