回复: 回复: Re: [openresty] 回复: 回复: 使用lua-resty-lock导致nginx core掉

coderesty · 2014-03-19T15:19:44+00:00

我使用的是ngx_openresty-1.4.3.6.tar.gz , 这个稳定版本, gdb的bt&#x7...

回复: 回复: Re: [openresty] 回复: 回复: 使用lua-resty-lock导致nginx core掉

coderesty

我下载最新的ngx_openresty-1.5.8.1.tar.gz , 发现lua_code_cache off;之后, 不core掉, 但是锁不起作用, 并没有锁住, 第一次请求锁住, 没有解锁, 第二次请求依然能够锁住.

发现lua-resty-lock和lua_code_cache的打开与关闭的关系很大.

2014-03-19

coderesty

发件人："coderesty"<code...@gmail.com>

发送时间：2014-03-19 13:00

主题：回复: Re: [openresty] 回复: 回复: 使用lua-resty-lock导致nginx core掉

收件人："openresty"<openresty@googlegroups.com>

抄送：

我使用的是ngx_openresty-1.4.3.6.tar.gz , 这个稳定版本, gdb的bt结果为:

2014-03-19

coderesty

发件人："Yichun Zhang (agentzh)" <age...@gmail.com>

发送时间：2014-03-19 04:37

主题：Re: [openresty] 回复: 回复: 食用lua-resty-lock导致nginx core掉

收件人："openresty"<openresty@googlegroups.com>

抄送：

Hello!

2014-03-18 6:21 GMT-07:00 coderesty:

> 我自己找到原因啦, 把lua_code_cache on;就不core啦, 把lua_code_cache关啦, 请求一次正常,

> 然后在请求就core掉.

> 但我不知道是什么原因导致的, 请问是为什么呀??

我使用你提供的代码片段加上 lua_code_cache off，即使通过 ab -c2 施加 2

并发的压力，也无法复现任何崩溃。Valgrind memcheck 也没有捕捉到任何内存问题。我使用的是最新的 ngx_lua 和

LuaJIT.

有如下几个建议：

1. 请提供你使用的 ngx_lua 模块和 LuaJIT 的版本（建议在报告问题时总是主动提供这些信息）。如果你使用的是

openresty 的话，请提供 openresty 的版本号。如果你目前使用的不是最新版本，请尝试最新的版本。

2. 请利用 gdb 这样的工具得到崩溃的具体信息，特别是 C 调用栈。具体细节请参见文档

http://wiki.nginx.org/Debugging#Core_dump 如果没有这样的具体信息，我们是很难进行判断的。

Regards,

-agentzh

邮件来自列表“openresty”,专用于技术讨论!

订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com

发言: 请发邮件到 openresty@googlegroups.com

退订: 请发邮件至 openresty+unsubscribe@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

coderesty

另外我用的是—with-luaji，是不是luajit和lua-resty-lock不兼容呀，在lua_code_cache off；下

在 2014年3月19日，下午3:18，coderesty <code...@gmail.com> 写道：

我下载最新的ngx_openresty-1.5.8.1.tar.gz  , 发现lua_code_cache off;之后, 不core掉, 但是锁不起作用, 并没有锁住, 第一次请求锁住, 没有解锁, 第二次请求依然能够锁住.

发现lua-resty-lock和lua_code_cache的打开与关闭的关系很大.

2014-03-19

coderesty

发件人："coderesty"<code...@gmail.com>

发送时间：2014-03-19 13:00

主题：回复: Re: [openresty] 回复: 回复: 使用lua-resty-lock导致nginx core掉

收件人："openresty"<openresty@googlegroups.com>

抄送：

我使用的是ngx_openresty-1.4.3.6.tar.gz  , 这个稳定版本, gdb的bt结果为:

<{4CA1FE73-3E6C-43B8-AB37-5D89AA6E5C0B}.bmp>

2014-03-19

coderesty

发件人："Yichun Zhang (agentzh)" <age...@gmail.com>

发送时间：2014-03-19 04:37

主题：Re: [openresty] 回复: 回复: 食用lua-resty-lock导致nginx core掉

收件人："openresty"<openresty@googlegroups.com>

抄送：

Hello!

2014-03-18 6:21 GMT-07:00 coderesty:

> 我自己找到原因啦, 把lua_code_cache on;就不core啦, 把lua_code_cache关啦, 请求一次正常,

> 然后在请求就core掉.

> 但我不知道是什么原因导致的, 请问是为什么呀??

>

我使用你提供的代码片段加上 lua_code_cache off，即使通过 ab -c2 施加 2

并发的压力，也无法复现任何崩溃。Valgrind memcheck 也没有捕捉到任何内存问题。我使用的是最新的 ngx_lua 和

LuaJIT.

有如下几个建议：

1. 请提供你使用的 ngx_lua 模块和 LuaJIT 的版本（建议在报告问题时总是主动提供这些信息）。如果你使用的是

openresty 的话，请提供 openresty 的版本号。如果你目前使用的不是最新版本，请尝试最新的版本。

2. 请利用 gdb 这样的工具得到崩溃的具体信息，特别是 C 调用栈。具体细节请参见文档

http://wiki.nginx.org/Debugging#Core_dump 如果没有这样的具体信息，我们是很难进行判断的。

Regards,

-agentzh

--

--

agentzh

Hello!

2014-03-19 0:18 GMT-07:00 coderesty:
>
> 我下载最新的ngx_openresty-1.5.8.1.tar.gz  , 发现lua_code_cache off;之后, 不core掉,

老版本的 ngx_lua 的 lua_cache_cache off 在和使用了 FFI 的 Lua module（比如
lua-resty-core）一起使用时确实会崩溃。

新版本的 ngx_lua 在 lua_code_cache off 模式下使用了每个请求一个 Lua VM 实例的做法，所以不会再有崩溃的问题。

值得提醒的是，lua_code_cache off 只应在简单的开发过程中使用，因为性能开销巨大，而且因为每请求一个 Lua VM
实例，所以请求之间是无法通过 Lua VM 来保持状态的。

> 但是锁不起作用, 并没有锁住,
> 第一次请求锁住, 没有解锁, 第二次请求依然能够锁住.
> 发现lua-resty-lock和lua_code_cache的打开与关闭的关系很大.
>

我使用 lua_code_cache off 运行了 lua-resty-lock 的整个测试集，所有测试用例都通过了。由于
lua-resty-lock 使用共享内存来保持锁的状态，所以 lua_code_cache off 不应对该库的功能产生影响。

请提供一个完整的最小化的独立用例，以及复现问题所需的详细的步骤。尽量去除无关的外部依赖和细节，以便我可以在我本地复现你看到的问题。

另外，值得一提的是，最新的 openresty 是 1.5.11.1rc2:

    http://openresty.org/download/ngx_openresty-1.5.11.1rc2.tar.gz

> 另外我用的是—with-luaji， 是不是luajit和lua-resty-lock不兼容呀
>

作为 lua-resty-lock 的作者，我要告诉你的是，lua-resty-lock 只支持 LuaJIT. 这在文档中有明确说明：

    https://github.com/agentzh/lua-resty-lock#prerequisites

Regards,
-agentzh

coderesty

我的例子是这样的, 原理上应该第一次请求获取锁, 然后第二次请求就不能获取锁, 然后超时返回, 但是第二次依然能够获取锁.

并且使用ngx_openresty-1.4.3.6.tar.gz , 这个版本, 第二次请求会导致nginx的work进程core掉.

2014-03-20

coderesty

发件人："Yichun Zhang (agentzh)" <age...@gmail.com>

发送时间：2014-03-20 03:26

主题：Re: 回复: Re: [openresty] 回复: 回复: 使用lua-resty-lock导致nginx core掉

收件人："openresty"<openresty@googlegroups.com>

抄送：

Hello!

2014-03-19 0:18 GMT-07:00 coderesty:

> 我下载最新的ngx_openresty-1.5.8.1.tar.gz , 发现lua_code_cache off;之后, 不core掉,

老版本的 ngx_lua 的 lua_cache_cache off 在和使用了 FFI 的 Lua module（比如

lua-resty-core）一起使用时确实会崩溃。

新版本的 ngx_lua 在 lua_code_cache off 模式下使用了每个请求一个 Lua VM 实例的做法，所以不会再有崩溃的问题。

值得提醒的是，lua_code_cache off 只应在简单的开发过程中使用，因为性能开销巨大，而且因为每请求一个 Lua VM

实例，所以请求之间是无法通过 Lua VM 来保持状态的。

> 但是锁不起作用, 并没有锁住,

> 第一次请求锁住, 没有解锁, 第二次请求依然能够锁住.

> 发现lua-resty-lock和lua_code_cache的打开与关闭的关系很大.

我使用 lua_code_cache off 运行了 lua-resty-lock 的整个测试集，所有测试用例都通过了。由于

lua-resty-lock 使用共享内存来保持锁的状态，所以 lua_code_cache off 不应对该库的功能产生影响。

请提供一个完整的最小化的独立用例，以及复现问题所需的详细的步骤。尽量去除无关的外部依赖和细节，以便我可以在我本地复现你看到的问题。

另外，值得一提的是，最新的 openresty 是 1.5.11.1rc2:

http://openresty.org/download/ngx_openresty-1.5.11.1rc2.tar.gz

> 另外我用的是—with-luaji，是不是luajit和lua-resty-lock不兼容呀

作为 lua-resty-lock 的作者，我要告诉你的是，lua-resty-lock 只支持 LuaJIT. 这在文档中有明确说明：

https://github.com/agentzh/lua-resty-lock#prerequisites

Regards,

-agentzh

邮件来自列表“openresty”,专用于技术讨论!

订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com

发言: 请发邮件到 openresty@googlegroups.com

退订: 请发邮件至 openresty+unsubscribe@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-03-19 23:43 GMT-07:00 coderesty:
>
> 我的例子是这样的,

请下一次提供代码示例时，不要提供图片；因为你这样让我无法直接复制和粘贴你的代码和配置。

>  原理上应该第一次请求获取锁, 然后第二次请求就不能获取锁, 然后超时返回, 但是第二次依然能够获取锁.
>

你这个例子本身是有问题的，你看到的现象是我期望中的结果。

具体来说，这是因为 resty.lock 对象被垃圾回收（GC）时会自动释放它拿着的锁。所以你的第一个请求结束后，锁就被立即释放了。

之所以在 lua_cache_lock off 时更容易被触发，是因为在此模式下，当前请求对应的 Lua VM
实例会在请求结束时立即销毁，所以请求里的 resty.lock 这个 Lua 对象也会在请求结束时立即被 GC.

你在测试时应该确保你的锁被持有足够长的时间，比如可以这样写：

    local lock, err = lock:lock("my_key")
    -- error handling goes here...omitted
    ngx.sleep(30)   -- sleeping for 30 seconds to ensure the lock is held.
    lock:unlock()

这样在请一个请求还在执行时，你再同时发起第二个请求。此时第二个请求应该会等待第一个请求结束并释放锁。

尽量自己主动释放锁，而不要依赖于 GC. 毕竟 GC 回收一般会有一定的延迟。

> 并且使用ngx_openresty-1.4.3.6.tar.gz  , 这个版本, 第二次请求会导致nginx的work进程core掉.
>

我已经告诉过你，老版本的 ngx_lua 在 lua_code_cache off 时和 lua-resty-lock 这样使用了 FFI
的 Lua 库一起工作时会导致崩溃问题。你这里的老版本的 openresty 包含的就是这样的老版本的 ngx_lua.
我已经建议你使用最新版本的 ngx_openresty 1.5.11.1rc2 了。你为何不仔细阅读我先前的回复呢？

Regards,
-agentzh