背景,服务器上的一个JAVA服务进程突然挂掉,查看产生了崩溃日志,如下: # Set larger code cache with -XX:ReservedCodeCacheSize= # This output file may be truncated or incomplete. # # Out of Memory Error (os_linux.cpp:2673), pid=28610, tid=139813184919296  日志分析原因很简单,服务器的内存不够用,导致进程崩溃 JA…

参考: http://www.blogjava.net/rosen/archive/2010/05/21/321575.html 1,Java进程内存堆分代: 典型的JVM根据generation(代)来进行GC.一个java程序内存堆有下面几个代: young generation  (年轻代) tenured generation (老年代) permanent generation  (永久代, perm gen),perm gen(或称Non-Heap 非堆)是个异类,稍后会讲到.注意,…

jstat工具特别强大,有众多的可选项,详细查看堆内各个部分的使用量,以及加载类的数量.使用时,需加上查看进程的进程id,和所选参数. 执行:cd $JAVA_HOME/bin中执行jstat,注意jstat后一定要跟参数. 各个参数的意义. jstat -class pid:显示加载class的数量,及所占空间等信息. jstat -compiler pid:显示VM实时编译的数量等信息. jstat -gc pid:可以显示gc的信息,查看gc的次数,及时间.其中最后五项,分别是young…

背景 环境:openshift3.11 开发反映部署在容器中的java应用内存持续增长,只升不降,具体为: java应用部署在容器中,配置的jvm参数为-Xms1024m -Xmx1024m,容器memory request为1G, memory limit为4G,通过openshift的Pod metrics监控发现,应用消耗内存达到99%(只剩下3M),但是Pod处于Running状态,没有发生OOM,Pod容器java进程正常接收出了请求.增加容器memory limit至8G,内存依然消…

分析工具 1.jps 显示指定系统内的所有JVM进程 2.jstat 收集JVM各方面的运行数据 3.jinfo  显示JVM配置信息 4.jmap  堆快照 5.jhat  分析headdump文件 6.jstack  显示JVM的线程快照 jstat  -class pid -XX:+PrintGCDetails:输出GC的详细信息 -XX:+PrintGCTimeStamps:输出GC的时间信息 -XX:+PrintGCApplicatonStoppedTime:GC造成的应用暂停的时间…

故障场景 Java进程出现问题,通常表现出如下现象: Web应用响应时间长/超时,甚至不响应 CPU使用率极高/低,频繁出现Full GC,甚至OutOfMemoryError 响应时间长.超时,甚至不响应,这是最直观的表现:而CPU使用率极高或极低,频繁出现Full GC,这些需要借助系统日志或者监控辅助发现. 原因分析 针对响应时间长.超时,甚至不响应,这是一个综合性的问题导致的,可能并不单纯是应用程序本身的问题,如果后端还接了数据存储系统,除了排查应用程序本身的问题之外,还需要排查应用所依…

运行个JAVA 用sleep去hold住 package org.hjb.test; public class TestOnly { public static void main(String[] args) { System.out.println("sleep .."); try { Thread.sleep(10000000); } catch (InterruptedException e) { e.printStackTrace(); } } }   java -Xmx10…

自Java 6开始,Java程序启动时都会在JVM内部启动一个JMX agent,JMX agent会启动一个MBean server组件,把MBeans(Java平台标准的MBean + 你自己创建的MBean)注册到它里面,然后暴露给JMX client管理.简单来说就是每个Java程序都可以通过JMX来被JMX client管理,而且这一切都是自动发生的.而VisualVm就是一个JMX Client. VisualVm能够自动发现本机的Java进程,如果要监控远程主机上的Java进程则需…

内存注入ShellCode的优势就在于被发现的概率极低,甚至可以被忽略,这是因为ShellCode被注入到进程内存中时,其并没有与之对应的硬盘文件,从而难以在磁盘中取证,但也存在一个弊端由于内存是易失性存储器,所以系统必须一直开机,不能关闭,该攻击手法可以应用于服务器上面,安全风险最小,注入后将注入器删除即可. 1.生成64位ShellCode代码命令 [root@localhost ~]# msfvenom -a x64 --platform Windows \ -p windows/x64/…

背景起因: 记起以前的另一次也是关于内存的调优分享下   有个系统平时运行非常稳定运行(没经历过大并发考验),然而在一次活动后,人数并发一上来后,系统开始卡. 我按经验开始调优,在每个关键步骤的加入如下代码耗时统计进行压测:   long startTime = System.currentTimeMillis();  callRpc();   //这里比如调用RPC伪代码,当然还在插入数据库,中间件地方都加入统计  long costTime = (System.currentTimeMill…