JVM卡死，Eden Space为100%，求解决方案

在LInux服务器上，内存为125G，
刚开始，设置的JVM参数为-Xmx5120M，发现程序重启（看门狗ftp连接不上进程，就会将进程重启）
后来设置了-Xmx5120M -Xmn1920m，发现程序还是重启，
重启的有时候会产生hs_error文件，有时候没有产生，但共同的特点是eden space为100%
目前不知道该如何定位原因，是JVM参数没有设置正确？还是代码有问题？还是进程只是卡死后续还会恢复？
求大神给点思路

解决方案 »

  1.   

    使用jvm 相关的命令 抓取一下内存 dump
    分析一下dump 看那个对象占用最多  
    再结合程序分析一下,可以找出问题 
      

  2.   

    占用内存最多的对象是byte[] 跟 String，程序本来是接收数据并保存数据的，byte[]跟String占用空间大，也是合情合理的，分析很多次也没有看出来啥 -_-
      

  3.   

    导致JVM  Eden Space为100%，说明堆内存对象操作很多很快。
    只要不出现tomcat:java.lang.OutOfMemoryError: PermGen space的异常，说明堆内存还是够用的。
    主要看看Perm（永久代）的利用率，如果把你5G都用完了，我只能说很有可能程序有问题。产生hs_error文件，可以根据日志内容来分析。不过这些hs_error文件很有可能是看门狗杀死java进程后留下的。
      

  4.   

    虽然设置-Xmn为5G,但程序卡死的是我用jmap和jstat都查看了内存
    Jmap：显示年轻为160M，而且为100%Jstat：每秒查看GCUtil
    可以看到Eden一下子从11% 升到100%,此后就卡死了，S0 S1 E O YGC FGC都不再变化很奇怪为什么Eden为什么一秒就升到了100%，不知道是因为那会数据量太大还是程序有问题如果是数据量太大，有没有什么方法可以从代码层面去避免，大家有什么想法
      

  5.   


    hs_error文件里面看到：出现异常的时候正在与运行的线程是VM Thread，推测是JVM在GC的时候崩溃的
      

  6.   


    hs_error文件里面看到：出现异常的时候正在与运行的线程是VM Thread，推测是JVM在GC的时候崩溃的hs_error贴出来看看
    把你的配置文件贴出来看看（最好时用jvisualvm 查看实际的运行参数配置）
      

  7.   

    jmap -dump:format=b,file=heap.bin <pid>
    dump一下 然后用MemoryAnalyzer.exe分析一下 看看内存增长在哪里了，一定要在重启之前
      

  8.   


    内存上去之后  手动GC 有效果吗?  jmap好像是先会调GC再查对象的.. 
     -Xmn1920m 感觉小了点..  来看看这个..虽然老了点  但是我看新的文章也都是在转他的..  http://unixboy.iteye.com/blog/174173/再就是给一下更完整的参数吧... 还有注意一下硬盘空间是怎样的 
      

  9.   

    err日志里面有没有OOM错误, 硬盘空间是不是满了.(当前目录的空间)
      

  10.   


    内存上去之后  手动GC 有效果吗?  jmap好像是先会调GC再查对象的.. 
     -Xmn1920m 感觉小了点..  来看看这个..虽然老了点  但是我看新的文章也都是在转他的..  http://unixboy.iteye.com/blog/174173/再就是给一下更完整的参数吧... 还有注意一下硬盘空间是怎样的 有一太机器 现在设置了三个参数 -Xms5120m -Xmx5120m -Xmn1920m，目前已经有两天没有重启了，不知道后面会不会重启
    -Xss没有设置，目前没有计算应该多少，所以没有设置，不知道设置之后会不会有什么影响
      

  11.   


    hs_error文件里面看到：出现异常的时候正在与运行的线程是VM Thread，推测是JVM在GC的时候崩溃的hs_error贴出来看看
    把你的配置文件贴出来看看（最好时用jvisualvm 查看实际的运行参数配置）哎，数据不在本机，拿不出来，只能远程看看
    现在想解决的是如果是FTP接收数据量太大，怎么能让Eden不要激增到100%
      

  12.   

    FTP接收数据应该是边收边写入文件，全部存在内存的话，很容易秒爆
      

  13.   


    现在怀疑是FTP接收数据量太大，待会会记录一下，看看重启之前的FTP数据量是不是也在激增话说用的Apache 提供的FTP Server API，设置了setMaxLogins最大登陆数，好像也没有任何作用
      

  14.   


    这是假设呀.. 你有了假设可以去试验一下呀,如果不是这样的原因就可以排除掉了 搞一个本地的环境试试 ? 
    要不然你想了半天解决方法,然后发现不是这个原因就尴尬了..不过FTP 我也不懂..胡说两句
    接收文件一般是有个cache吧,然后读一块写一块.. 难道是无限大的..  有点像持久化的感觉.
    再就是应该也有用堆外内存的实现吧..不过我也只是听说过还有就是再提一下硬盘问题.. 硬盘满了会有奇怪的现象..
      

  15.   


    现在怀疑是FTP接收数据量太大，待会会记录一下，看看重启之前的FTP数据量是不是也在激增话说用的Apache 提供的FTP Server API，设置了setMaxLogins最大登陆数，好像也没有任何作用等一下..   我好像被你绕进去了  ...    FTP 为什么会用堆内存..  FTP 是文件传输协议呀...  不是这一层的吧 
      

  16.   


    现在怀疑是FTP接收数据量太大，待会会记录一下，看看重启之前的FTP数据量是不是也在激增话说用的Apache 提供的FTP Server API，设置了setMaxLogins最大登陆数，好像也没有任何作用等一下..   我好像被你绕进去了  ...    FTP 为什么会用堆内存..  FTP 是文件传输协议呀...  不是这一层的吧 用的Apache FTP  API，使用代码实现的，改了一些api的接收函数，在接收到数据就会存到队列中，但队列也是有长度的，我也只是猜测是这一块，但也不确定，好崩溃，目前能确定的就是Eden激增到100%，十几秒没有反应就会被看门狗重启，但Eden为什么为激增，找不到原因，同样的程序在其他机器上运行也好几个月了，就只有几台不好使
      

  17.   

     -Xms5120m -Xmx5120m -Xmn1920m   只有-Xms和-Xmx设为一致时-Xmn参数才有效果，edenspace里存储的大部分都是新创建的对象，看看是不是对象都是启动时生成的，可以考虑下懒加载。
      

  18.   

    这个是截取的挂掉之后的Jstat -gccuase 的输出
      

  19.   

    这玩意看不懂啊..  每一列是啥意思..  最后到100的是Eden吗. 
    有没有查看过GC次数  在内存被占满之前是不是有特别多次的GC