出处: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

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

搞Java开发的,经常会碰到下面两种异常: 1.java.lang.OutOfMemoryError: PermGen space 2.java.lang.OutOfMemoryError: Java heap space 要详细解释这两种异常,需要简单重提下Java内存模型. (友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen) Java内存模型是描述Java程序中各变量(实例域.静态域和数组元素)之间的关系,以及在实

一.摘要 由于硬件问题.系统资源紧缺或者程序本身的BUG,Java服务在线上不可避免地会出现一些“系统性”故障,比如:服务性能明显下降.部分(或所 有)接口超时或卡死等.其中部分故障隐藏颇深,对运维和开发造成长期困扰.笔者根据自己的学习和实践,总结出一套行之有效的“逐步排除”的方法,来快速定 位Java服务线上“系统性”故障. 二.导言 Java语言是广泛使用的语言,它具有跨平台的特性和易学易用的特点,很多服务端应用都采用Java语言开发.由于软件系统本身以及运行环境的复杂 性,Java的应用不

前言 作为在线系统负责人或者是一个技术专家,你可能刚刚接手一个项目就需要处理紧急故障,或者被要求帮忙处理一些紧急的故障,这个时候的情景是: (1)你可能对这个业务仅仅是听说过,而不怎么真正了解: (2)你可能没有这个故障的详细信息,比如可能仅仅是有使用方反馈服务中断了10分钟: (3)你对代码细节还没有仔细研究过. 这个时候该怎么解决问题呢?根据以前的经验,工程师们常常倾向于直接登上服务器检查代码,试图立刻修改问题.或者是把某些可能是问题的配置做修改,但并不是100%确认这就是问题的根本原因.但

BTrace 是什么 BTrace 是检查和解决线上的问题的杀器,BTrace 可以通过编写脚本的方式,获取程序执行过程中的一切信息,并且,注意了,不用重启服务,是的,不用重启服务.写好脚本,直接用命令执行即可,不用动原程序的代码. 原理 总体来说,BTrace 是基于动态字节码修改技术(Hotswap)来实现运行时 java 程序的跟踪和替换.大体的原理可以用下面的公式描述:Client(Java compile api + attach api) + Agent(脚本解析引擎 + ASM +

一.前述 maven 线上部署的话会出现一些问题比如java.lang.ClassNotFoundException或者no main manifest attribute的话,是因为maven 配置里面的问题,本文就这问题给出常用配置. 二.具体部署 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0"

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

前言 在线上的程序中,我们可能经常会碰到程序卡死或者执行很慢的情况,这时候我们希望知道是代码哪里的问题,我们或许迫切希望得到代码运行到哪里了,是哪一步很慢,是否是进入了死循环,或者是否哪一段代码有问题导致程序很慢,或者出现了线程不安全的情况,或者是某些连接数或者打开文件数太多等问题,总之我们想知道程序卡在哪里了,哪块占用了大量的资源. 此时,或许通过线程堆栈的分析就能定位出问题. 如果能深入掌握堆栈分析的技术,很多问题都能迎刃而解,但是线程堆栈分析并不简单,设计到线上的排错问题,需要有一定的知识

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

问题出现:现网CPU飙高,Full GC告警 CGI 服务发布到现网后,现网机器出现了Full GC告警,同时CPU飙高99%.在优先恢复现网服务正常后,开始着手定位Full GC的问题.在现场只能够抓到四个GC线程占用了很高的CPU,无法抓到引发Full GC的线程.查看了服务故障期间的错误日志,发现更多的是由于Full GC引起的问题服务异常日志,无法确定Full GC的根源.为了查找问题的根源,只能从发布本身入手去查问题,发现一次bugfix的提交,有可能触发一个死循环逻辑: for(in

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

CAS (15) - CAS 线上环境 Ehcache Replication 的非稳定重现错误 摘要 线上环境在 EhCache Replication 过程中出现 java.util.ConcurrentModificationException 2016-12-21 14:58:02,022 ERROR [net.sf.ehcache.distribution.RMISynchronousCacheReplicator] - <Exception on replication of put

线上zk做配置管理,最近突然发现两个节点一直在刷下边 java.nio.channels.CancelledKeyException    at gnu.java.nio.SelectionKeyImpl.readyOps(libgcj.so.10)    at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:187)    at java.lang.Thread.run(libgcj.

1.业务日志相关 假设系统出现异常或者业务有异常,首先想到的都是查看业务日志 查看日志工具: less 或者more grep tail -f filename 查看实时的最新内容 ps:切忌vim直接打开大日志文件,由于会直接载入到内存的 2.数据库相关 java应用非常多瓶颈在数据库,一条sql没写好导致慢查询,可能就会带来应用带来致命危害. 假设出现Could not get JDBC Connection .接口响应慢.线程打满等. 须要登录线上库, 查看数据库连接情况:show pro

前一篇介绍了线上应用故障排查之一:高CPU占用,这篇主要分析高内存占用故障的排查. 搞Java开发的,经常会碰到下面两种异常: 1.java.lang.OutOfMemoryError: PermGen space 2.java.lang.OutOfMemoryError: Java heap space 要详细解释这两种异常,需要简单重提下Java内存模型. (友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen) Jav

热更不规范,同事两行泪 背景 C君是一个javaer,最近在开发用户登出接口的时候,不小心把接口参数拼错了 正确的是: /api/v1/user/logout?referrer=www.javaer.com 结果不小心把referrer写成了referre,把字母 r 给丢了,带来的影响就是用户登出后再登陆就无法回到正确的地址,而且代码已经上生产了,这可怎么办?! 偷偷发一版?那么多用户已经在线了,如果被发现就GG了. 下一版再修复?那等待时间也太长了,让BOSS知道也是一首凉凉啊,有可能还的找

线上故障主要2种: CPU利用率很高, 内存占用率很大 一.CPU利用率很高 1. top查询那个进程CPU使用率高 2. 显示进程列表 ps -mp pid -o THREAD,tid,time 找到了耗时最高的线程28802,占用CPU时间快两个小时了! 其次将需要的线程ID转换为16进制格式: printf "%x\n" tid 最后打印线程的堆栈信息: jstack pid |grep tid -A 30 从Thread dump日志中可以找到哪行代码造成CPU使用率高 二.内

原文地址:http://m.blog.csdn.net/article/details?id=43376943 前言:我们的场景并没有像BAT等大型互联网公司里的系统那么复杂,但是基本上也有一定的规模,暂且就认为我们是一个中型互联网系统.但是工具和思路都是差不多的,因为原理是一样的.同时下面提到的命令,具体详细的用法,我想google上已经有足够多的资源了,这里只说思路与方向. 首先我们分析一下服务器构造和操作系统,服务器我们可以简单的分解为CPU.内存.硬盘(其他部件的我们就不考虑了),操作系

前言 在使用 Arthas 之前,当遇到 Java 线上问题时,如 CPU 飙升.负载突高.内存溢出等问题,你需要查命令,查网络,然后 jps.jstack.jmap.jhat.jstat.hprof 等一通操作.最终焦头烂额,还不一定能查出问题所在.而现在,大多数的常见问题你都可以使用 Arthas 轻松定位,迅速解决,及时止损,准时下班. 1.Arthas 介绍 Arthas 是 Alibaba 在 2018 年 9 月开源的 Java 诊断工具.支持 JDK6+, 采用命令行交互模式,提供