PostgreSQL分页查询引发的思考：OutOfMemoryError

前段时间遇到一个customer issue，问题现象是这样，每次客户通过tomcat查询DB，都会假死，页面一直打转，也无法重新登陆。

登陆后台发现生成了OutOfMemoryError dump文件.

问题1：怎么设置才能在server遇到OutOfMemoryError的时候，生成dump文件呢？

在JAVA_OPTS中增加参数XX:+HeapDumpOnOutOfMemoryError

参考：Java HotSpot VM Options

http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html

这里也顺便说一下JVM -X参数和-XX参数的区别：

Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations),and are subject to change without notice in subsequent releases of the JDK.

Options that are specified with -XX are not stable and are subject to change without notice.

我们知道tomcat是通过catalina.sh脚本启动的，我们就打开catalina.sh看看是否设置了这个参数，如下：

JAVA_OPTS="$JAVA_OPTS -Xmn$WEB_Xmn -Xms$WEB_Xms -Xmx$WEB_Xmx -Xss$WEB_Xss -XX:PermSize=$WEB_PermSize -XX:MaxPermSize=$WEB_MaxPermSize $Compress_Oops -XX:SurvivorRatio=3 -XX:+DisableExplicitGC -XX:CMSInitiatingOccupancyFraction=85 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:CMSMaxAbortablePrecleanTime=30000 -XX:+UseFastAccessorMethods -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError"

发现了吧，catalina.sh设置了这个参数，所以当发生OutOfMemoryError错误时，就会产生一个dump文件。

赶紧将dump文件取过来进行分析。

问题2：什么是dump文件，dump文件应该用什么工具分析呢？

不急，咱们来逐个回答。dump文件就是这样一个文件java_pid13793.hprof，当然名字会有不同，也就是一个*.hprof后缀名的文件。一般我们会使用MemoryAnalyzer这个工具来分析。

注意：dump文件一般比较大，如果发现用MemoryAnalyzer打不开，请调下MemoryAnalyzer.ini中的设置，将-Xmx1024m改成一个更大的值，比如改成-Xmx4096m。

问题3：怎么分析呢，分析步骤是什么？

1）第一步打开dump文件，选择Leak Suspects Report

2)选择比重最大的，查看其堆栈信息

如图，Problem Suspect1占1.3GB,基本上就是它了。

3）分析堆栈信息

通过分析堆栈，发现是查询出了问题，由于搜索的数据量大，将tomcat的内存撑爆了。然后就继续跟踪代码。

问题4：明明设置了分页查询，怎么还会把内存撑爆呢？

搜了PostgreSQL的官网才发现，PostgreSQL和MySQL、SQL Server不同，如果想要其分页生效，必须将Connect.SetAutoCommit(false)设置false.

// make sure autocommit is off
conn.setAutoCommit(false);

具体的可以参考PostgrsSQL的官网说明：

https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor

今天先到这儿吧，下次继续分享^_^