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

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

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

一.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) throws InterruptedExcep

注意:该项目只展示部分功能,如需了解,评论区咨询即可. 1.开发环境 开发语言:Java 后台框架:SSM 前端框架:vue 数据库:MySQL 设计模式:MVC 架构:B/S 源码类型: Web 编译工具:Idea.Eclipse.MyEclipse (选其一) 其他:jdk1.8.Tomcat8.5 .Navicat .Tomcat .node 2.系统的设计与实现 2.1 用户类型 用户角色分为 管理员.教师.学生 这三类用户. 2.2 各角色功能模块 2.2.1 管理员 登录: 修改个人

在上一篇 Docker + node(koa) + nginx + mysql 开发环境搭建,我们进行了本地开发环境搭建 现在我们就来开始线上环境部署 如果本地环境搭建没有什么问题,那么线上部署的配置也就很简单了 我所使用的环境,Linux Mint,命令有不同可以适当更改 目录结构 - compose 新建,线上环境配置 - data - conf - node_modules - static - docker-compose.yml - docker-compose-prod.yml 新建

原文链接:线上BUG:MySQL死锁分析实战 1 线上告警 我们不需要关注截图中得其他信息,只要能看到打印得org.springframework.dao.DeadlockLoserDataAccessException就足够了,就是MySQL发生死锁导致服务抛异常. 关于接口得逻辑,可以大概描述为:C端调用接口查询店铺得追踪事件列表,如果查询为空列表则顺便给初始化,这里的初始化是批量插入一批事件追踪列表,然后再返回,这里要给到一个关于表的信息点:这个表有主键索引和唯一索引. 1.1 云日志&死

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

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

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

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

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

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

[转]原文链接:https://cloud.tencent.com/developer/article/1497826 这是一个十分严重的线上问题 自从最近的某年某月某天起,线上服务开始变得不那么稳定(软病).在高峰期,时常有几台机器的内存持续飙升,并且无法回收,导致服务不可用. 给出监控中GC的采样曲线: 内存使用曲线如下: 如上两张图显示:18:50-19:00的这10分钟阶段里,服务已经处于不可用的状态了.这就导致了:上游服务的超时异常会增加,该台机器会触发熔断. 熔断触发后,这台机器的流

前言 当你兴冲冲地开始运行自己的Java项目时,你是否遇到过如下问题: 程序在稳定运行了,可是实现的功能点了没反应. 为了修复Bug而上线的新版本,上线后发现Bug依然在,却想不通哪里有问题? 想到可能出现问题的地方,却发现那里没打日志,没法在运行中看到问题,只能加了日志输出重新打包--部署--上线 程序功能正常了,可是为啥响应时间这么慢,在哪里出现了问题? 程序不但稳定运行,而且功能完美,但跑了几天或者几周过后,发现响应速度变慢了,是不是内存泄漏了? 以前,你碰到这些问题,解决的办法大多是,修

线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍. 同时例如jstack.jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df.free.top 三连,然后依次jstack.jmap伺候,具体问题具体分析即可. CPU 一般来讲我们首先会排查cpu方面的问题.cpu异常往往还是比较好定位的.原因包括业务逻辑问题(死循环).频繁gc以及上下文切换过多.而最常见的往往是业务逻辑(或者框架逻辑)导致的,可以使

我是风筝,公众号「古时的风筝」,一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农! 文章会收录在 JavaNewBee 中,更有 Java 后端知识图谱,从小白到大牛要走的路都在里面. 这个问题可以说是 Java 面试的高频面试题了,有很多面试官都喜欢问这个问题,问题可能是下面这样的. 线上一台服务器 CPU 使用率100% 了,如果你碰到这样的情况,如何排查并找到问题原因? 这就是一个套路题,所谓套路题就是有标准的套路解法的,掌握了套路,不仅能解决面试官,还能解决问题.不

参考:https://fredal.xin/java-error-check?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 线上故障主要会包括cpu.磁盘.内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍.同时例如jstack.jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df.free.top 三连,然后依次jstack.jmap伺候,具体问题具体分析

一次Java线程池误用(newFixedThreadPool)引发的线上血案和总结 这是一个十分严重的线上问题 自从最近的某年某月某天起,线上服务开始变得不那么稳定(软病).在高峰期,时常有几台机器的内存持续飙升,并且无法回收,导致服务不可用. 给出监控中GC的采样曲线: 内存使用曲线如下: 如上两张图显示:18:50-19:00的这10分钟阶段里,服务已经处于不可用的状态了.这就导致了:上游服务的超时异常会增加,该台机器会触发熔断. 熔断触发后,这台机器的流量会打到其他机器,其他机器发生类似的