ngx.ctx 在高并发的情况下，不同的请求之间的ngx.ctx会互串

wl19871011 · 2013-11-22T11:42:37+00:00

Hello! 2013/11/21 xinqiyang: > uname -rm > 3.9.3-x86_64-linode33 x86_64 , 这个是被Linode升级过的&#x51...

ngx.ctx 在高并发的情况下，不同的请求之间的ngx.ctx会互串

wl19871011

我们这边在做接口的异步化，目前已经上线一台，在观察统计日志的时候，发现不同请求打印的日志信息出现数据互串的情况。

这边的业务逻辑比较多，所以采用多个module，拆分业务逻辑放到多个文件中。

nginx中的配置采用指令content_by_lua_file "index.lua"

整个请求生命周期中需要保存一些数据，方便在请求结束前打印统计日志或者给其他逻辑使用。所以这边采用了ngx.ctx作为单个请求生命周期的data存储表。

但是在开启lua_code_cache后，高并发的情况下，不同请求下打印的日志会数据互串。（这个请求打印的统计日志是另外一个请求的数据）

ps 现在发现的现象是我们的业务逻辑有很多网络io操作，这些都采用cosocket。在发送之前打印的ctx.xx值跟发起之后打印的ctx.xx完全不一样

在module里面使用ctx样例如下

local ctx=ngx.ctx

module(...)

function xxx () {

ctx.xxx = val1

network io

print(ctx.xxx) 这个打印出来的是其他请求的数据

}

这个如何解决呢？或者有什么好的方案吗？

还有个问题是发现nginx猛吃内存,达到10GB，这边也使用了share_dict，才150mb。其余逻辑都是网络io操作，没有全局变量都是Lcoal var和module function调用

使用的版本是nginx 1.4.2和ngx_lua 0.9.0

agentzh

Hello!

2013/11/21 wl1011:
>          在module里面使用ctx样例如下
>          local ctx=ngx.ctx
>          module(...)
>          function xxx () {
>                 ctx.xxx = val1
>                 network io
>                 print(ctx.xxx) 这个打印出来的是其他请求的数据
>          }
>

这里的用法是错误的。不应在 module 顶层保存 ngx.ctx 返回的 table. ngx.ctx 是通过 ngx 表的
__index 元方法返回每请求的 table 的，如果你在顶层把某一次 __index 元方法返回的当前请求的 table
保存起来复用，则后续所有的请求都将使用同一个 Lua table 了（见
https://github.com/chaoslawful/lua-nginx-module#data-sharing-within-an-nginx-worker
）。正确的做法是在 function xxx () 里直接使用 ngx.ctx.xxx.

当然，另一个明显的错误是你使用了 {} 作为函数体定义，这不合乎 Lua 的语法。

另外，不建议使用 module() 函数定义 Lua 模块，因为这个函数有创建全局变量的副作用。推荐的写法是

    local _M = {}

    function _M.xxx ()
        ngx.ctx.xxx = val1
        -- network io
        print(ngx.ctx.xxx)
    end

    return _M

同时推荐使用 lua-releng 工具扫描你的 Lua 代码，找出所有使用全局变量的地方（它们是请求间串数据的主要根源）。更多细节可以参见

    https://github.com/chaoslawful/lua-nginx-module#lua-variable-scope

Best regards,
-agentzh

wl19871011

谢谢问题解决了。

顺便请教个问题，这边在使用ngx_lua的时候，我们自己也写了一些lua的so，但是每次替换新的so的时候ngx 重启都会出一次core。这个有什么好的方法解决吗？

还有关于ngx自身内存猛涨的情况，有什么好的方案排查吗？

在 2013年11月22日星期五UTC+8下午12时24分38秒，agentzh写道：

Hello!

2013/11/21 wl1011:
> 在module里面使用ctx样例如下
> local ctx=ngx.ctx
> module(...)
> function xxx () {
> ctx.xxx = val1
> network io
> print(ctx.xxx) 这个打印出来的是其他请求的数据
> }
>

这里的用法是错误的。不应在 module 顶层保存 ngx.ctx 返回的 table. ngx.ctx 是通过 ngx 表的
__index 元方法返回每请求的 table 的，如果你在顶层把某一次 __index 元方法返回的当前请求的 table
保存起来复用，则后续所有的请求都将使用同一个 Lua table 了（见
https://github.com/chaoslawful/lua-nginx-module#data-sharing-within-an-nginx-worker
）。正确的做法是在 function xxx () 里直接使用 ngx.ctx.xxx.

当然，另一个明显的错误是你使用了 {} 作为函数体定义，这不合乎 Lua 的语法。

另外，不建议使用 module() 函数定义 Lua 模块，因为这个函数有创建全局变量的副作用。推荐的写法是

local _M = {}

function _M.xxx ()
ngx.ctx.xxx = val1
-- network io
print(ngx.ctx.xxx)
end

return _M

同时推荐使用 lua-releng 工具扫描你的 Lua 代码，找出所有使用全局变量的地方（它们是请求间串数据的主要根源）。更多细节可以参见

https://github.com/chaoslawful/lua-nginx-module#lua-variable-scope

Best regards,
-agentzh

agentzh

Hello!

2013/11/21 wl1011:
>
> 顺便请教个问题，这边在使用ngx_lua的时候，我们自己也写了一些lua的so，但是每次替换新的so的时候ngx
> 重启都会出一次core。这个有什么好的方法解决吗？
>

建议从 core dump 获取崩溃发生位置上的调用栈信息，见

    http://wiki.nginx.org/Debugging#Core_dump

> 还有关于ngx自身内存猛涨的情况，有什么好的方案排查吗？
>

有许多基于 systemtap 的动态追踪工具可用于诊断 nginx worker 进程的内存泄漏问题，比如

https://github.com/agentzh/stapxx#ngx-lj-gc
https://github.com/agentzh/stapxx#ngx-lj-gc-objs
https://github.com/agentzh/nginx-systemtap-toolkit#ngx-leaked-pools
https://github.com/agentzh/nginx-systemtap-toolkit#ngx-cycle-pool
https://github.com/agentzh/stapxx#sample-bt-leaks

当然 pmap -d、top 等系统命令也会提供一些有用的信息。

Regards,
-agentzh