nginx+lua报错libluajit-5.1.so.2.0.0

guoyang3 · 2014-07-02T20:17:44+00:00

检查一下 lua_code_cache on 是否已经打开

nginx+lua报错libluajit-5.1.so.2.0.0

guoyang3

大家知道这个是什么错误？

nginx[19586]: segfault at 14 ip 00007fc6b5c02059 sp 00007fff983730f8 error 4 in libluajit-5.1.so.2.0.0[7fc6b5bf4000+6c000]

guoyang3

我的cat messages-20140615|grep nginx里总会报这个错误或者用dmesg这个命令查看

发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表郭阳3
发送时间: 2014年7月2日 20:18
收件人: openresty@googlegroups.com
主题: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

大家知道这个是什么错误？

nginx[19586]: segfault at 14 ip 00007fc6b5c02059 sp 00007fff983730f8 error 4 in libluajit-5.1.so.2.0.0[7fc6b5bf4000+6c000]

--
--

agentzh

Hello!

2014-07-02 5:17 GMT-07:00 郭阳3:
> 大家知道这个是什么错误？
>
> nginx[19586]: segfault at 14 ip 00007fc6b5c02059 sp 00007fff983730f8 error 4
> in libluajit-5.1.so.2.0.0[7fc6b5bf4000+6c000]
>

你的 LuaJIT VM 发生了崩溃。我看到你使用的是 LuaJIT 2.0.0，这个古老的版本含有很多已知的 bug，建议至少升级到
2.0.x 系列的最新版本（目前是 2.0.3），或者直接使用 git 仓库里的版本。

一般地，对于这样的问题的调试，至少需要取得崩溃位置上较为完整的调用栈（见 http://wiki.nginx.org/Debugging#Core_dump ）

最后一个建议是，尽量总是使用最新的 openresty 发布以避免很多不必要的麻烦：

     http://openresty.org/#Download

Regards,
-agentzh

guoyang3

谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，而且日志里总报
[error] 29597#0: *11174695624 failed to load Lua inlined code: cannot open /letv/www/api/getVideoListOut.lua: No such file or directory,
难道是nginx每次都加载lua文件的原因吗

-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月3日 4:58
收件人: openresty
主题: Re: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 5:17 GMT-07:00 郭阳3:
> 大家知道这个是什么错误？
>
> nginx[19586]: segfault at 14 ip 00007fc6b5c02059 sp 00007fff983730f8 
> error 4 in libluajit-5.1.so.2.0.0[7fc6b5bf4000+6c000]
>

你的 LuaJIT VM 发生了崩溃。我看到你使用的是 LuaJIT 2.0.0，这个古老的版本含有很多已知的 bug，建议至少升级到
2.0.x 系列的最新版本（目前是 2.0.3），或者直接使用 git 仓库里的版本。

一般地，对于这样的问题的调试，至少需要取得崩溃位置上较为完整的调用栈（见 http://wiki.nginx.org/Debugging#Core_dump ）

最后一个建议是，尽量总是使用最新的 openresty 发布以避免很多不必要的麻烦：

     http://openresty.org/#Download

Regards,
-agentzh

--

agentzh

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core
dump 进行分析和排查：

    https://github.com/openresty/nginx-gdb-utils#lgcstat

    https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

agentzh

Hello!

2014-07-03 14:26 GMT-07:00 Yichun Zhang (agentzh):
> 1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者
>

不好意思，这里有一处笔误，应作“强烈建议不要在生产环境禁用 Lua 代码缓存”。

Regards,
-agentzh

guoyang3

这个是我的代码：

local memcached = require "lib.resty.memcached"
local PLATFORM_PLAYPLATFORM_MAP = require "conf.platformtable"

--local cjson = require "cjson"

DEFAULT_NUM_PAGE = 1
DEFAULT_NUM_PER_PAGE = 20
MAX_NUM_PER_PAGE = 100
PORDER_ASC = -1

--缓存key生成策略 和后端二级缓存key要一致
function generateVideoListSecondLevelKey(pid, b, s, o, vid, platformId)
    local secondLevelCacheKey
    secondLevelCacheKey = "ALBUM_VLIST_"..pid.."_"..b.."_"..s.."_"..o
    if vid ~= nil then
        secondLevelCacheKey = secondLevelCacheKey.."_"..vid
    end
    if platformId ~= nil then
        secondLevelCacheKey = secondLevelCacheKey.."_"..platformId
    end
    return secondLevelCacheKey
end

--加载数据从resin
function getDataFromResin(url)
    res=ngx.location.capture(url)
    return res.body  
end

function getArgs()
    local arg = ""
    local args = ngx.req.get_uri_args()
    for key, val in pairs(args) do
        if type(val) == "table" then
		    arg = arg .. key .. "=" .. table.concat(val, ", ") .. "&"
        else
		    arg = arg .. key .. "=" .. val .. "&"
        end
    end
	
	return string.sub(arg,0,-2)
end

id = ngx.var.arg_id
b = ngx.var.arg_b               
s = ngx.var.arg_s
o = ngx.var.arg_o
vid = ngx.var.arg_vid
p = ngx.var.arg_p
platform = ngx.var.arg_platform

--ngx.log(ngx.ERR,"run")

if id == nil then
   --ngx.say(cjson.encode({callback="",data=null,msgs={"专辑ID为空"},result = 0}))
   id = ""
end

if platform == nil then
	platform = ""
end

if b == nil then
    b = DEFAULT_NUM_PAGE;
end

if s == nil then
    s = DEFAULT_NUM_PER_PAGE
elseif tonumber(s) > MAX_NUM_PER_PAGE then
    s =  MAX_NUM_PER_PAGE
end

if o == nil then
    o =  PORDER_ASC
end

local platformId
if p == nil then
    platformId = PLATFORM_PLAYPLATFORM_MAP[platform]
else
    platformId = p
end

if platformId == nil then
	platformId = platform
end

local key = generateVideoListSecondLevelKey(id, b, s, o, vid, platformId)

local memc,err = memcached:new()
if not memc then
    --ngx.say("failed")
	ngx.log(ngx.ERR,"new cbase fail!")
	--new cbase有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
    return
end

memc:set_timeout(1000)
local ok, err = memc:connect("127.0.0.1",11211)
if not ok then
    --ngx.say("fail")
	ngx.log(ngx.ERR,"connect the cbase fail!"..err)
	--连接cbase有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
    return
end
         
local res, flags, err = memc:get(key)
if err then
    --ngx.say("failed to get : ", err)
	ngx.log(ngx.ERR,"failed to get : "..key)
	--获取cbase数据有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
	memc:set_keepalive(10000, 100)
    return
end

local result
              
if res ~= nil then
    result = res
end

if not res then
	ngx.log(ngx.ERR,"load from resin,the key "..key)
    --res=ngx.location.capture("/t/mms/inner/albumInfo/getVideoList?id=76913&platform=pc")
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs())    
    local ok, err = memc:set(key, result,600)
    if not ok then
		ngx.log(ngx.ERR,"failed to set : "..key)
        --return
    end	
else
	ngx.log(ngx.ERR,"hit it:"..key)
end
ngx.say(result)
memc:set_keepalive(10000, 100)

以上代码很简单的逻辑 我这里也没有查出什么问题，我挨个删除代码，在local res, flags, err = memc:get(key)这块取数据的时候，nginx实际占用内存会升高，
基本数据为90kb左右的，我想大并发量下把取出的数据放在变量里，nginx肯定会实际内存占用量升高的，vm应该垃圾回收不是那么快的。请帮看看代码哪里还有问题！我试过都换成最新的luajit效果貌似也不太明显（还会有nginx占用内存升高）但是没出现线上的内存溢出现象，我在测试环境测不出来线上的问题可能打压不够，模仿不了。对lua语言不太熟……，现学现用

-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

    https://github.com/openresty/nginx-gdb-utils#lgcstat

    https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot 
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--

guoyang3

又看了一次日志 发现许多如下错误，摘录两条
nginx: lua atpanic: Lua VM crashed, reason: not enough memory
2014/07/02 21:39:41 [error] 9948#0: *11198714680 lua entry thread aborted: memory allocation error: not enough memory
        /letv/www/api/lib/resty/memcached.lua:169: in function 'get'
nginx: lua atpanic: Lua VM crashed, reason: not enough memory
2014/07/02 21:44:23 [error] 32090#0: *11199251874 lua entry thread aborted: memory allocation error: not enough memory
        /letv/www/api/lib/resty/memcached.lua:341: in function 'set'

难道是memcached.lua:341这个的问题？我们的访问量非常大，是不是memcached.lua里有bug造成了内存溢出，我的代码在上封邮件里。

-----邮件原件-----
发件人: 郭阳3 
发送时间: 2014年7月7日 14:24
收件人: openresty
主题: 答复: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

这个是我的代码：

local memcached = require "lib.resty.memcached"
local PLATFORM_PLAYPLATFORM_MAP = require "conf.platformtable"

--local cjson = require "cjson"

DEFAULT_NUM_PAGE = 1
DEFAULT_NUM_PER_PAGE = 20
MAX_NUM_PER_PAGE = 100
PORDER_ASC = -1

--缓存key生成策略 和后端二级缓存key要一致
function generateVideoListSecondLevelKey(pid, b, s, o, vid, platformId)
    local secondLevelCacheKey
    secondLevelCacheKey = "ALBUM_VLIST_"..pid.."_"..b.."_"..s.."_"..o
    if vid ~= nil then
        secondLevelCacheKey = secondLevelCacheKey.."_"..vid
    end
    if platformId ~= nil then
        secondLevelCacheKey = secondLevelCacheKey.."_"..platformId
    end
    return secondLevelCacheKey
end

--加载数据从resin
function getDataFromResin(url)
    res=ngx.location.capture(url)
    return res.body
end

function getArgs()
    local arg = ""
    local args = ngx.req.get_uri_args()
    for key, val in pairs(args) do
        if type(val) == "table" then
		    arg = arg .. key .. "=" .. table.concat(val, ", ") .. "&"
        else
		    arg = arg .. key .. "=" .. val .. "&"
        end
    end
	
	return string.sub(arg,0,-2)
end

id = ngx.var.arg_id
b = ngx.var.arg_b               
s = ngx.var.arg_s
o = ngx.var.arg_o
vid = ngx.var.arg_vid
p = ngx.var.arg_p
platform = ngx.var.arg_platform

--ngx.log(ngx.ERR,"run")

if id == nil then
   --ngx.say(cjson.encode({callback="",data=null,msgs={"专辑ID为空"},result = 0}))
   id = ""
end

if platform == nil then
	platform = ""
end

if b == nil then
    b = DEFAULT_NUM_PAGE;
end

if s == nil then
    s = DEFAULT_NUM_PER_PAGE
elseif tonumber(s) > MAX_NUM_PER_PAGE then
    s =  MAX_NUM_PER_PAGE
end

if o == nil then
    o =  PORDER_ASC
end

local platformId
if p == nil then
    platformId = PLATFORM_PLAYPLATFORM_MAP[platform]
else
    platformId = p
end

if platformId == nil then
	platformId = platform
end

local key = generateVideoListSecondLevelKey(id, b, s, o, vid, platformId)

local memc,err = memcached:new()
if not memc then
    --ngx.say("failed")
	ngx.log(ngx.ERR,"new cbase fail!")
	--new cbase有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
    return
end

memc:set_timeout(1000)
local ok, err = memc:connect("127.0.0.1",11211) if not ok then
    --ngx.say("fail")
	ngx.log(ngx.ERR,"connect the cbase fail!"..err)
	--连接cbase有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
    return
end
         
local res, flags, err = memc:get(key)
if err then
    --ngx.say("failed to get : ", err)
	ngx.log(ngx.ERR,"failed to get : "..key)
	--获取cbase数据有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
	memc:set_keepalive(10000, 100)
    return
end

local result
              
if res ~= nil then
    result = res
end

if not res then
	ngx.log(ngx.ERR,"load from resin,the key "..key)
    --res=ngx.location.capture("/t/mms/inner/albumInfo/getVideoList?id=76913&platform=pc")
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs())    
    local ok, err = memc:set(key, result,600)
    if not ok then
		ngx.log(ngx.ERR,"failed to set : "..key)
        --return
    end	
else
	ngx.log(ngx.ERR,"hit it:"..key)
end
ngx.say(result)
memc:set_keepalive(10000, 100)

以上代码很简单的逻辑 我这里也没有查出什么问题，我挨个删除代码，在local res, flags, err = memc:get(key)这块取数据的时候，nginx实际占用内存会升高，
基本数据为90kb左右的，我想大并发量下把取出的数据放在变量里，nginx肯定会实际内存占用量升高的，vm应该垃圾回收不是那么快的。请帮看看代码哪里还有问题！我试过都换成最新的luajit效果貌似也不太明显（还会有nginx占用内存升高）但是没出现线上的内存溢出现象，我在测试环境测不出来线上的问题可能打压不够，模仿不了。对lua语言不太熟……，现学现用

-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

    https://github.com/openresty/nginx-gdb-utils#lgcstat

    https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot 
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--

guoyang3

又看了一次日志 发现许多如下错误，摘录两条

2014/07/02 17:45:19 [error] 30602#0: *11175540681 lua entry thread aborted: memory allocation error: not enough memory
stack traceback:
coroutine 0:
        [C]: in function 'concat'
        /letv/www/api/lib/resty/memcached.lua:341: in function 'set'

nginx: lua atpanic: Lua VM crashed, reason: not enough memory
2014/07/02 21:39:41 [error] 9948#0: *11198714680 lua entry thread aborted: memory allocation error: not enough memory
        /letv/www/api/lib/resty/memcached.lua:169: in function 'get'
nginx: lua atpanic: Lua VM crashed, reason: not enough memory
2014/07/02 21:44:23 [error] 32090#0: *11199251874 lua entry thread aborted: memory allocation error: not enough memory
        /letv/www/api/lib/resty/memcached.lua:341: in function 'set'

难道是memcached.lua:341这个的问题？我们的访问量非常大，是不是memcached.lua里有bug造成了内存溢出，我的代码在上封邮件里。
因为在本地测试服务器打压力测试根本复现不了问题，用tcpcopy把线上的请求引导测试服务器 也是不能重现问题，只要一上线就会有问题……（现象是用top看nginx
有8个worker，其中两个内存涨到了1G多，其他还正常，这个时候就会报错了）而且测试服务器和线上的一样的软件，一样的配置。
用gdb查问题如下：
(gdb) where
#0  0x00007fe7ab288059 in ?? ()
Cannot access memory at address 0x7fffcfe30388
就没有下文了 不知道什么意思 哪段代码有问题。

请大家帮看下 困扰太长时间了
2014/07/02 17:45:19 [error] 30602#0: *11175540681 lua entry thread aborted: memory allocation error: not enough memory
stack traceback:
coroutine 0:
        [C]: in function 'concat'
        /letv/www/api/lib/resty/memcached.lua:341: in function 'set'


-----邮件原件-----
发件人: 郭阳3 
发送时间: 2014年7月7日 14:24
收件人: openresty
主题: 答复: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

这个是我的代码：

local memcached = require "lib.resty.memcached"
local PLATFORM_PLAYPLATFORM_MAP = require "conf.platformtable"

--local cjson = require "cjson"

DEFAULT_NUM_PAGE = 1
DEFAULT_NUM_PER_PAGE = 20
MAX_NUM_PER_PAGE = 100
PORDER_ASC = -1

--缓存key生成策略 和后端二级缓存key要一致
function generateVideoListSecondLevelKey(pid, b, s, o, vid, platformId)
    local secondLevelCacheKey
    secondLevelCacheKey = "ALBUM_VLIST_"..pid.."_"..b.."_"..s.."_"..o
    if vid ~= nil then
        secondLevelCacheKey = secondLevelCacheKey.."_"..vid
    end
    if platformId ~= nil then
        secondLevelCacheKey = secondLevelCacheKey.."_"..platformId
    end
    return secondLevelCacheKey
end

--加载数据从resin
function getDataFromResin(url)
    res=ngx.location.capture(url)
    return res.body
end

function getArgs()
    local arg = ""
    local args = ngx.req.get_uri_args()
    for key, val in pairs(args) do
        if type(val) == "table" then
		    arg = arg .. key .. "=" .. table.concat(val, ", ") .. "&"
        else
		    arg = arg .. key .. "=" .. val .. "&"
        end
    end
	
	return string.sub(arg,0,-2)
end

id = ngx.var.arg_id
b = ngx.var.arg_b               
s = ngx.var.arg_s
o = ngx.var.arg_o
vid = ngx.var.arg_vid
p = ngx.var.arg_p
platform = ngx.var.arg_platform

--ngx.log(ngx.ERR,"run")

if id == nil then
   --ngx.say(cjson.encode({callback="",data=null,msgs={"专辑ID为空"},result = 0}))
   id = ""
end

if platform == nil then
	platform = ""
end

if b == nil then
    b = DEFAULT_NUM_PAGE;
end

if s == nil then
    s = DEFAULT_NUM_PER_PAGE
elseif tonumber(s) > MAX_NUM_PER_PAGE then
    s =  MAX_NUM_PER_PAGE
end

if o == nil then
    o =  PORDER_ASC
end

local platformId
if p == nil then
    platformId = PLATFORM_PLAYPLATFORM_MAP[platform]
else
    platformId = p
end

if platformId == nil then
	platformId = platform
end

local key = generateVideoListSecondLevelKey(id, b, s, o, vid, platformId)

local memc,err = memcached:new()
if not memc then
    --ngx.say("failed")
	ngx.log(ngx.ERR,"new cbase fail!")
	--new cbase有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
    return
end

memc:set_timeout(1000)
local ok, err = memc:connect("127.0.0.1",11211) if not ok then
    --ngx.say("fail")
	ngx.log(ngx.ERR,"connect the cbase fail!"..err)
	--连接cbase有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
    return
end
         
local res, flags, err = memc:get(key)
if err then
    --ngx.say("failed to get : ", err)
	ngx.log(ngx.ERR,"failed to get : "..key)
	--获取cbase数据有问题 直接从resin取数据	
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs()) 
	ngx.say(result)
	memc:set_keepalive(10000, 100)
    return
end

local result
              
if res ~= nil then
    result = res
end

if not res then
	ngx.log(ngx.ERR,"load from resin,the key "..key)
    --res=ngx.location.capture("/t/mms/inner/albumInfo/getVideoList?id=76913&platform=pc")
    result = getDataFromResin("/t"..ngx.var.uri.."?"..getArgs())    
    local ok, err = memc:set(key, result,600)
    if not ok then
		ngx.log(ngx.ERR,"failed to set : "..key)
        --return
    end	
else
	ngx.log(ngx.ERR,"hit it:"..key)
end
ngx.say(result)
memc:set_keepalive(10000, 100)

以上代码很简单的逻辑 我这里也没有查出什么问题，我挨个删除代码，在local res, flags, err = memc:get(key)这块取数据的时候，nginx实际占用内存会升高，
基本数据为90kb左右的，我想大并发量下把取出的数据放在变量里，nginx肯定会实际内存占用量升高的，vm应该垃圾回收不是那么快的。请帮看看代码哪里还有问题！我试过都换成最新的luajit效果貌似也不太明显（还会有nginx占用内存升高）但是没出现线上的内存溢出现象，我在测试环境测不出来线上的问题可能打压不够，模仿不了。对lua语言不太熟……，现学现用

-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

    https://github.com/openresty/nginx-gdb-utils#lgcstat

    https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot 
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--

agentzh

Hello!

2014-07-20 19:52 GMT-07:00 郭阳3:
> 又看了一次日志 发现许多如下错误，摘录两条
> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
[...]
> 难道是memcached.lua:341这个的问题？我们的访问量非常大，是不是memcached.lua里有bug造成了内存溢出，我的代码在上封邮件里。
>

貌似你几乎完全忽略了我之前的几封回信里的建议，而只是一直在自说自话。建议仔细阅读我前几封邮件里的建议，然后我们再接着讨论。

Regards,
-agentzh

guoyang3

感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。
我的nginx配置：
    lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;";
    lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";

lua脚本是如下：
local memcached = require "lib.resty.memcached"
local czip  = require("ziplib")
只发下这些加载项，怀疑可能和这个有关，春哥能否帮看下，是否正确，拿不定的是lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;"; 这后面的两个分号是什么意思，如果不这么做，我的里面的
Lua程序加载不进来，这个是我网上找的试试可以，就是不知道什么意思。还有lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";这些so文件我放到其他地方引用有没有问题，以及local czip  = require("ziplib")这个引用是否正确，这个是我们做的一个c代码来进行解压缩的


-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

    https://github.com/openresty/nginx-gdb-utils#lgcstat

    https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot 
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--

smallfish.xy

package_path 里的 ";;" 可以参考：http://www.lua.org/manual/5.1/manual.html

smallfish http://chenxiaoyu.org

2014-08-04 11:03 GMT+08:00 郭阳3 <guo...@letv.com>:

感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。
我的nginx配置：
lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;";
lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";

lua脚本是如下：

local memcached = require "lib.resty.memcached"

local czip = require("ziplib")
只发下这些加载项，怀疑可能和这个有关，春哥能否帮看下，是否正确，拿不定的是lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;"; 这后面的两个分号是什么意思，如果不这么做，我的里面的
Lua程序加载不进来，这个是我网上找的试试可以，就是不知道什么意思。还有lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";这些so文件我放到其他地方引用有没有问题，以及local czip = require("ziplib")这个引用是否正确，这个是我们做的一个c代码来进行解压缩的

-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)

发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

https://github.com/openresty/nginx-gdb-utils#lgcstat

https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--

--

hi.laowang

我觉得只要RES正常，VIRT上涨是无所谓的

On Monday, August 4, 2014 11:03:01 AM UTC+8, 郭阳3 wrote:

感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。
我的nginx配置：
lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;";
lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";

lua脚本是如下：
local memcached = require "lib.resty.memcached"
local czip = require("ziplib")
只发下这些加载项，怀疑可能和这个有关，春哥能否帮看下，是否正确，拿不定的是lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;"; 这后面的两个分号是什么意思，如果不这么做，我的里面的
Lua程序加载不进来，这个是我网上找的试试可以，就是不知道什么意思。还有lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";这些so文件我放到其他地方引用有没有问题，以及local czip = require("ziplib")这个引用是否正确，这个是我们做的一个c代码来进行解压缩的

-----邮件原件-----
发件人: open...@googlegroups.com [mailto:open...@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

https://github.com/openresty/nginx-gdb-utils#lgcstat

https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--

guoyang3

如果一直增长也会造成内存溢出吧，除非nginx会kill掉那个进程重启一个

发件人: 老王 [mailto:hi.l...@gmail.com]
发送时间: 2014年8月4日 14:02
收件人: openresty@googlegroups.com
抄送: 郭阳3
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

我觉得只要RES正常，VIRT上涨是无所谓的

On Monday, August 4, 2014 11:03:01 AM UTC+8, 郭阳3 wrote:

感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。
我的nginx配置：
lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;";
lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";

lua脚本是如下：
local memcached = require "lib.resty.memcached"
local czip = require("ziplib")
只发下这些加载项，怀疑可能和这个有关，春哥能否帮看下，是否正确，拿不定的是lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;"; 这后面的两个分号是什么意思，如果不这么做，我的里面的
Lua程序加载不进来，这个是我网上找的试试可以，就是不知道什么意思。还有lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";这些so文件我放到其他地方引用有没有问题，以及local czip = require("ziplib")这个引用是否正确，这个是我们做的一个c代码来进行解压缩的

-----

hi.laowang

virt只是理论值吧，多点无所谓

On Monday, August 4, 2014 4:00:54 PM UTC+8, 郭阳3 wrote:

如果一直增长也会造成内存溢出吧，除非nginx会kill掉那个进程重启一个

发件人: 老王 [mailto:hi.la...@gmail.com]
发送时间: 2014年8月4日 14:02
收件人: open...@googlegroups.com
抄送: 郭阳3
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

我觉得只要RES正常，VIRT上涨是无所谓的

On Monday, August 4, 2014 11:03:01 AM UTC+8, 郭阳3 wrote:

感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。
我的nginx配置：
lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;";
lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";

lua脚本是如下：
local memcached = require "lib.resty.memcached"
local czip = require("ziplib")
只发下这些加载项，怀疑可能和这个有关，春哥能否帮看下，是否正确，拿不定的是lua_package_path "/opt/www/geturlnew/?.lua;./?.lua;/opt/www/api/?.lua;;"; 这后面的两个分号是什么意思，如果不这么做，我的里面的
Lua程序加载不进来，这个是我网上找的试试可以，就是不知道什么意思。还有lua_package_cpath "/opt/www/api/?.so;/usr/local/openresty/lualib/?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so";这些so文件我放到其他地方引用有没有问题，以及local czip = require("ziplib")这个引用是否正确，这个是我们做的一个c代码来进行解压缩的

-----邮件原件-----
发件人: open...@googlegroups.com [mailto:open...@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年7月4日 5:27
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-07-02 18:49 GMT-07:00 郭阳3:
> 谢谢春哥，昨天查到 nginx占用内存达到了2g而其他没有上线这个lua代码的只有200m左右，

你使用的 LuaJIT 2.0.0 这个老版本有已知的内存泄漏 bug. 我上一封邮件已经建议你至少升级到 2.0.3. 请按我说的去做。

另外，你需要仔细你的 Lua 代码本身的逻辑没有内存泄漏，比如你没有在请求处理程序中不断地向 package.path
这样的全局字符串不断追加新的内容数据，你也没有在你自己的模块级别的变量里不断追加数据（比如无限制地向一个 table 里插入数据），见
https://github.com/openresty/lua-nginx-module#data-sharing-within-an-nginx-worker

同时确保你使用的 nginx 和 ngx_lua
的版本足够新。如果不是最新版本，请首先尝试升级。正如我上一封邮件里建议的，“尽量总是使用最新的 openresty
发布以避免很多不必要的麻烦”。

特别地，对于 Lua 空间里的内存泄漏问题，可以使用我们的 lgcstat 和 lgcpath 这两个 gdb 扩展命令对进程或 core dump 进行分析和排查：

https://github.com/openresty/nginx-gdb-utils#lgcstat

https://github.com/openresty/nginx-gdb-utils#lgcpath

> 而且日志里总报
> [error] 29597#0: *11174695624 failed to load Lua inlined code: cannot
> open /letv/www/api/getVideoListOut.lua: No such file or directory,

显然你使用的是一个比较古老的 ngx_lua 模块的版本。升级后再看。

> 难道是nginx每次都加载lua文件的原因吗
>

ngx_lua 模块并不会在每次请求时现加载 .lua 文件，除非

1. 你在 nginx.conf 里面配置了“lua_code_cache off;”（强烈建议在生产环境禁用 Lua 代码缓存），或者

2. 你自己在请求处理程序里面使用 loadfile() 这样的标准 Lua 函数加载外部 .lua 文件，或者通过清空
package.loaded 表里的条目强制 require() 重新加载对应的 Lua 模块文件。

Regards,
-agentzh

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty...@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

agentzh

Hello!

2014-08-03 20:03 GMT-07:00 郭阳3:
> 感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
> 可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
> 不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。

VIRT 这个指标没有太大的意义，因为只是进程预留的虚拟内存地址空间。所以有时即使达到几 GB 甚至几 TB
也不一定会实际映射到物理内存页（所以根本不会出现内存溢出）。

真正重要的是 RES 这个指标（当然 RES 也会包含实际访问过的共享内存页的空间）。另一个值得参考的指标是 pmap -d 命令输出中的
writeable/private 这个指标。另外，你也可以使用 lj-gc 命令实时获取指定的 nginx worker（或者
luajit）进程中 LuaJIT VM 的 GC 实际分配了的空间大小：

    https://github.com/openresty/stapxx#lj-gc

Regards,
-agentzh

guoyang3

谢谢大家回答，还有个奇怪问题,我用top命令看nginx里的占用最大进程的res为121m，但是用pmap -d的 writeable/private为writeable/private: 437304K，这个是什么情况比top的还大，我到底相信哪个？
详细的：

16116:   nginx: worker process
Address           Kbytes Mode  Offset           Device    Mapping
0000000000400000     976 r-x-- 0000000000000000 0fd:00000 nginx
00000000006f4000      92 rw--- 00000000000f4000 0fd:00000 nginx
000000000070b000      68 rw--- 0000000000000000 000:00000   [ anon ]
0000000000810000     668 rw--- 0000000000000000 000:00000   [ anon ]
00000000008b7000  379392 rw--- 0000000000000000 000:00000   [ anon ]
0000000040077000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000400f5000     384 rw--- 0000000000000000 000:00000   [ anon ]
000000004016d000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000401c8000     256 rw--- 0000000000000000 000:00000   [ anon ]
000000004020e000     384 rw--- 0000000000000000 000:00000   [ anon ]
000000004026e000     256 rw--- 0000000000000000 000:00000   [ anon ]
00000000402f0000     128 rw--- 0000000000000000 000:00000   [ anon ]
000000004031a000     256 rw--- 0000000000000000 000:00000   [ anon ]
000000004036d000     256 rw--- 0000000000000000 000:00000   [ anon ]
0000000040448000     384 rw--- 0000000000000000 000:00000   [ anon ]
00000000404bb000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000404f9000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000040551000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000405f1000     128 rw--- 0000000000000000 000:00000   [ anon ]
000000004087d000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000408fb000     512 rw--- 0000000000000000 000:00000   [ anon ]
00000000409a6000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000409ea000     512 rw--- 0000000000000000 000:00000   [ anon ]
0000000040bd7000     256 rw--- 0000000000000000 000:00000   [ anon ]
0000000040c83000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000040d57000     512 rw--- 0000000000000000 000:00000   [ anon ]
0000000040e49000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000040e7b000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000040f3e000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000040f98000     256 rw--- 0000000000000000 000:00000   [ anon ]
0000000041060000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000410d7000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041198000     384 rw--- 0000000000000000 000:00000   [ anon ]
0000000041236000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041296000     256 rw--- 0000000000000000 000:00000   [ anon ]
0000000041397000     128 rw--- 0000000000000000 000:00000   [ anon ]
000000004144d000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000414ed000     640 rw--- 0000000000000000 000:00000   [ anon ]
00000000415c2000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000416b5000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041700000     128 rw--- 0000000000000000 000:00000   [ anon ]
00000000417c0000     388 rw--- 0000000000000000 000:00000   [ anon ]
000000004198d000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041a4e000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041a70000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041b3f000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041b7e000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041c4c000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041c9b000     256 rw--- 0000000000000000 000:00000   [ anon ]
0000000041cdb000     256 rw--- 0000000000000000 000:00000   [ anon ]
0000000041d48000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041dc9000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041f74000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000000041fcf000     128 rw--- 0000000000000000 000:00000   [ anon ]
0000003279000000     128 r-x-- 0000000000000000 0fd:00000 ld-2.12.so
000000327921f000       4 r---- 000000000001f000 0fd:00000 ld-2.12.so
0000003279220000       4 rw--- 0000000000020000 0fd:00000 ld-2.12.so
0000003279221000       4 rw--- 0000000000000000 000:00000   [ anon ]
0000003279400000     176 r-x-- 0000000000000000 0fd:00000 libpcre.so.0.0.1
000000327942c000    2044 ----- 000000000002c000 0fd:00000 libpcre.so.0.0.1
000000327962b000       4 rw--- 000000000002b000 0fd:00000 libpcre.so.0.0.1
0000003279800000    1572 r-x-- 0000000000000000 0fd:00000 libc-2.12.so
0000003279989000    2044 ----- 0000000000189000 0fd:00000 libc-2.12.so
0000003279b88000      16 r---- 0000000000188000 0fd:00000 libc-2.12.so
0000003279b8c000       4 rw--- 000000000018c000 0fd:00000 libc-2.12.so
0000003279b8d000      20 rw--- 0000000000000000 000:00000   [ anon ]
0000003279c00000      92 r-x-- 0000000000000000 0fd:00000 libpthread-2.12.so
0000003279c17000    2048 ----- 0000000000017000 0fd:00000 libpthread-2.12.so
0000003279e17000       4 r---- 0000000000017000 0fd:00000 libpthread-2.12.so
0000003279e18000       4 rw--- 0000000000018000 0fd:00000 libpthread-2.12.so
0000003279e19000      16 rw--- 0000000000000000 000:00000   [ anon ]
000000327a000000     524 r-x-- 0000000000000000 0fd:00000 libm-2.12.so
000000327a083000    2044 ----- 0000000000083000 0fd:00000 libm-2.12.so
000000327a282000       4 r---- 0000000000082000 0fd:00000 libm-2.12.so
000000327a283000       4 rw--- 0000000000083000 0fd:00000 libm-2.12.so
000000327a800000      84 r-x-- 0000000000000000 0fd:00000 libz.so.1.2.3
000000327a815000    2044 ----- 0000000000015000 0fd:00000 libz.so.1.2.3
000000327aa14000       4 r---- 0000000000014000 0fd:00000 libz.so.1.2.3
000000327aa15000       4 rw--- 0000000000015000 0fd:00000 libz.so.1.2.3
000000327b000000     116 r-x-- 0000000000000000 0fd:00000 libselinux.so.1
000000327b01d000    2044 ----- 000000000001d000 0fd:00000 libselinux.so.1
000000327b21c000       4 r---- 000000000001c000 0fd:00000 libselinux.so.1
000000327b21d000       4 rw--- 000000000001d000 0fd:00000 libselinux.so.1
000000327b21e000       4 rw--- 0000000000000000 000:00000   [ anon ]
000000327b400000      88 r-x-- 0000000000000000 0fd:00000 libresolv-2.12.so
000000327b416000    2048 ----- 0000000000016000 0fd:00000 libresolv-2.12.so
000000327b616000       4 r---- 0000000000016000 0fd:00000 libresolv-2.12.so
000000327b617000       4 rw--- 0000000000017000 0fd:00000 libresolv-2.12.so
000000327b618000       8 rw--- 0000000000000000 000:00000   [ anon ]
000000327b800000      88 r-x-- 0000000000000000 0fd:00000 libgcc_s-4.4.6-20120305.so.1
000000327b816000    2044 ----- 0000000000016000 0fd:00000 libgcc_s-4.4.6-20120305.so.1
000000327ba15000       4 rw--- 0000000000015000 0fd:00000 libgcc_s-4.4.6-20120305.so.1
000000327d000000      12 r-x-- 0000000000000000 0fd:00000 libcom_err.so.2.1
000000327d003000    2044 ----- 0000000000003000 0fd:00000 libcom_err.so.2.1
000000327d202000       4 r---- 0000000000002000 0fd:00000 libcom_err.so.2.1
000000327d203000       4 rw--- 0000000000003000 0fd:00000 libcom_err.so.2.1
000000327d800000      28 r-x-- 0000000000000000 0fd:00000 libcrypt-2.12.so
000000327d807000    2048 ----- 0000000000007000 0fd:00000 libcrypt-2.12.so
000000327da07000       4 r---- 0000000000007000 0fd:00000 libcrypt-2.12.so
000000327da08000       4 rw--- 0000000000008000 0fd:00000 libcrypt-2.12.so
000000327da09000     184 rw--- 0000000000000000 000:00000   [ anon ]
000000327dc00000      40 r-x-- 0000000000000000 0fd:00000 libkrb5support.so.0.1
000000327dc0a000    2044 ----- 000000000000a000 0fd:00000 libkrb5support.so.0.1
000000327de09000       4 r---- 0000000000009000 0fd:00000 libkrb5support.so.0.1
000000327de0a000       4 rw--- 000000000000a000 0fd:00000 libkrb5support.so.0.1
000000327e000000       8 r-x-- 0000000000000000 0fd:00000 libkeyutils.so.1.3
000000327e002000    2044 ----- 0000000000002000 0fd:00000 libkeyutils.so.1.3
000000327e201000       4 r---- 0000000000001000 0fd:00000 libkeyutils.so.1.3
000000327e202000       4 rw--- 0000000000002000 0fd:00000 libkeyutils.so.1.3
000000327e800000     252 r-x-- 0000000000000000 0fd:00000 libgssapi_krb5.so.2.2
000000327e83f000    2048 ----- 000000000003f000 0fd:00000 libgssapi_krb5.so.2.2
000000327ea3f000       4 r---- 000000000003f000 0fd:00000 libgssapi_krb5.so.2.2
000000327ea40000       8 rw--- 0000000000040000 0fd:00000 libgssapi_krb5.so.2.2
000000327ec00000     168 r-x-- 0000000000000000 0fd:00000 libk5crypto.so.3.1
000000327ec2a000    2044 ----- 000000000002a000 0fd:00000 libk5crypto.so.3.1
000000327ee29000       8 r---- 0000000000029000 0fd:00000 libk5crypto.so.3.1
000000327ee2b000       4 rw--- 000000000002b000 0fd:00000 libk5crypto.so.3.1
000000327f000000     372 r-x-- 0000000000000000 0fd:00000 libfreebl3.so
000000327f05d000    2044 ----- 000000000005d000 0fd:00000 libfreebl3.so
000000327f25c000       4 r---- 000000000005c000 0fd:00000 libfreebl3.so
000000327f25d000       4 rw--- 000000000005d000 0fd:00000 libfreebl3.so
000000327f25e000      16 rw--- 0000000000000000 000:00000   [ anon ]
000000327f400000     848 r-x-- 0000000000000000 0fd:00000 libkrb5.so.3.3
000000327f4d4000    2048 ----- 00000000000d4000 0fd:00000 libkrb5.so.3.3
000000327f6d4000      36 r---- 00000000000d4000 0fd:00000 libkrb5.so.3.3
000000327f6dd000       8 rw--- 00000000000dd000 0fd:00000 libkrb5.so.3.3
0000003309000000    1748 r-x-- 0000000000000000 0fd:00000 libcrypto.so.1.0.1e
00000033091b5000    2048 ----- 00000000001b5000 0fd:00000 libcrypto.so.1.0.1e
00000033093b5000     108 r---- 00000000001b5000 0fd:00000 libcrypto.so.1.0.1e
00000033093d0000      48 rw--- 00000000001d0000 0fd:00000 libcrypto.so.1.0.1e
00000033093dc000      16 rw--- 0000000000000000 000:00000   [ anon ]
0000003309400000     388 r-x-- 0000000000000000 0fd:00000 libssl.so.1.0.1e
0000003309461000    2048 ----- 0000000000061000 0fd:00000 libssl.so.1.0.1e
0000003309661000      16 r---- 0000000000061000 0fd:00000 libssl.so.1.0.1e
0000003309665000      28 rw--- 0000000000065000 0fd:00000 libssl.so.1.0.1e
00007fc5892f2000      20 r-x-- 0000000000000000 0fd:00000 libnss_dns-2.12.so
00007fc5892f7000    2044 ----- 0000000000005000 0fd:00000 libnss_dns-2.12.so
00007fc5894f6000       4 r---- 0000000000004000 0fd:00000 libnss_dns-2.12.so
00007fc5894f7000       4 rw--- 0000000000005000 0fd:00000 libnss_dns-2.12.so
00007fc5894f8000      12 r-x-- 0000000000000000 0fd:00000 core.so
00007fc5894fb000    2044 ----- 0000000000003000 0fd:00000 core.so
00007fc5896fa000       4 rw--- 0000000000002000 0fd:00000 core.so
00007fc5896fb000      44 r-x-- 0000000000000000 0fd:00000 core.so
00007fc589706000    2044 ----- 000000000000b000 0fd:00000 core.so
00007fc589905000       4 rw--- 000000000000a000 0fd:00000 core.so
00007fc589906000     192 r-x-- 0000000000000000 000:00000   [ anon ]
00007fc589936000     108 r-x-- 0000000000000000 0fd:00002 ziplib.so
00007fc589951000    2048 ----- 000000000001b000 0fd:00002 ziplib.so
00007fc589b51000       4 rw--- 000000000001b000 0fd:00002 ziplib.so
00007fc589b52000    3692 rw--- 0000000000000000 000:00000   [ anon ]
00007fc589eed000      64 r-x-- 0000000000000000 000:00000   [ anon ]
00007fc589efd000      28 r-x-- 0000000000000000 0fd:00000 cjson.so
00007fc589f04000    2044 ----- 0000000000007000 0fd:00000 cjson.so
00007fc58a103000       4 rw--- 0000000000006000 0fd:00000 cjson.so
00007fc58a104000       8 r-x-- 0000000000000000 0fd:00000 syslog.so
00007fc58a106000    2044 ----- 0000000000002000 0fd:00000 syslog.so
00007fc58a305000       4 rw--- 0000000000001000 0fd:00000 syslog.so
00007fc58a306000     220 r-x-- 0000000000000000 0fd:00000 libGeoIP.so.1.4.8
00007fc58a33d000    2044 ----- 0000000000037000 0fd:00000 libGeoIP.so.1.4.8
00007fc58a53c000       8 rw--- 0000000000036000 0fd:00000 libGeoIP.so.1.4.8
00007fc58a53e000       8 r-x-- 0000000000000000 0fd:00000 libletvip.so.1.1
00007fc58a540000    2044 ----- 0000000000002000 0fd:00000 libletvip.so.1.1
00007fc58a73f000       4 rw--- 0000000000001000 0fd:00000 libletvip.so.1.1
00007fc58a740000   42412 rw--- 0000000000000000 000:00000   [ anon ]
00007fc58d0ab000       4 rw-s- 0000000000000000 000:00004 zero (deleted)
00007fc58d0ac000  102400 rw-s- 0000000000000000 000:00004 zero (deleted)
00007fc5934ac000    1024 rw-s- 0000000000000000 000:00004 zero (deleted)
00007fc5935ac000   51200 rw-s- 0000000000000000 000:00004 zero (deleted)
00007fc5967ac000   51200 rw-s- 0000000000000000 000:00004 zero (deleted)
00007fc5999ac000      48 r-x-- 0000000000000000 0fd:00000 libnss_files-2.12.so
00007fc5999b8000    2048 ----- 000000000000c000 0fd:00000 libnss_files-2.12.so
00007fc599bb8000       4 r---- 000000000000c000 0fd:00000 libnss_files-2.12.so
00007fc599bb9000       4 rw--- 000000000000d000 0fd:00000 libnss_files-2.12.so
00007fc599bba000      32 rw--- 0000000000000000 000:00000   [ anon ]
00007fc599bc2000       8 r-x-- 0000000000000000 0fd:00000 libdl-2.12.so
00007fc599bc4000    2048 ----- 0000000000002000 0fd:00000 libdl-2.12.so
00007fc599dc4000       4 r---- 0000000000002000 0fd:00000 libdl-2.12.so
00007fc599dc5000       4 rw--- 0000000000003000 0fd:00000 libdl-2.12.so
00007fc599dc6000       8 rw--- 0000000000000000 000:00000   [ anon ]
00007fc599dc8000     456 r-x-- 0000000000000000 0fd:00000 libluajit-5.1.so.2.1.0
00007fc599e3a000    2044 ----- 0000000000072000 0fd:00000 libluajit-5.1.so.2.1.0
00007fc59a039000      12 rw--- 0000000000071000 0fd:00000 libluajit-5.1.so.2.1.0
00007fc59a03c000       4 rw--- 0000000000000000 000:00000   [ anon ]
00007fc59a04c000       4 rw--- 0000000000000000 000:00000   [ anon ]
00007fff3048c000      84 rw--- 0000000000000000 000:00000   [ stack ]
00007fff305ff000       4 r-x-- 0000000000000000 000:00000   [ anon ]
ffffffffff600000       4 r-x-- 0000000000000000 000:00000   [ anon ]
mapped: 711624K    writeable/private: 437304K    shared: 205828K

-----邮件原件-----
发件人: openresty@googlegroups.com [mailto:openresty@googlegroups.com] 代表 Yichun Zhang (agentzh)
发送时间: 2014年8月5日 2:43
收件人: openresty
主题: Re: 答复: [openresty] nginx+lua报错libluajit-5.1.so.2.0.0

Hello!

2014-08-03 20:03 GMT-07:00 郭阳3:
> 感谢春哥，已经换了nginx version: openresty/1.5.12.1 这个版本，目前正常提供服务运行了5天，不像以前直接上线不到半个小时就会内存溢出nginx work进程内存狂涨。
> 可是现在还有个现象，top命令查看，nignx的work进程的virt 在小幅度的增长，5天内已经由不到300多m涨到了500多m，而且不会降下来，但是res最大才140多m，而且会降下来。
> 不知道这种现象是否正常，真怕运行时间长了virt一直涨，会出现内存溢出现象。

VIRT 这个指标没有太大的意义，因为只是进程预留的虚拟内存地址空间。所以有时即使达到几 GB 甚至几 TB
也不一定会实际映射到物理内存页（所以根本不会出现内存溢出）。

真正重要的是 RES 这个指标（当然 RES 也会包含实际访问过的共享内存页的空间）。另一个值得参考的指标是 pmap -d 命令输出中的
writeable/private 这个指标。另外，你也可以使用 lj-gc 命令实时获取指定的 nginx worker（或者
luajit）进程中 LuaJIT VM 的 GC 实际分配了的空间大小：

    https://github.com/openresty/stapxx#lj-gc

Regards,
-agentzh

--