nginx内存持续增长

mjay0929 · 2016-06-14T20:12:14+00:00

Hello如果 get 和 set 之间逻辑较为复杂，或者 get set 之间&#x67...

nginx内存持续增长

mjay0929

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。

但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

doujiang24

Hello

你的最终 timer 是一直存在，不断发起新的 http 请求么

还是 timer 是处理一定的 http 请求，就退出？

前者可能会有一定的内存泄露风险，最后采用后者

最好的定位办法是用内存泄露火焰图，此乃神器，你值得拥有

具体的时候方法，请多搜索本站以往的帖子

https://github.com/openresty/stapxx#sample-bt-leaks

在 2016年6月14日下午8:12， <mja...@gmail.com>写道：

hi

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。
但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

--

mjay0929

hi doujiang

这个timer.at不会一直存在。

尝试了doujiang说的方法，得到了火焰图，但是看不太明白，请教下，这个图能说明什么问题呢，有没有什么资料可以对火焰图的分析说明下，感谢哈:)

附：1.生成火焰图的命令：

./samples/sample-bt-leaks.sxx -x 55530 --arg time=60 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=10000 > a.bt

2.当时使用nginx-gdb-utils得到的lgcstat，看样子不太像泄漏在lua层面
(gdb) lgcstat
3250 str      objects: max=7262, avg = 51, min=18, sum=166035
624 upval    objects: max=24, avg = 24, min=24, sum=14976
   2 thread   objects: max=608, avg = 604, min=600, sum=1208
578 proto    objects: max=10495, avg = 642, min=80, sum=371260
1053 func     objects: max=144, avg = 29, min=20, sum=30648
16 trace    objects: max=5716, avg = 832, min=160, sum=13320
694 cdata    objects: max=16, avg = 15, min=12, sum=11100
1468 tab      objects: max=24608, avg = 218, min=32, sum=320328
210 udata    objects: max=1441886, avg = 7274, min=32, sum=1527590

sizeof strhash 32768
sizeof g->tmpbuf 512
sizeof ctype_state 4568
sizeof jit_state 24880

total sz 2524417
g->strnum 3250, g->gc.total 2524417可能是电话号码，是否拨号?
elapsed: 0.578708 sec

3. 火焰图（不知道如何上传svg图片，见谅:) ）

在 2016年6月14日星期二 UTC+8下午9:44:06，doujiang写道：

Hello

你的最终 timer 是一直存在，不断发起新的 http 请求么
还是 timer 是处理一定的 http 请求，就退出？

前者可能会有一定的内存泄露风险，最后采用后者

最好的定位办法是用内存泄露火焰图，此乃神器，你值得拥有
具体的时候方法，请多搜索本站以往的帖子
https://github.com/openresty/stapxx#sample-bt-leaks

在 2016年6月14日下午8:12， <mjay...@gmail.com>写道：
hi

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。
但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

--

doujiang24

Hello

在 2016年6月20日下午8:21， <mja...@gmail.com>写道：

hi doujiang
这个timer.at不会一直存在。
尝试了doujiang说的方法，得到了火焰图，但是看不太明白，请教下，这个图能说明什么问题呢，

图中显示的宽度，就是在 60s 内申请了还没有释放的内存

有没有什么资料可以对火焰图的分析说明下，感谢哈:)

想深入了解的话，你可以多了解下 systemtap，然后看看 sample-bt-leaks.sxx 源码，并不难理解

附：1.生成火焰图的命令：
./samples/sample-bt-leaks.sxx -x 55530 --arg time=60 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=10000 > a.bt

2.当时使用nginx-gdb-utils得到的lgcstat，看样子不太像泄漏在lua层面

确实，从火焰图里看，你的泄露点很明显在 nginx 的内存分配上

因为 nginx 是每请求有独立内存池，请求内的内存申请都从池中分配，在请求结束之前并不存在释放（只释放大内存段）

而，timer 本身也是一个请求（fake request），所以我们不应该让一个 timer 一直执行

你可以改下你的逻辑，每个 timer 跑一段时间就创建另一个 timer，又它来继续执行

(gdb) lgcstat
3250 str      objects: max=7262, avg = 51, min=18, sum=166035
624 upval    objects: max=24, avg = 24, min=24, sum=14976
   2 thread   objects: max=608, avg = 604, min=600, sum=1208
578 proto    objects: max=10495, avg = 642, min=80, sum=371260
1053 func     objects: max=144, avg = 29, min=20, sum=30648
16 trace    objects: max=5716, avg = 832, min=160, sum=13320
694 cdata    objects: max=16, avg = 15, min=12, sum=11100
1468 tab      objects: max=24608, avg = 218, min=32, sum=320328
210 udata    objects: max=1441886, avg = 7274, min=32, sum=1527590

sizeof strhash 32768
sizeof g->tmpbuf 512
sizeof ctype_state 4568
sizeof jit_state 24880

total sz 2524417
g->strnum 3250, g->gc.total 2524417可能是电话号码，是否拨号?
elapsed: 0.578708 sec

3. 火焰图（不知道如何上传svg图片，见谅:) ）

在 2016年6月14日星期二 UTC+8下午9:44:06，doujiang写道：
Hello

你的最终 timer 是一直存在，不断发起新的 http 请求么
还是 timer 是处理一定的 http 请求，就退出？

前者可能会有一定的内存泄露风险，最后采用后者

最好的定位办法是用内存泄露火焰图，此乃神器，你值得拥有
具体的时候方法，请多搜索本站以往的帖子
https://github.com/openresty/stapxx#sample-bt-leaks

在 2016年6月14日下午8:12， <mjay...@gmail.com>写道：
hi

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。
但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

--

--

mjay0929

hi doujiang

非常感谢及时回答，有个疑问哈：

每个 timer 跑一段时间就创建另一个 timer，又它来继续执行

这里如果这样的话，这个内存还是没有释放吧（释放了又申请了新的）？

另外，请教下，我们这种场景用timer并发是不是最合适呢，有没有其他优化的方法，感谢:)

在 2016年6月20日星期一 UTC+8下午9:26:12，doujiang写道：

Hello

在 2016年6月20日下午8:21， <mjay...@gmail.com>写道：
hi doujiang
这个timer.at不会一直存在。
尝试了doujiang说的方法，得到了火焰图，但是看不太明白，请教下，这个图能说明什么问题呢，

图中显示的宽度，就是在 60s 内申请了还没有释放的内存

有没有什么资料可以对火焰图的分析说明下，感谢哈:)

想深入了解的话，你可以多了解下 systemtap，然后看看 sample-bt-leaks.sxx 源码，并不难理解

附：1.生成火焰图的命令：
./samples/sample-bt-leaks.sxx -x 55530 --arg time=60 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=10000 > a.bt

2.当时使用nginx-gdb-utils得到的lgcstat，看样子不太像泄漏在lua层面

确实，从火焰图里看，你的泄露点很明显在 nginx 的内存分配上

因为 nginx 是每请求有独立内存池，请求内的内存申请都从池中分配，在请求结束之前并不存在释放（只释放大内存段）

而，timer 本身也是一个请求（fake request），所以我们不应该让一个 timer 一直执行
你可以改下你的逻辑，每个 timer 跑一段时间就创建另一个 timer，又它来继续执行

(gdb) lgcstat
3250 str      objects: max=7262, avg = 51, min=18, sum=166035
624 upval    objects: max=24, avg = 24, min=24, sum=14976
   2 thread   objects: max=608, avg = 604, min=600, sum=1208
578 proto    objects: max=10495, avg = 642, min=80, sum=371260
1053 func     objects: max=144, avg = 29, min=20, sum=30648
16 trace    objects: max=5716, avg = 832, min=160, sum=13320
694 cdata    objects: max=16, avg = 15, min=12, sum=11100
1468 tab      objects: max=24608, avg = 218, min=32, sum=320328
210 udata    objects: max=1441886, avg = 7274, min=32, sum=1527590

sizeof strhash 32768
sizeof g->tmpbuf 512
sizeof ctype_state 4568
sizeof jit_state 24880

total sz 2524417
g->strnum 3250, g->gc.total 2524417可能是电话号码，是否拨号?
elapsed: 0.578708 sec

3. 火焰图（不知道如何上传svg图片，见谅:) ）

在 2016年6月14日星期二 UTC+8下午9:44:06，doujiang写道：
Hello

你的最终 timer 是一直存在，不断发起新的 http 请求么
还是 timer 是处理一定的 http 请求，就退出？

前者可能会有一定的内存泄露风险，最后采用后者

最好的定位办法是用内存泄露火焰图，此乃神器，你值得拥有
具体的时候方法，请多搜索本站以往的帖子
https://github.com/openresty/stapxx#sample-bt-leaks

在 2016年6月14日下午8:12， <mjay...@gmail.com>写道：
hi

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。
但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

--

--

doujiang24

Hello

在 2016年6月20日下午10:56， <mja...@gmail.com>写道：

hi doujiang

非常感谢及时回答，有个疑问哈：
每个 timer 跑一段时间就创建另一个 timer，又它来继续执行
这里如果这样的话，这个内存还是没有释放吧（释放了又申请了新的）？

老的释放了，又申请了新的

只要不是一直不释放，就不会持续增长

另外，请教下，我们这种场景用timer并发是不是最合适呢，有没有其他优化的方法，感谢:)

你可以用 ngx.thread 来并发

在 2016年6月20日星期一 UTC+8下午9:26:12，doujiang写道：
Hello

在 2016年6月20日下午8:21， <mjay...@gmail.com>写道：
hi doujiang
这个timer.at不会一直存在。
尝试了doujiang说的方法，得到了火焰图，但是看不太明白，请教下，这个图能说明什么问题呢，

图中显示的宽度，就是在 60s 内申请了还没有释放的内存

有没有什么资料可以对火焰图的分析说明下，感谢哈:)

想深入了解的话，你可以多了解下 systemtap，然后看看 sample-bt-leaks.sxx 源码，并不难理解

附：1.生成火焰图的命令：
./samples/sample-bt-leaks.sxx -x 55530 --arg time=60 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=10000 > a.bt

2.当时使用nginx-gdb-utils得到的lgcstat，看样子不太像泄漏在lua层面

确实，从火焰图里看，你的泄露点很明显在 nginx 的内存分配上

因为 nginx 是每请求有独立内存池，请求内的内存申请都从池中分配，在请求结束之前并不存在释放（只释放大内存段）

而，timer 本身也是一个请求（fake request），所以我们不应该让一个 timer 一直执行
你可以改下你的逻辑，每个 timer 跑一段时间就创建另一个 timer，又它来继续执行

(gdb) lgcstat
3250 str      objects: max=7262, avg = 51, min=18, sum=166035
624 upval    objects: max=24, avg = 24, min=24, sum=14976
   2 thread   objects: max=608, avg = 604, min=600, sum=1208
578 proto    objects: max=10495, avg = 642, min=80, sum=371260
1053 func     objects: max=144, avg = 29, min=20, sum=30648
16 trace    objects: max=5716, avg = 832, min=160, sum=13320
694 cdata    objects: max=16, avg = 15, min=12, sum=11100
1468 tab      objects: max=24608, avg = 218, min=32, sum=320328
210 udata    objects: max=1441886, avg = 7274, min=32, sum=1527590

sizeof strhash 32768
sizeof g->tmpbuf 512
sizeof ctype_state 4568
sizeof jit_state 24880

total sz 2524417
g->strnum 3250, g->gc.total 2524417可能是电话号码，是否拨号?
elapsed: 0.578708 sec

3. 火焰图（不知道如何上传svg图片，见谅:) ）

在 2016年6月14日星期二 UTC+8下午9:44:06，doujiang写道：
Hello

你的最终 timer 是一直存在，不断发起新的 http 请求么
还是 timer 是处理一定的 http 请求，就退出？

前者可能会有一定的内存泄露风险，最后采用后者

最好的定位办法是用内存泄露火焰图，此乃神器，你值得拥有
具体的时候方法，请多搜索本站以往的帖子
https://github.com/openresty/stapxx#sample-bt-leaks

在 2016年6月14日下午8:12， <mjay...@gmail.com>写道：
hi

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。
但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

--

--

--

mjay0929

hi doujiang

还有个奇怪的问题，我们的程序运行一段时间之后，等所有timer跑完，虚拟内存上升了一直没下来，请问有什么方法查看这些内存是由哪些模块分布的吗？

sample-bt-leaks.sxx这个好像是查看运行中的状态的，感谢哈:)

在 2016年6月20日星期一 UTC+8下午11:06:54，doujiang写道：

Hello

在 2016年6月20日下午10:56， <mjay...@gmail.com>写道：
hi doujiang

非常感谢及时回答，有个疑问哈：
每个 timer 跑一段时间就创建另一个 timer，又它来继续执行
这里如果这样的话，这个内存还是没有释放吧（释放了又申请了新的）？

老的释放了，又申请了新的
只要不是一直不释放，就不会持续增长

另外，请教下，我们这种场景用timer并发是不是最合适呢，有没有其他优化的方法，感谢:)

你可以用 ngx.thread 来并发

在 2016年6月20日星期一 UTC+8下午9:26:12，doujiang写道：
Hello

在 2016年6月20日下午8:21， <mjay...@gmail.com>写道：
hi doujiang
这个timer.at不会一直存在。
尝试了doujiang说的方法，得到了火焰图，但是看不太明白，请教下，这个图能说明什么问题呢，

图中显示的宽度，就是在 60s 内申请了还没有释放的内存

有没有什么资料可以对火焰图的分析说明下，感谢哈:)

想深入了解的话，你可以多了解下 systemtap，然后看看 sample-bt-leaks.sxx 源码，并不难理解

附：1.生成火焰图的命令：
./samples/sample-bt-leaks.sxx -x 55530 --arg time=60 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=10000 > a.bt

2.当时使用nginx-gdb-utils得到的lgcstat，看样子不太像泄漏在lua层面

确实，从火焰图里看，你的泄露点很明显在 nginx 的内存分配上

因为 nginx 是每请求有独立内存池，请求内的内存申请都从池中分配，在请求结束之前并不存在释放（只释放大内存段）

而，timer 本身也是一个请求（fake request），所以我们不应该让一个 timer 一直执行
你可以改下你的逻辑，每个 timer 跑一段时间就创建另一个 timer，又它来继续执行

(gdb) lgcstat
3250 str      objects: max=7262, avg = 51, min=18, sum=166035
624 upval    objects: max=24, avg = 24, min=24, sum=14976
   2 thread   objects: max=608, avg = 604, min=600, sum=1208
578 proto    objects: max=10495, avg = 642, min=80, sum=371260
1053 func     objects: max=144, avg = 29, min=20, sum=30648
16 trace    objects: max=5716, avg = 832, min=160, sum=13320
694 cdata    objects: max=16, avg = 15, min=12, sum=11100
1468 tab      objects: max=24608, avg = 218, min=32, sum=320328
210 udata    objects: max=1441886, avg = 7274, min=32, sum=1527590

sizeof strhash 32768
sizeof g->tmpbuf 512
sizeof ctype_state 4568
sizeof jit_state 24880

total sz 2524417
g->strnum 3250, g->gc.total 2524417可能是电话号码，是否拨号?
elapsed: 0.578708 sec

3. 火焰图（不知道如何上传svg图片，见谅:) ）

在 2016年6月14日星期二 UTC+8下午9:44:06，doujiang写道：
Hello

你的最终 timer 是一直存在，不断发起新的 http 请求么
还是 timer 是处理一定的 http 请求，就退出？

前者可能会有一定的内存泄露风险，最后采用后者

最好的定位办法是用内存泄露火焰图，此乃神器，你值得拥有
具体的时候方法，请多搜索本站以往的帖子
https://github.com/openresty/stapxx#sample-bt-leaks

在 2016年6月14日下午8:12， <mjay...@gmail.com>写道：
hi

请教一个关于nginx内存增长的问题。

我们的应用场景是这样的：每一个请求会创建N个ngx.time.at事件，其中每个ngx.time.at事件中会再次创建M个ngx.time.at事件（为了达到并发的效果），最终的ngx.time.at事件会构造新的http请求，然后根据响应做不同的正则匹配，正则匹配使用的是re2。
但是nginx在运行过程中，通过top看到VIRT和RES都在持续增长，增长后并不回退。请教下，大概会是什么原因导致的呢，这种情况下要如何定位问题呢？

我们的lua程序都通过lua-releng检测过无全局变量等。

--

--

--