Websphere内存溢出的日志

项目中碰到Websphere内存溢出的情况。原因可能：出现过多内存泄漏，或者分配过多大内存等。解决方法：
1、进入was管理控制台，选择 应用程序服务器 > server1 > 进程定义 > Java 虚拟机，将"最大堆大小"改为768或1024以上（跟机器内存相关，你的机器最好有较大内存）。保存。
2、优化你的程序，减少要求分配较大内存的设计，优化数据连接池。
3、给was打补丁。ibm网站上有相关补丁下载，不过最好升级到同系列的最新版本
4、修改启动文件，使之不产生这些文件，设置如下：
    export IBM_HEAP_DUMP=false
    export IBM_HEAPDUMP=false
    export IBM_HEAPDUMP_OUTOFMEMORY=false
    export IBM_JAVACORE_OUTOFMEMORY=false
分析以上4中方法，只有方法2才是根本解决之道。
针对4，IBM网站上有详细阐述，特附如下：
http://www-1.ibm.com/support/docview.wss?uid=swg21140641

用于故障诊断的工具：
http://www.ibm.com/developerworks/cn/websphere/techjournal/0702_supauth/0702_supauth.html

在您对 WebSphere Application Server 进行故障诊断时，日志记录工具很可能是您使用的第一项问题确定功能。这一工具集向用户和 IBM Support 提供深入了解运行时的能力，这种能力在确定基本问题时是必需的。

WebSphere Application Server 日志记录基础结构是基于标准 Java 的日志记录基础结构（即java.util.logging）建立的。在一个典型的 WebSphere Application Server 配置中，日志记录被设置为将普通和严重的日志消息分别写入两个文件，即SystemOut.log 和 SystemErr.log。
    
其他日志
WebSphere Application Server 中还有其他两个日志文件：JVM native_stdout 和 native_stderr 文件。与 SystemOut.log 和 SystemErr.log 不同，这两个文件实际上是由 JVM 本身处理的，只包含与该 JVM 的操作有关的消息，而不包含来自 WebSphere Application Server 运行时的消息。

假设在native_stderr.log里有这么一段日志：

<AF[3160]: Allocation Failure. need 2621456 bytes, 195 ms since last AF>
<AF[3160]: managing allocation failure, action=2 (5049520/1073740288)>
  <GC(3538): GC cycle started Wed Jul 30 17:41:02 2008
  <GC(3538): freed 4619080 bytes, 0% free (9668600/1073740288), in 6135 ms>
  <GC(3538): mark: 992 ms, sweep: 28 ms, compact: 5115 ms>
  <GC(3538): refs: soft 0 (age >= 32), weak 0, final 7, phantom 3>
  <GC(3538): moved 6184798 objects, 298397088 bytes, reason=1, used 101520 more bytes>
<AF[3160]: managing allocation failure, action=3 (9668600/1073740288)>
<AF[3160]: managing allocation failure, action=4 (9668600/1073740288)>
<AF[3160]: managing allocation failure, action=6 (9668600/1073740288)>
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to C:\Program Files\IBM\WebSphere\AppServer\profiles\default\heapdump.20080730.174102.3784.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to C:\Program Files\IBM\WebSphere\AppServer\profiles\default\javacore.20080730.174149.3784.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[3160]: Insufficient space in Javaheap to satisfy allocation request>
<AF[3160]: completed in 92673 ms>

第一行是说需要2621456 bytes内存，分配失败；
然后第二行告知可用内存只有5049520 bytes；
第三行GC开始回收内存；
第四行回收了4619080 bytes，总的可用内存变为9668600bytes。0% free是指当前可用/总内存大小，9668600/1073740288=0.0090，被约等于0了。
第五行开始不知道在干什么，猜测是移动数据以获取连续空间？
第十一行终于报内存不足了，然后会记录两个日志文件，heapdump、javacore.log。
根据这两个日志的时间，可以到sysetemOut.log中查看当时在做什么操作。

再看一段：

<AF[2]: Allocation Failure. need 524 bytes, 383 ms since last AF>
<AF[2]: managing allocation failure, action=0 (528723272/536869376)>
  <GC(2): GC cycle started Sat Apr 05 21:40:31 2008
  <GC(2): freed 3529224 bytes, 99% free (532252496/536869376), in 10 ms>
  <GC(2): mark: 7 ms, sweep: 3 ms, compact: 0 ms>
  <GC(2): refs: soft 0 (age >= 32), weak 0, final 7, phantom 0>
<AF[2]: completed in 11 ms>

这段应该说明，可用内存很大，但申请连续内存时可能还是不足。这段日志记录的是gc回收后就正好够了，所以没有了上一段日志中的move。

嗯，仅仅是猜测。