JVM崩溃Log日志分析和jvm参数在哪里设置和tomcat优化(全)

一:JVM崩溃Log日志分析

Java的应用有时候会因为各种原因Crash，这时候会产生一个类似java_errorpid.log的错误日志。可以拿到了

这个日志，怎样分析Crash的原因呢？下面我们来详细讨论如何分析java_errorpid.log的错误日志。

一. 如何得到这个日志文件

如果有一个严重的错误引起Java进程非正常退出，我们叫Crash，这时候会产生一个日志文件。缺省情况下，这个
文件会产生在工作目录下。但是，可以在Java启动参数通过下面的设置，来改变这个文件的位置和命名规则。例如：

java -XX:ErrorFile=/var/log/java/java_error_%p.log

就将这个错误文件放在/var/log/java下，并且以java_error_pid.log的形式出现。

 

二.产生错误的原因
造成严重错误的原因有多种可能性。Java虚拟机自身的Bug是原因之一，但是这种可能不是很大。在绝大多数情况下，

是由于系统的库文件、API或第三方的库文件造成的；系统资源的短缺也有可能造成这种严重的错误。在发生了Crash

之后，如果无法定位根本原因，也应该迅速找到Work Around的方法。

三.对日志文件的分析
首先要检查日志的文件头：例如，下面是从一个客户发过来的错误日志的文件头

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0815e87e, pid=7268, tid=4360
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_13-b06 mixed mode)
# Problematic frame:
# V [jvm.dll+0x15e87e]
#
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

 

文件头中有很多有用的信息，“EXCEPTION_ACCESS_VIOLATION ”意味着Java应用Crash的时候，

正在运行JVM自己的代码，而不是外部的Java代码或其他类库代码。这种情况很可能是JVM的Bug，但是

也不一定。除了“EXCEPTION_ACCESS_VIOLATION ”，还有可能是别的信息，例如“SIGSEGV(0xb)”，

意味着JVM正在执行本地或JNI的代码;“EXCEPTION_STACK_OVERFLOW”意味着这是个栈溢出的错误。

 （**********看到这里我们知道我报错时正在运行JVM自己的代码，而不是外部的Java代码或其他类库代码*********）

另外一个有用的信息就是：

# Problematic frame:
# V [jvm.dll+0x15e87e]

它说明Crash的时候，JVM正在从哪个库文件执行代码。除了“V”以外，还有可能是“C”、“j”、“v”、“J”。具体的表示意思如下：

FrameType Description：
C: Native C frame
j: Interpreted Java frame
V: VMframe
v: VMgenerated stub frame
J: Other frame types, including compiled Java frames

（**********看到这里我们知道我报错时是V: VMframe这种情况*********）

文件头之后，是当前线程的DUMP信息，线程之后是JVM进程的DUMP信息，包括所有线程的状态、地址和ID。最后还有JVM状态，

Heap状态，动态连接库等等的信息。这些烦乱的信息中，包含有非常有用的信息。下面我们根据几个具体的实例来分析Java虚拟

机Crash的典型例子。

四.内存回收引起的Crash
内存回收引起的Crash有以下的特点：在日志文件头一般有“ EXCEPTION_ACCESS _VIOLATION”和

“# Problematic frame: # V [jvm.dll+....”的信息，意味着这是在JVM内部处理，而且多半是JVM的Bug。

（**********看到这里我们知道我报错时意味着这是在JVM内部处理，而且多半是JVM的Bug*********）

对于这类问题，最快的方法就是绕过它。

另外，在Thread的DUMP信息最后，还能看到有关内存回收的行为例如：

--------------- T H R E A D ---------------
Current thread (0x00a56668): VMThread [id=4360]
siginfo: ExceptionCode=0xc0000005, reading address 0x00000057
Registers:
........

Stack: [0x03cf0000,0x03d30000), sp=0x03d2fc18, free space=255k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x15e87e]

VM_Operation (0x063efbac): full generation collection, mode: safepoint, requested by thread 0x040f83f8
------------------------------------------------------------

可以清楚的看到JVM正在做 “full generation collection”。另外还有可能看到，其他的回收行为：

generation collection for allocation

full generation collection

parallel gc failed allocation

parallel gc failed permanent allocation

parallel gc system gc

（***********这些错，俺都没碰到***********）

对于内存回收的错误，一般采取改变回收的算法和参数的方法来绕过去。例如，来自客户的日志除了上面的

日志信息，在日志中Heap信息中还能发现一些其他信息：

--------------------------------------------------------------
Heap
def new generation total 22592K, used 19530K [0x10010000, 0x11890000, 0x138f0000)
eden space 20096K, 97% used [0x10010000, 0x11322bd8, 0x113b0000)
from space 2496K, 0% used [0x113b0000, 0x113b0000, 0x11620000)
to space 2496K, 0% used [0x11620000, 0x11620000, 0x11890000)
tenured generation total 190696K, used 100019K [0x138f0000, 0x1f32a000, 0x30010000)
the space 190696K, 52% used [0x138f0000, 0x19a9cf38, 0x19a9d000, 0x1f32a000)
compacting perm gen total 38656K, used 38588K [0x30010000, 0x325d0000, 0x34010000)
the space 38656K, 99% used [0x30010000, 0x325bf038, 0x325bf200, 0x325d0000)
----------------------------------------------------------------

上面的信息能看出在Crash的时候，JVM的PermSize空间几乎已经消耗完了，并且回收算法在压缩Perm空间的时候出了错。

因此，建议改变内存回收的算法，或扩大PermSize和MaxPermSize的数值。

（*******这个倒是可以尝试*******）

五.栈溢出引起的Crash

Java代码引起的栈溢出，通常不会引起JVM的Crash，而是抛出一个Java异常：java.lang.StackOverflowError。

但是在Java虚拟机中，Java的代码和本地C或C++代码公用相同的Stack。这样，在执行本地代码所造成的栈溢出，

就有可能引起JVM的Crash了。

栈溢出引起的Crash会在日志的文件头中看到“EXCEPTION_STACK_OVERFLOW”字样。另外，在当前线程的Stack

信息中也能发现一些信息。例如下面的例子：

-----------------------------------------------------------------------------------
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x10001011, pid=296, tid=2940
#
# Java VM: Java HotSpot(TM) Client VM (1.6-internal mixed mode, sharing)
# Problematic frame:
# C [App.dll+0x1011]
#
--------------- T H R E A D ---------------
Current thread (0x000367c0): JavaThread "main" [_thread_in_native, id=2940]
:
Stack: [0x00040000,0x00080000), sp=0x00041000, free space=4k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [App.dll+0x1011]
C [App.dll+0x1020]
C [App.dll+0x1020]
:
C [App.dll+0x1020]
C [App.dll+0x1020]
...<more frames>...
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j Test.foo()V+0
j Test.main([Ljava/lang/String;)V+0
v ~StubRoutines::call_stub

--------------------------------------------------------------------------------

在上面的信息中，可以发现这是个栈溢出的错误。并且当前栈剩余的空间已经很小了(free space =4k)。

因此建议将JVM的Stack的尺寸调大，主要设计两个参数：“-Xss” 和“-XX:StackShadowPages=n”。

 

转自:http://blog.sina.com.cn/s/blog_4c98b9600100jq38.html

 

二:JVM参数在哪里设置

 

在哪里设置,分好几种情况： 
1、集成开发环境下启动并使用JVM，如eclipse需要修改根目录文件eclipse.ini； 
2、Windows服务器下安装版Tomcat，可使用Tomcat7w.exe工具（tomcat目录下）和直接修改注册表两种方式修改Jvm参数； 
3、Windows服务器解压版Tomcat注册Windows服务，方法同上； 
4、解压版本的Tomcat, 通过startup.bat启动tomcat加载配置的，在tomcat 的bin 下catalina.bat 文件内添加； 
5、Linux服务器Tomcat设置JVM，修改TOMCAT_HOME/bin/catalina.sh；

参考帖子：http://bbs.51testing.com/thread-1050687-1-1.html

 

三:tomcat优化(全)

1.内存设置(VM参数调优)
(1). Windows环境下，是tomcat解压版(执行startup.bat启动tomcat) ,解决办法:
修改“%TOMCAT_HOME%\bin\catalina.bat”文件，在文件开头增加如下设置：
set JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=512m
备注：一定加在catalina.bat最前面。
(2). Windows环境下，是tomcat安装版(利用windows的系统服务启动tomcat),解决办法:
修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6\Parameters\JavaOptions
原值为:

-Dcatalina.home=E:\Tomcat 6.0
-Dcatalina.base=E:\Tomcat 6.0
-Djava.endorsed.dirs=E:\Tomcat 6.0\common\endorsed
-Djava.io.tmpdir=E:\Tomcat 6.0\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=E:\Tomcat 6.0\conf\logging.properties
加入：
Xms512m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=512m

重起tomcat服务,设置生效。
(3). Linux环境下, ,解决办法:
修改“%TOMCAT_HOME%\bin\catalina.sh”文件，在文件开头增加如下设置：JAVA_OPTS=’-Xms256m -Xmx512m’

各参数详解：
-Xms：设置JVM初始内存大小(默认是物理内存的1/64)
-Xmx：设置JVM可以使用的最大内存(默认是物理内存的1/4，建议：物理内存80%)
-Xmn：设置JVM最小内存(128-256m就够了,一般不设置)
默认空余堆内存小于 40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、 -Xmx相等以避免在每次GC 后调整堆的大小。
在较大型的应用项目中，默认的内存是不够的，有可能导致系统无法运行。常见的问题是报Tomcat内存溢出错误“java.lang.OutOfMemoryError: Java heap space”，从而导致客户端显示500错误。

-XX:PermSize ：为JVM启动时Perm的内存大小
-XX:MaxPermSize ：为最大可占用的Perm内存大小(默认为32M)
-XX:MaxNewSize，默认为16M
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现“java.lang.OutOfMemoryError: PermGen space”错误。
对于WEB项目，jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小，为了避免调整)，你可以使用更多的参数配置。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小,那么就会产生此错误信息了。
其它参数：
-XX:NewSize ：默认为2M，此值设大可调大新对象区，减少Full GC次数
-XX:NewRatio ：改变新旧空间的比例，意思是新空间的尺寸是旧空间的1/8（默认为8）
-XX:SurvivorRatio ：改变Eden对象空间和残存空间的尺寸比例，意思是Eden对象空
间的尺寸比残存空间大survivorRatio+2倍（缺省值是10）
-XX:userParNewGC 可用来设置并行收集【多CPU】
-XX:ParallelGCThreads 可用来增加并行度【多CPU】
-XXUseParallelGC 设置后可以使用并行清除收集器【多CPU】
2.修改tomcat让其支持NIO
修改前：
protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>
修改成支持NIO的类型，配置如下 ：
protocol="org.apache.coyote.http11.Http11NioProtocol " connectionTimeout="20000" redirectPort="8443" />
3.并发数设置
默认的tomcat配置，并发测试时，可能30个USER上去就当机了。
添加
 

maxThreads="600" //最大线程数
minSpareThreads="100" //初始化时创建的线程数
maxSpareThreads="500" //一旦线程超过这个值，Tomcat会关闭不需要的socket线程
acceptCount="700"//指定当所有可以使用的处理请求的线程数都被使用时，可以放到
处理队列中的请求数，超过这个数的请求将不予处理
connectionTimeout="20000"
redirectPort="8443" />

或者
name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="400" />

executor="tomcatThreadPool" port="80" protocol="HTTP/1.1" connectionTimeout="20000" enableLookups="false"
redirectPort="8443" URIEncoding="UTF-8" acceptCount="1000" />

4.Java虚拟机调优
应该选择SUN的JVM，在满足项目需要的前提下，尽量选用版本较高的JVM，一般来说高版本产品在速度和效率上比低版本会有改进。 JDK1.4比JDK1.3性能提高了近10%-20%，JDK1.5比JDK1.4性能提高25%-75%。
5.禁用DNS查询

enableLookups="false"：
enableLookups="false" redirectPort="8443" URIEncoding="UTF-8" acceptCount="1000" />

　当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络， 并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭 DNS查询，方式是修改server.xml文件中的enableLookups参数值为false。
6.设置解决乱码问题

URIEncoding="UTF-8" acceptCount="1000" />

转自:http://blog.sina.com.cn/s/blog_790229d301017ow2.html