1. jps 使用 jps -l -m 获取到当前jvm进程的pid,通过上述命令获取到了服务的进程号 jps(JVM Process Status Tool):显示指定系统内所有的HotSpot虚拟机进程 jps -l -m :参数-l列出机器上所有jvm进程,-m显示出JVM启动时传递给main()的参数 2. jstat 使用 jstat 观察jvm状态,因为是OOM异常,所以我们首先重启机器观察了JVM的运行情况: 我们使用 jstat - gc pid time命令观察GC,发现GC在

写在前面: 最近开始总结内存方面的东西,已经总结以前遇到的一些内存案例分享下,接下来还有几篇,然后是进程/线程相关的,逐渐形成我的知识体系树 如果你有兴趣,可以文章末尾的公众号二维码一起梳理这些信息. OOM问题一般都是人工代码失误, 多数其实在review阶段应该可以排除,本文主要是想记录下内存快照排查OOM的一个过程  场景: 系统的交互安全完全依赖各种加密做(做到了无session,完全WEB无状态,这个设计以后可讲下),故加密变得很重要,但因为有新的加密引入了BouncyCastlePr

  1. jstat -gc pid 可以显示gc的信息,查看gc的次数,及时间. 其中最后五项,分别是young gc的次数,young gc的时间,full gc的次数,full gc的时间,gc的总时间. 2.jstat -gccapacity pid 可以显示,VM内存中三代(young,old,perm)对象的使用和占用大小, 如:PGCMN显示的是最小perm的内存使用量,PGCMX显示的是perm的内存最大使用量, PGC是当前新生成的perm内存占用量,PC是但前perm内存占用

QQA: jstat gcutil 的输出是什么意思 当 Java 程序有性能问题时,尤其是响应时间有突然变化时,最好第一时间查看 GC 的状态.一般用 jstat -gcutil <pid> 1s 来查看,那么它的输出又是什么含义呢? 输出样例 一般会用两种方式调用 jstat,一种看百分比,一种看具体数值(KB). 例如 jstat -gcutil <pid> 1s 会每隔一秒输出内存相关信息,示例输出如下: S0 S1 E O M CCS YGC YGCT FGC FGCT

https://blog.csdn.net/qq_16681169/article/details/53296137 一.出现问题 在前一段时间日常环境很不稳定,前端调用mtop接口会出网络异常或服务不存在的异常.查询了服务器上的HSF会有偶尔挂死的情况,服务器上的接口服务都不可用.于是我们对服务器上的状况进行了排查. 二.排查问题的过程 在这次的问题排查主要是围绕JVM的内存使用情况,生成对象分布情况以及GC情况来讨论的.中间有一些细节一开始存有疑问,迷雾的排除不算太顺利.首先要感谢下基础架构

生产出现oom问题,怎么排查?   1.使用dmesg命令查看系统日志 dmesg |grep -E 'kill|oom|out of memory',可以查看操作系统启动后的系统日志,这里就是查看跟内存溢出相关联的系统日志. 2.这时候,需要启动项目,使用ps命令查看进程 ps -aux|grep java命令查看一下你的java进程,就可以找到你的java进程的进程id. 3.接着使用top命令 top命令显示的结果列表中,会看到%MEM这一列,这里可以看到你的进程可能对内存的使用率特别高.

文章同步发布于github博客地址,阅读效果更佳,欢迎品尝 运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题!虽然jvm调优成熟的工具已经有很多:jconsole.大名鼎鼎的VisualVM,IBM的Memory Analyzer等等,但是在生产环境出现问题的时候,一方面工具的使用会有所限制,另一方面喜欢装X的我们,总喜欢在出现问题的时候在终端输入一些命令来解决.所有的工具几乎都是依赖于jdk的接口和底层的这些命令,研究这些命令的使用也让我们更能了解jvm构成和特性

Story background 回望2018年12月,这也许是程序员们日夜不得安宁的日子,皆因各种前线的系统使用者都需要冲业绩等原因,往往在这个时候会向系统同时写入海量的数据,当我们的应用或者数据库服务器反应不过来的时候,就会产生各种各样诡异的问题,诸如表现出来就是系统变得巨卡无比,无法使用,或者周期性卡顿,令人发指,用户轻则问候系统全家,重则心脏病发.总而言之每天都脑壳疼!归根到底是我们的应用服务器或数据库服务器因为扛不住流量造成的系统BUG问题暴露,诸如OOM等,呈现出机器的三高,这里说的

运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题!虽然jvm调优成熟的工具已经有很多:jconsole.大名鼎鼎的VisualVM,IBM的Memory Analyzer等等,但是在生产环境出现问题的时候,一方面工具的使用会有所限制,另一方面喜欢装X的我们,总喜欢在出现问题的时候在终端输入一些命令来解决.所有的工具几乎都是依赖于jdk的接口和底层的这些命令,研究这些命令的使用也让我们更能了解jvm构成和特性. Sun JDK监控和故障处理命令有jps jstat j

原文地址:https://yq.aliyun.com/articles/69520 我的问题排查工具箱 前言 平时的工作中经常碰到很多疑难问题的处理,在解决问题的同时,有一些工具起到了相当大的作用,在此书写下来,一是作为笔记,可以让自己后续忘记了可快速翻阅,二是分享,希望看到此文的同学们可以拿出自己日常觉得帮助很大的工具,大家一起进步. 闲话不多说,开搞. Linux命令类 tail 最常用的tail -f tail -300f shopbase.log #倒数300行并进入实时监听文件写入模式

问题描述 应用收到频繁Full GC告警 问题排查 登录到对应机器上去,查看GC日志,发现YGC一分钟已经达到了15次,比Full GC还要频繁一些,其中Full GC平均10分钟超过了4次,如下图 使用jstat -gcutil 5280 1000查看实时GC情况,年老代采用的是CMS收集器,发现触发Full GC的原因是年老代占用空间达到指定阈值70%(-XX:CMSInitiatingOccupancyFraction=70). 这时候猜测是某个地方频繁创建对象导致,通过jmap -dum

前言 平时的工作中经常碰到很多疑难问题的处理,在解决问题的同时,有一些工具起到了相当大的作用,在此书写下来,一是作为笔记,可以让自己后续忘记了可快速翻阅,二是分享,希望看到此文的同学们可以拿出自己日常觉得帮助很大的工具,大家一起进步. 闲话不多说,开搞. Linux命令类 tail 最常用的tail -f tail -300f shopbase.log #倒数300行并进入实时监听文件写入模式 grep grep forest f.txt #文件查找 grep forest f.txt cpf.

前言 平时的工作中经常碰到很多疑难问题的处理,在解决问题的同时,有一些工具起到了相当大的作用,在此书写下来,一是作为笔记,可以让自己后续忘记了可快速翻阅,二是分享,希望看到此文的同学们可以拿出自己日常觉得帮助很大的工具,大家一起进步. 闲话不多说,开搞. Linux命令类 tail 最常用的tail -f tail -300f shopbase.log #倒数300行并进入实时监听文件写入模式 grep grep forest f.txt     #文件查找 grep forest f.txt 

JDK 提供了一系列用于监控.诊断 Java 进程的工具,它们在 JDK 安装目录的 bin 目录下,有 jps.jcmd.jstack.jinfo.jmap 等.其中jmc.jconsole.jvisualvm 是 GUI 工具,其他大部分都是命令行工具. cd $JAVA_HOME/bin ls 本篇只是个入门介绍,不涉及深入分析.每一个工具都有它专门的作用,掌握使用方法只是很简单的入门阶段,更重要的是根据工具得到的信息去分析系统存在的问题以及性能瓶颈,每一个工具的使用和分析都可以单独成文.

运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题!虽然jvm调优成熟的工具已经有很多:jconsole.大名鼎鼎的VisualVM,IBM的Memory Analyzer等等,但是在生产环境出现问题的时候,一方面工具的使用会有所限制,另一方面喜欢装X的我们,总喜欢在出现问题的时候在终端输入一些命令来解决.所有的工具几乎都是依赖于jdk的接口和底层的这些命令,研究这些命令的使用也让我们更能了解jvm构成和特性. Sun JDK监控和故障处理命令有jps jstat j

现实企业级Java开发中,有时候我们会碰到下面这些问题: OutOfMemoryError,内存不足 内存泄露 线程死锁 锁争用(Lock Contention) Java进程消耗CPU过高 运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题!虽然jvm调优成熟的工具已经有很多:jconsole.大名鼎鼎的VisualVM,IBM的Memory Analyzer等等,但是在生产环境出现问题的时候,一方面工具的使用会有所限制,另一方面喜欢装X的我们,总喜欢在出现问题的时

| grep 5 -A 3    #上匹配seq 10 | grep 5 -B 3    #下匹配seq 10 | grep 5 -C 3    #上下匹配,平时用这个就妥了cat f.txt | grep -c 'SHOPBASE' awk 1 基础命令 awk '{print $4,$6}' f.txtawk '{print NR,$0}' f.txt cpf.txt    awk '{print FNR,$0}' f.txt cpf.txtawk '{print FNR,FILENAME,

线上服务的GC问题,是Java程序非常典型的一类问题,非常考验工程师排查问题的能力.同时,几乎是面试必考题,但是能真正答好此题的人并不多,要么原理没吃透,要么缺乏实战经验. 过去半年时间里,我们的广告系统出现了多次和GC相关的线上问题,有Full GC过于频繁的,有Young GC耗时过长的,这些问题带来的影响是:GC过程中的程序卡顿,进一步导致服务超时从而影响到广告收入. 这篇文章,我将以一个FGC频繁的线上案例作为引子,详细介绍下GC的排查过程,另外会结合GC的运行原理给出一份实践指南,希望

转载:https://blog.csdn.net/g6U8W7p06dCO99fQ3/article/details/106088467 线上服务的GC问题,是Java程序非常典型的一类问题,非常考验工程师排查问题的能力.同时,几乎是面试必考题,但是能真正答好此题的人并不多,要么原理没吃透,要么缺乏实战经验. 过去半年时间里,我们的广告系统出现了多次和GC相关的线上问题,有Full GC过于频繁的,有Young GC耗时过长的,这些问题带来的影响是:GC过程中的程序卡顿,进一步导致服务超时从而影

一.项目架构 SpringCloud  Dalston.SR1 + SpringBoot 1.5.9 + Mysql +Redis + RabbitMQ 所有的业务模块的应用服务都部署在同一个服务器,且单实例部署,服务器配置4核32G, 二. 原因分析: 自己所负责的data模块这两天OOM较多,导致服务重启: data服务主要业务是报表相关,数仓对接的业务以及多个外部数据相关的小程序的后台,与数据库的交互比较多,业务逻辑相对其他模块较为简单, 第一次:2月25日OOM情况: 由于Redis反序

一.概述: 在实际使用hadoop的过程中,由于涉及到多台服务器.每台机器上可能还有多个服务等.所以当集群环境出现问题时,快速定位到错误出现的地方尤为重要. 在排查错误的过程中,基本上就是通过既有的工具来检测集群的运行时环境.集群日志等来分析导致错误的原因. 二.Java heap: hadoop需要运行在Java运行时环境之上.因此jvm中的内存分配是否处于合理的状态,就是需要检测的一个因素.Java虚拟机中分为多个区域,最值得关注的区域是heap区.heap区的大体划分如下: 创建对象时,会