32
32
33
33
34
34
< meta property ="og:title " content ="生产环境内存泄露分析 " />
35
- < meta property ="og:description " content ="项目架构 java +grpc +rails 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。然后重启一次服务器并每天记录cpu、内存 " />
35
+ < meta property ="og:description " content ="项目架构 Java +gRPC +Rails 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。在开始分析问题之前,我们先重启一次服务器 " />
36
36
< meta property ="og:type " content ="article " />
37
37
< meta property ="og:url " content ="https://johnnyting.github.io/posts/%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E5%86%85%E5%AD%98%E6%B3%84%E9%9C%B2%E5%88%86%E6%9E%90/ " /> < meta property ="article:published_time " content ="2019-11-27T16:59:43+08:00 "/>
38
38
< meta property ="article:modified_time " content ="2019-11-27T16:59:43+08:00 "/>
39
39
40
40
< meta itemprop ="name " content ="生产环境内存泄露分析 ">
41
- < meta itemprop ="description " content ="项目架构 java +grpc +rails 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。然后重启一次服务器并每天记录cpu、内存 ">
41
+ < meta itemprop ="description " content ="项目架构 Java +gRPC +Rails 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。在开始分析问题之前,我们先重启一次服务器 ">
42
42
43
43
44
44
< meta itemprop ="datePublished " content ="2019-11-27T16:59:43+08:00 " />
45
45
< meta itemprop ="dateModified " content ="2019-11-27T16:59:43+08:00 " />
46
- < meta itemprop ="wordCount " content ="1906 ">
46
+ < meta itemprop ="wordCount " content ="1984 ">
47
47
48
48
49
49
50
50
< meta itemprop ="keywords " content ="ruby,java, " />
51
51
< meta name ="twitter:card " content ="summary "/>
52
52
< meta name ="twitter:title " content ="生产环境内存泄露分析 "/>
53
- < meta name ="twitter:description " content ="项目架构 java +grpc +rails 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。然后重启一次服务器并每天记录cpu、内存 "/>
53
+ < meta name ="twitter:description " content ="项目架构 Java +gRPC +Rails 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。在开始分析问题之前,我们先重启一次服务器 "/>
54
54
55
55
</ head >
56
56
@@ -171,9 +171,9 @@ <h1 class="f1 athelas mb1">生产环境内存泄露分析</h1>
171
171
172
172
</ header >
173
173
174
- < section class ="nested-copy-line-height lh-copy serif f4 nested-links nested-img mid-gray pr4-l w-two-thirds-l "> < p > 项目架构 java+grpc+rails </ p >
174
+ < section class ="nested-copy-line-height lh-copy serif f4 nested-links nested-img mid-gray pr4-l w-two-thirds-l "> < p > 项目架构 Java+gRPC+Rails </ p >
175
175
176
- < p > 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。然后重启一次服务器并每天记录cpu 、内存使用情况。内存记录如下:</ p >
176
+ < p > 因生产环境频繁出现宕机的情况,平均一周需要重启下服务器,这谁顶得住啊。。这个问题必须解决。在开始分析问题之前,我们先重启一次服务器,然后每天记录cpu 、内存使用情况。内存记录如下:</ p >
177
177
178
178
< pre > < code class ="language-textile "> 重启后第一次内存展示:
179
179
➜ ~ free -h
@@ -229,7 +229,7 @@ <h1 class="f1 athelas mb1">生产环境内存泄露分析</h1>
229
229
1771 uugm 20 0 4452920 255852 9180 S 0.0 3.1 3:48.27 java
230
230
</ code > </ pre >
231
231
232
- < p > 其实通过内存占用记录,可以判断有两个java进程(1492、2501)内存一直递增,一个ruby进程(28426)一直递增。经过查看这两个java进程都使用到了grpc,有可能是grpc的问题 ,当然现在只是我的猜测,我们需要进一步分析。</ p >
232
+ < p > 其实通过内存占用记录(这里top的数据记录就没有粘贴了) ,可以判断有两个java进程(1492、2501)内存一直递增,一个ruby进程(28426)一直递增。经过查看这两个java进程都使用到了grpc,其他没有使用grpc的java进程内存没有递增,很有可能是grpc的问题 ,当然现在只是我的猜测,我们需要进一步分析。</ p >
233
233
234
234
< p > 1.将pid为1492的java进程的整个heap堆数据dump出来,文件形式为二进制文件</ p >
235
235
@@ -286,21 +286,21 @@ <h1 class="f1 athelas mb1">生产环境内存泄露分析</h1>
286
286
* 避免n+1查询
287
287
</ code > </ pre >
288
288
289
- < p > 其实我们Rails项目中确实用到了一些全局的对象并且是大对象 ,会不会是这个问题?但这些都是必须的,很多接口都要用到这些大对象,如果不用全局变量,那么每次请求都要新创建一个对象内存占用一样的大,了解了ruby的gc机制 ,这些大对象用了之后可能还不会完全释放,内存占用也许会更大。</ p >
289
+ < p > 其实我们Rails项目中确实用到了一些全局对象并且是大对象 ,会不会是这个问题?但这些都是必须的,很多接口都要用到这些大对象,如果不用全局变量,那么每次请求都要新创建一个对象,内存占用一样的大,了解了下ruby的gc机制 ,这些大对象用了之后可能还不会完全释放,内存占用也许会更大。</ p >
290
290
291
- < p > 这就僵住了呀,那该怎么解决呢。 </ p >
291
+ < p > 这就僵住了呀,那该怎么解决呢? </ p >
292
292
293
293
< p > 我无奈之下重启了下puma,看看有什么不同。</ p >
294
294
295
295
< pre > < code class ="language-shell "> touch tmp/restart.txt
296
296
</ code > </ pre >
297
297
298
- < p > 我惊奇发现内存瞬间释放了2G </ p >
298
+ < p > 我惊奇的发现服务器内存瞬间释放了2G </ p >
299
299
300
300
< pre > < code class ="language-textile "> ➜ ~ free -h
301
- total used free shared buff/cache available
302
- Mem: 7.8G 4.8G 1.9G 14M 1.1G 2.6G
303
- Swap: 0B 0B 0B
301
+ total used free shared buff/cache available
302
+ Mem: 7.8G 4.8G 1.9G 14M 1.1G 2.6G
303
+ Swap: 0B 0B 0B
304
304
</ code > </ pre >
305
305
306
306
< p > 难道是puma的问题?</ p >
@@ -309,7 +309,9 @@ <h1 class="f1 athelas mb1">生产环境内存泄露分析</h1>
309
309
310
310
< p > 引用别人的结论:</ p >
311
311
312
- < pre > < code class ="language-textile "> puma 和 unicorn 都不会主动降低操作系统内存占用, 但会复用已经申请过的内存. 所以会随着每分钟请求量的增加导致内存不断上升. 如果超出某个极限, 则有可能导致内存爆掉. 可以考虑使用 puma_worker_killer 进行控制.
312
+ < pre > < code class ="language-textile "> puma 和 unicorn 都不会主动降低操作系统内存占用, 但会复用已经申请过的内存.
313
+ 所以会随着每分钟请求量的增加导致内存不断上升. 如果超出某个极限, 则有可能导致
314
+ 内存爆掉. 可以考虑使用puma_worker_killer进行控制.
313
315
</ code > </ pre >
314
316
315
317
< p > 似乎又有点思路了,就算没有真正解决内存泄露的问题,也可以用puma_worker_killer来控制内存占用来解决服务器宕机的问题。</ p >
@@ -341,8 +343,6 @@ <h1 class="f1 athelas mb1">生产环境内存泄露分析</h1>
341
343
< p > 8.经过上面步骤之后的内存记录</ p >
342
344
343
345
< pre > < code > 第一天:
344
-
345
-
346
346
</ code > </ pre >
347
347
< ul class ="pa0 ">
348
348
0 commit comments