nginx虚拟内存一直在飙升

melon198502

春哥

你好，我现在top查看nginx进程的虚拟内存一直在飙升（我的的环境是nginx1.4.2+luajit2.0.2+ngx_lua0.8.8），估计是有内存泄露了，我想使用nginx-systemtap-toolkit中的ngx-leaked-pools工具来调试，我看文档这个工具需要打上dtrace path，我该如何给标准的nginx打上这个包呢，我看了您的nginx_dtrace project好像并没有一个单独的path，我需要怎样做呢？请指教，谢谢！

melon198502

春哥我找到你的stap++工具试了一下，但还是不能确定是原因在哪？春哥帮忙看看
top的显示
PID USER      PR NI VIRT RES SHR S %CPU %MEM    TIME+ COMMAND
26121 www       15   0 15.1g 521m 2380 S 2.0 5.4   0:12.69 nginx

# ./samples/ngx-lj-gc.sxx -x 26121
Start tracing 26121 (/contec/nginx-1.4.2/sbin/nginx)
Total GC count: 391237 bytes

使用这个工具时提示如下错误
# ./samples/ngx-lj-gc-objs.sxx -x 26121
semantic error: type definition 'GCcdataVar' not found in '/contec/luajit-2.0.2/lib/libluajit-5.1.so.2.0.2': operator '@cast' at stapxx-lv1n5xky/luajit.stp:
47:31
        source: @define sizeof_GCcdataVar %( &@cast(0, "GCcdataVar", "/contec/luajit-2.0.2/lib/libluajit-5.1.so.2.0.2")[1] %)
                                              ^

semantic error: unresolved type : identifier 'cdatav' at :173:13
        source:             cdatav = cd - @sizeof_GCcdataVar
                            ^

Pass 2: analysis failed. [man error::pass2]
Number of similar error messages suppressed: 20.

#./samples/sample-bt-leaks.sxx -x 26121 --arg time=20 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=10000
用sample-bt-leaks生成的火焰图，见附件

Attachment: a.svg
Description: image/svg

agentzh

Hello!

On Thu, Nov 28, 2013 at 6:55 AM,  melon198502 wrote:
> top的显示
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 26121 www       15   0 15.1g 521m 2380 S  2.0  5.4   0:12.69 nginx
>

这里 VIRT 的大小并不重要，因为这个值包括了进程预留但尚未实际使用的虚拟内存页。这里重要的是 RES
这个指标，它反映了实际加载到进程空间中的内存页。不过这个值也会包括进程访问过的共享内存区域中的页，所以更准确的一个指标是使用 pmap -d
<pid> 命令得到最后一行输出里面的“writeable/private”这个指标。

你这里的 RES 值确实有些大。你观察过这个值会稳定地无限增长下去吗？

> # ./samples/ngx-lj-gc.sxx -x 26121                                                   > Start tracing 26121 (/contec/nginx-1.4.2/sbin/nginx)
> Total GC count: 391237 bytes
>

你的 Lua VM 使用的内存很小，只有不到 400KB. 所以应当是你使用的 Nginx 模块、Nginx 核心，或者直接使用了
malloc 等底层内存分配器的第三方 Lua C 模块占用了绝大部分的内存。

> 使用这个工具时提示如下错误
> # ./samples/ngx-lj-gc-objs.sxx -x 26121
> semantic error: type definition 'GCcdataVar' not found in
> '/contec/luajit-2.0.2/lib/libluajit-5.1.so.2.0.2': operator '@cast' at
> stapxx-lv1n5xky/luajit.stp:

这个错误很奇怪。你确认你的 LuaJIT 2.0.2 在用 make 命令构造时指定了 CCDEBUG=-g 参数么？即

    make CCDEBUG=-g

如果你使用的是 openresty 软件包，则其自带的 LuaJIT 2 在构造时总会启用其调试符号。

>
> #./samples/sample-bt-leaks.sxx -x 26121 --arg time=20 -D STP_NO_OVERLOAD -D
> MAXMAPENTRIES=10000
> 用sample-bt-leaks生成的火焰图，见附件
>

你提供的这个火焰图明显不是由 sample-bt-leaks 工具生成的“内存泄漏火焰图”，因为图中所有调用栈的顶部都不是内存分配函数，而是
epoll_wait 和 pread 这些会阻塞当前线程的系统调用。看起来这张图应该是 sample-bt-off-cpu
工具生成的“off-CPU 火焰图”。请你仔细确认你的操作步骤。

由于根据你的 ngx-lj-gc 工具的输出，可以断定绝大部分内存并不是由 Lua
分配的，所以你可以集中力量于“内存泄漏火焰图”上（如果你的 nginx 进程确实在稳定地泄漏内存的话）。

Regards,
-agentzh

melon198502

多谢春哥回复！

在 2013年11月29日星期五UTC+8上午3时08分22秒，agentzh写道：

Hello!

On Thu, Nov 28, 2013 at 6:55 AM, melon198502 wrote:
> top的显示
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 26121 www 15 0 15.1g 521m 2380 S 2.0 5.4 0:12.69 nginx
>

这里 VIRT 的大小并不重要，因为这个值包括了进程预留但尚未实际使用的虚拟内存页。这里重要的是 RES
这个指标，它反映了实际加载到进程空间中的内存页。不过这个值也会包括进程访问过的共享内存区域中的页，所以更准确的一个指标是使用 pmap -d
<pid> 命令得到最后一行输出里面的“writeable/private”这个指标。

你这里的 RES 值确实有些大。你观察过这个值会稳定地无限增长下去吗？

我观察了这个值确实会无限增长下去，今天找到导致VIRT和RES不断增长的地方，并构建了一个最小化示例来重现这种情况
        location = /test {
            content_by_lua '
                while true do
                    local res = ngx.location.capture("/test.php")
                    if not res or res.status~=ngx.HTTP_OK then
                        break
                    end
                    ngx.sleep(2)
                end
                ngx.exit(ngx.HTTP_OK)
            ';
        }

test.php
<?php
echo "abcedefg,abcdefg";
?>

curl http://localhost/test &
我用curl开了10个请求就复现了这种现象，但不知道具体什么原因导致的，希望春哥帮忙分析分析

> # ./samples/ngx-lj-gc.sxx -x 26121 > Start tracing 26121 (/contec/nginx-1.4.2/sbin/nginx)
> Total GC count: 391237 bytes
>

你的 Lua VM 使用的内存很小，只有不到 400KB. 所以应当是你使用的 Nginx 模块、Nginx 核心，或者直接使用了
malloc 等底层内存分配器的第三方 Lua C 模块占用了绝大部分的内存。

> 使用这个工具时提示如下错误
> # ./samples/ngx-lj-gc-objs.sxx -x 26121
> semantic error: type definition 'GCcdataVar' not found in
> '/contec/luajit-2.0.2/lib/libluajit-5.1.so.2.0.2': operator '@cast' at
> stapxx-lv1n5xky/luajit.stp:

这个错误很奇怪。你确认你的 LuaJIT 2.0.2 在用 make 命令构造时指定了 CCDEBUG=-g 参数么？即

make CCDEBUG=-g

如果你使用的是 openresty 软件包，则其自带的 LuaJIT 2 在构造时总会启用其调试符号。

我开始安装的时候没加，好多nginx-systemtap-toolkit, stapxx里的工具用不了，重装完其它的都能用了，目前就发现这个不能用，我再重装下看看吧

>
> #./samples/sample-bt-leaks.sxx -x 26121 --arg time=20 -D STP_NO_OVERLOAD -D
> MAXMAPENTRIES=10000
> 用sample-bt-leaks生成的火焰图，见附件
>

你提供的这个火焰图明显不是由 sample-bt-leaks 工具生成的“内存泄漏火焰图”，因为图中所有调用栈的顶部都不是内存分配函数，而是
epoll_wait 和 pread 这些会阻塞当前线程的系统调用。看起来这张图应该是 sample-bt-off-cpu
工具生成的“off-CPU 火焰图”。请你仔细确认你的操作步骤。

我确实是按照您stapxx文档中的示例操作的，我看火焰图中调用栈的顶部是ngx_alloc,ngx_palloc_large这样的调用啊，这些不是内存分配函数吗？

由于根据你的 ngx-lj-gc 工具的输出，可以断定绝大部分内存并不是由 Lua
分配的，所以你可以集中力量于“内存泄漏火焰图”上（如果你的 nginx 进程确实在稳定地泄漏内存的话）。

Regards,
-agentzh

best regrads
-melon

agentzh

Hello!

2013/11/29  melon198502:
>
> 我观察了这个值 确实会无限增长下去，今天找到导致VIRT和RES不断增长的地方，并构建了一个最小化示例来重现这种情况
>         location = /test {
>             content_by_lua '
>                 while true do
>                     local res = ngx.location.capture("/test.php")

>             ';

你的这个例子本身没有什么实际意义，因为 ngx.location.capture()
发起的子请求所分配的内存总是会推迟到主请求退出时释放。Nginx
核心中对于子请求的内存处理策略是假设主请求会在短时间内结束，而不是像这样在单个主请求内部无限循环下去。

>
> 我确实是按照您stapxx文档中的示例操作的，我看火焰图中调用栈的顶部是ngx_alloc,ngx_palloc_large这样的调用啊，这些不是内存分配函数吗？
>

我又重看了一下，你的内存泄漏火焰图确实是正确的，我当时应当是混淆了我系统中的另一个名叫 a.svg 的文件。

从你提供的内存泄漏火焰图上看，看起来很像是子请求内部的 upstream
模块释放的内存还未及释放（即还在等待主请求的结束）。如果你使用子请求的话，应当避免这种长时间循环下去的用法。或者反过来，如果你一定要使用这种用法，应当避免使用子请求。

Regards,
-agentzh

melon198502

谢春哥，明白了，是我误用子请求了，主要还是不明白内部实现，是时候该好好看看源码了

Best regards

-melon

在 2013年11月30日下午12:30，Yichun Zhang (agentzh) <age...@gmail.com>写道：

Hello!

2013/11/29 melon198502:

>
> 我观察了这个值确实会无限增长下去，今天找到导致VIRT和RES不断增长的地方，并构建了一个最小化示例来重现这种情况
> location = /test {
> content_by_lua '
> while true do
> local res = ngx.location.capture("/test.php")

> ';

你的这个例子本身没有什么实际意义，因为 ngx.location.capture()
发起的子请求所分配的内存总是会推迟到主请求退出时释放。Nginx
核心中对于子请求的内存处理策略是假设主请求会在短时间内结束，而不是像这样在单个主请求内部无限循环下去。

>
> 我确实是按照您stapxx文档中的示例操作的，我看火焰图中调用栈的顶部是ngx_alloc,ngx_palloc_large这样的调用啊，这些不是内存分配函数吗？
>

我又重看了一下，你的内存泄漏火焰图确实是正确的，我当时应当是混淆了我系统中的另一个名叫 a.svg 的文件。

从你提供的内存泄漏火焰图上看，看起来很像是子请求内部的 upstream
模块释放的内存还未及释放（即还在等待主请求的结束）。如果你使用子请求的话，应当避免这种长时间循环下去的用法。或者反过来，如果你一定要使用这种用法，应当避免使用子请求。

Regards,
-agentzh

--