高访问量jetty持续消耗内存问题-第一次发帖,求大牛解答

cjs_2017 发布于 2017/04/20 17:35
阅读 1K+
收藏 0

*环境:linux+ngixn+jetty
*问题描述:jetty启动后,经过一段时间(一般两个星期左右),内存消耗到没了,从内存消耗图看,是一个接近线性下降的趋势;*重启后jetty后,内存都可以释放完。(使用了ssl请求)
*数据提供:(总内存8G)
A、JVM启动参数:-Xmx5000m -Xms5000m -Xmn2000m -XX:PermSize=256m 

B、GC的情况:
2017-04-13T23:08:26.098+0800: 221108.011: [GC 221108.011: [ParNew
Desired survivor size 104857600 bytes, new threshold 6 (max 6)
- age   1:    5075328 bytes,    5075328 total
- age   2:     170664 bytes,    5245992 total
- age   3:     153136 bytes,    5399128 total
- age   4:     166792 bytes,    5565920 total
- age   5:     131288 bytes,    5697208 total
- age   6:     184864 bytes,    5882072 total
: 1645483K->6423K(1843200K), 0.0203310 secs] 3181438K->1542517K(4915200K), 0.0206690 secs] [Times: user=0.05 sys=0.00, real=0.02 secs] 
2017-04-13T23:08:26.127+0800: 221108.040: [GC [1 CMS-initial-mark: 1536094K(3072000K)] 1547277K(4915200K), 0.0367910 secs] [Times: user=0.01 sys=0.00, real=0.04 secs] 
2017-04-13T23:08:26.165+0800: 221108.078: [CMS-concurrent-mark-start]
2017-04-13T23:08:26.772+0800: 221108.685: [CMS-concurrent-mark: 0.607/0.607 secs] [Times: user=1.37 sys=0.21, real=0.61 secs] 
2017-04-13T23:08:26.772+0800: 221108.685: [CMS-concurrent-preclean-start]
2017-04-13T23:08:26.855+0800: 221108.769: [CMS-concurrent-preclean: 0.083/0.083 secs] [Times: user=0.12 sys=0.01, real=0.08 secs] 
2017-04-13T23:08:26.855+0800: 221108.769: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2017-04-13T23:08:31.866+0800: 221113.779: [CMS-concurrent-abortable-preclean: 4.873/5.010 secs] [Times: user=8.08 sys=0.65, real=5.01 secs] 
2017-04-13T23:08:31.869+0800: 221113.782: [GC[YG occupancy: 724914 K (1843200 K)]221113.951: [Rescan (parallel) , 0.2152830 secs]221114.167: [weak refs processing, 0.9604950 secs]221115.127: [class unloading, 0.0192670 secs]221115.147: [scrub symbol table, 0.0110620 secs]221115.158: [scrub string table, 0.0015560 secs] [1 CMS-remark: 1536094K(3072000K)] 2261008K(4915200K), 1.3161700 secs] [Times: user=1.92 sys=0.00, real=1.49 secs] 
2017-04-13T23:08:33.354+0800: 221115.268: [CMS-concurrent-sweep-start]
2017-04-13T23:08:34.581+0800: 221116.495: [CMS-concurrent-sweep: 1.176/1.227 secs] [Times: user=3.62 sys=0.16, real=1.22 secs] 
2017-04-13T23:08:34.581+0800: 221116.495: [CMS-concurrent-reset-start]
2017-04-13T23:08:34.603+0800: 221116.517: [CMS-concurrent-reset: 0.022/0.022 secs] [Times: user=0.04 sys=0.01, real=0.03 secs] 
2017-04-13T23:08:37.866+0800: 221119.780: [GC 221119.780: [ParNew
Desired survivor size 104857600 bytes, new threshold 6 (max 6)
- age   1:    8134688 bytes,    8134688 total
- age   2:     143856 bytes,    8278544 total
- age   3:     137752 bytes,    8416296 total
- age   4:     153072 bytes,    8569368 total
- age   5:     142208 bytes,    8711576 total
- age   6:     131224 bytes,    8842800 total
: 1644823K->9555K(1843200K), 0.0917760 secs] 2142002K->506915K(4915200K), 0.0922820 secs] [Times: user=0.29 sys=0.00, real=0.09 secs] 

C、运行free -m命令查看内存
                    total       used       free     shared    buffers     cached
Mem:          7870       7803         66          0         23       1013
-/+ buffers/cache:       6767       1103
Swap:         2047         71       1976

D、运行top命令查看
top - 09:48:13 up 180 days, 18:26,  1 user,  load average: 1.13, 1.37, 1.32
Tasks: 151 total,   3 running, 148 sleeping,   0 stopped,   0 zombie
Cpu(s): 23.7%us,  4.9%sy,  0.0%ni, 70.2%id,  0.1%wa,  0.0%hi,  0.7%si,  0.3%st
Mem:   8059448k total,  7925932k used,   133516k free,    21576k buffers
Swap:  2097144k total,    72880k used,  2024264k free,   981596k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                                 
10669 jetty     20   0 8589m 5.6g 5748 S 88.2 72.4  12059:18 java                                                                                                                                                                                     
 2186 nginx     20   0  143m  27m 1560 R  7.3  0.4   2093:23 nginx                                                       
。。。。

从上面的分析看,JVM的GC回收都没有问题,最后堆的占用不会很多,可是jetty的RES的占用达到了5.6G
有没有大神提供下思路,这到底是什么原因引起的?

以下是问题补充:

@cjs_2017:根据大神们的建议,查看了下代码?发现有段代码貌似会引起内存泄露,独立发了个贴,大神们帮忙分析下,不胜感激: https://www.oschina.net/question/3440308_2239445 (2017/04/24 11:22)
加载中
0
zigzagroad
zigzagroad
程序有问题:存在产生了但没有释放的资源。长时间运行以后就会产生内存不足的问题了。
zigzagroad
zigzagroad
内存呈线性增长的情况,基本上是可以确认为资源没有释放的;致使相应资源的引用计数始终大于0,gc也就不能将其回收掉了。
cjs_2017
cjs_2017
回复 @zigzagroad : 其实我有个疑惑,如果有对象没有释放,那么gc日志里面看到的经过CMS的堆内存应该也不会那么小呢?
zigzagroad
zigzagroad
看看代码中是否有向容器类的对象中放置资源,而该容器又是在一旦产生就不会释放的对象(比如singleton类的对象,或者Spring IoC中的单实例对象)中。
cjs_2017
cjs_2017
首先,非常感觉您的回答。 查看了代码,因为涉及的都是api接口,看本地jetty缓存代码逻辑也不会产生没有释放或无限增长的问题,然后也没有一些文件和io的类似操作。。。
0
xper
xper
内存泄露,优化代码,优化架构
cjs_2017
cjs_2017
首先,非常感觉您的回答。 能提供下查找思路吗?因为我看了dump的内存文件没找出什么问题
0
Adairs
Adairs
从内存消耗图看,是一个接近线性下降的趋势,应该是线性增长的趋势吧! 从你说的情况来看,像是部分代码存在内存泄露,你可以通过jmap和jstat查看一下详细信息
cjs_2017
cjs_2017
首先,非常感觉您的回答。 是的,我说错了,内存消耗是持续增长的状况;我dump了内存下来分析(用的是Eclipse memory Analyzer),发现Histogram只有400多m的shallow Heap,整个文件有1.7G,而unreachable objects都是要回收的。感觉没看出内存泄露的根据,软件判断sun.security.ssl.SSLContextImpl$引起,但不像呀
0
j
jake2

首先你这个gc日志太少了  看起来没有什么不正常的地方 所以最好能贴出jvm各区域内存的占用情况

所以只能猜测下

1.你这日志只是短时间的部分日志 可能 最后 堆内存确实占用了这么多

2 方法区你只设置了 最小内存  没设置最大内存肯能存在一直在自动扩充(不确定 没设置最大方法区 是否会一直自动扩充)

3 你看的时候 年轻代和老年代  都没gc呢  。。

感觉第二个靠谱些 但是 我一直没找到  方法区是否会一直扩充下去。。(如果是1.8  permsize参数无效的 确实会一直扩充)

综上所述  还是查看下 那个时候 内存占用情况 最靠谱233333

j
jake2
回复 @cjs_2017 : 嘞就不几道了
cjs_2017
cjs_2017
回复 @jake2 : 我一开始也这样认为,但是对比了另外一台服务器,同样的启动参数,top命令下的只有3.5G,没有达到5.6G。。。
j
jake2
回复 @cjs_2017 : 我最上面的回答有些错误 没注意到你的xms参数和你的 xmx参数一致的 其实你好像有些弄混了 jvm内存和top命令查看系统中程序的内存 你讲jvm的堆内存 初始固定为了5000m 就是说jvm进程一启动就会占用5000m内存 然后在加上 方法区的和 一些线程的私有空间 占个5.6g很正常的 你可以根据你项目需要内存的大小 将xms设小点
cjs_2017
cjs_2017
回复 @jake2 : 正常的依据是什么呢?因为内存在不断消耗,可是看了下堆内存和非堆内存都没有问题,所以就不知道内存在什么地方被消耗了,每次要重启jetty服务才能释放内存
cjs_2017
cjs_2017
非常感谢您的回答,这里对应你的说法来讨论下: 1、贴出来的是抽取的一部分日志,ParNew就是年轻代的回收,日志都是年轻代回收,记录跟贴出来的基本一致。CMS的全局回收只是偶尔。 2、方法区最大值jvm默认是四分之一的内存,所以不是无限的。
下一页
0
咖啡男孩

最简单的解决办法,每天凌晨自动重启一下项目。

返回顶部
顶部