关于ngx.shared.DICT.flush_all的问题

hi.laowang · 2013-07-17T11:39:58+00:00

Hello! 2013/7/16 杨进: > 是这样的，在配置nginx泛域名的时&...

关于ngx.shared.DICT.flush_all的问题

hi.laowang

我使用nginx共享内存来保存一些东西：

local ok = shared:safe_set(key, value, timeout)

发现大量错误：

2013/07/17 11:34:34 [crit] 10158#0: ngx_slab_alloc() failed: no memory in lua_shared_dict zone "packages"

2013/07/17 11:34:34 [crit] 10160#0: ngx_slab_alloc() failed: no memory in lua_shared_dict zone "packages"

然后我改了一下代码：

local ok = shared:safe_set(key, value, timeout)

if not ok then

shared:flush_all()

end

重启nginx后，用不了多久又会一片一片的报错，看上去好像flush_all没生效似的。

请明白人答疑解惑

agentzh

Hello!

2013/7/16 王博:
> 我使用nginx共享内存来保存一些东西：
>
> local ok = shared:safe_set(key, value, timeout)
>
> 发现大量错误：
>
> 2013/07/17 11:34:34 [crit] 10158#0: ngx_slab_alloc() failed: no memory in
> lua_shared_dict zone "packages"

这个错误消息是无害的，在 openresty 软件包中包含的 nginx 核心中，我已经把这个错误消息改成了 info 级别的了，见下面的补丁：

  https://github.com/agentzh/ngx_openresty/blob/master/patches/nginx-1.4.1-slab_alloc_no_memory_as_info.patch

> 然后我改了一下代码：
>
> local ok = shared:safe_set(key, value, timeout)
> if not ok then
>     shared:flush_all()
> end
>
> 重启nginx后，用不了多久又会一片一片的报错，看上去好像flush_all没生效似的。
>

flush_all 方法并不会实际释放共享内存的空间，它只是把所有的元素标记为过期而已。如果你希望实际释放空间，可以再紧接着调用
flush_expired 方法，这个方法会实际释放过期了的元素：

    http://wiki.nginx.org/HttpLuaModule#ngx.shared.DICT.flush_expired

Regards,
-agentzh

agentzh

Hello!

2013/7/16 王博:
> 然后我改了一下代码：
>
> local ok = shared:safe_set(key, value, timeout)
> if not ok then
>     shared:flush_all()
> end
>

另外，值得一提的是，从你这里的 Lua 代码的用法看，似乎你应当直接使用 set 方法，而不是 safe_set. 请确认 safe_set
确实是你所需要的。如果你仅是将这个字典用作 LRU cache 的话，应当使用 set，而不是 safe_set.
只有当你把字典当作数据存储，并且不希望有数据丢失时，才应使用
safe_set，但在这种情况下，应当确保你分配的字典的容量足够放下你所有的数据，即不应让 safe_set 调用失败。

Regards,
-agentzh

hi.laowang

怪我没有仔细看文档，现在OK了，谢谢春哥！

另：我有一个建议，ngx lua共享内存的使用，是否可以考虑加入一个无锁机制，因为在我的场景里，我可以容忍一定程度的数据不一致，如果可以抛弃spinlock，那么性能应该会提升更多。

On Wednesday, July 17, 2013 1:06:35 PM UTC+8, agentzh wrote:

Hello!

2013/7/16 王博:
> 然后我改了一下代码：
>
> local ok = shared:safe_set(key, value, timeout)
> if not ok then
> shared:flush_all()
> end
>

另外，值得一提的是，从你这里的 Lua 代码的用法看，似乎你应当直接使用 set 方法，而不是 safe_set. 请确认 safe_set
确实是你所需要的。如果你仅是将这个字典用作 LRU cache 的话，应当使用 set，而不是 safe_set.
只有当你把字典当作数据存储，并且不希望有数据丢失时，才应使用
safe_set，但在这种情况下，应当确保你分配的字典的容量足够放下你所有的数据，即不应让 safe_set 调用失败。

Regards,
-agentzh

hi.laowang

好像还是有问题，目前代码如下：

local success, err, forcible = shared_package_versions:set(apkid, version_code, timeout)

if forcible then

shared_package_versions:flush_all()

shared_package_versions:flush_expired()

end

代码平稳运行了一段时间后，又开始大量报错，no memory

On Wednesday, July 17, 2013 2:06:48 PM UTC+8, 王博 wrote:

怪我没有仔细看文档，现在OK了，谢谢春哥！

另：我有一个建议，ngx lua共享内存的使用，是否可以考虑加入一个无锁机制，因为在我的场景里，我可以容忍一定程度的数据不一致，如果可以抛弃spinlock，那么性能应该会提升更多。

On Wednesday, July 17, 2013 1:06:35 PM UTC+8, agentzh wrote:
Hello!

2013/7/16 王博:
> 然后我改了一下代码：
>
> local ok = shared:safe_set(key, value, timeout)
> if not ok then
> shared:flush_all()
> end
>

另外，值得一提的是，从你这里的 Lua 代码的用法看，似乎你应当直接使用 set 方法，而不是 safe_set. 请确认 safe_set
确实是你所需要的。如果你仅是将这个字典用作 LRU cache 的话，应当使用 set，而不是 safe_set.
只有当你把字典当作数据存储，并且不希望有数据丢失时，才应使用
safe_set，但在这种情况下，应当确保你分配的字典的容量足够放下你所有的数据，即不应让 safe_set 调用失败。

Regards,
-agentzh

hi.laowang

重复了几次，感觉好像存在某种临界值，flush_all&flush_expired开始可以正常工作一定时间，等到达某个阈值之后，就没用了，系统开始大量报no memory

On Wednesday, July 17, 2013 2:10:43 PM UTC+8, 王博 wrote:

好像还是有问题，目前代码如下：

local success, err, forcible = shared_package_versions:set(apkid, version_code, timeout)
if forcible then
shared_package_versions:flush_all()
shared_package_versions:flush_expired()
end

代码平稳运行了一段时间后，又开始大量报错，no memory

On Wednesday, July 17, 2013 2:06:48 PM UTC+8, 王博 wrote:
怪我没有仔细看文档，现在OK了，谢谢春哥！

另：我有一个建议，ngx lua共享内存的使用，是否可以考虑加入一个无锁机制，因为在我的场景里，我可以容忍一定程度的数据不一致，如果可以抛弃spinlock，那么性能应该会提升更多。

On Wednesday, July 17, 2013 1:06:35 PM UTC+8, agentzh wrote:
Hello!

2013/7/16 王博:
> 然后我改了一下代码：
>
> local ok = shared:safe_set(key, value, timeout)
> if not ok then
> shared:flush_all()
> end
>

另外，值得一提的是，从你这里的 Lua 代码的用法看，似乎你应当直接使用 set 方法，而不是 safe_set. 请确认 safe_set
确实是你所需要的。如果你仅是将这个字典用作 LRU cache 的话，应当使用 set，而不是 safe_set.
只有当你把字典当作数据存储，并且不希望有数据丢失时，才应使用
safe_set，但在这种情况下，应当确保你分配的字典的容量足够放下你所有的数据，即不应让 safe_set 调用失败。

Regards,
-agentzh

agentzh

Hello!

2013/7/16 王博:
> 重复了几次，感觉好像存在某种临界值，flush_all&flush_expired开始可以正常工作一定时间，等到达某个阈值之后，就没用了，系统开始大量报no
> memory
>

貌似你并没有仔细阅读我的上一封邮件。在这里我再重复一遍：

“这个错误消息是无害的，在 openresty 软件包中包含的 nginx 核心中，我已经把这个错误消息改成了 info 级别的了，见下面的补丁：

  https://github.com/agentzh/ngx_openresty/blob/master/patches/nginx-1.4.1-slab_alloc_no_memory_as_info.patch
"

Regards,
-agentzh

agentzh

Hello!

2013/7/16 王博:
> 另：我有一个建议，ngx
> lua共享内存的使用，是否可以考虑加入一个无锁机制，因为在我的场景里，我可以容忍一定程度的数据不一致，如果可以抛弃spinlock，那么性能应该会提升更多。
>

如果简单粗暴地去掉锁，并不会仅仅造成数据的不一致，还可能会造成指针的非法访问而导致进程崩溃。

请使用 Nginx Systemtap Toolkit 里面的 ngx-sample-bt 和 ngx-sample-bt-off-cpu
这两个工具对你的最繁忙的 nginx worker 进程进行采样，分别绘制出 on-CPU 和 off-CPU
火焰图，以确认共享内存字典的锁是瓶颈：

  https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt
  https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt-off-cpu

如果锁真是瓶颈，可以考虑

1. 你自己对你的字典进行 sharding，分割成多个子字典，以降低锁的粒度；或者

2. 直接实现一个像样的使用 lock-free 算法的共享内存字典，用空间来换时间。

Regards,
-agentzh

hi.laowang

我要描述的是，当我设置了flush_all & flush_expired之后，用不了多久，错误信息仍然“源源不断”的出来，就好象flush没有效果一样，如果flush生效，那么应该出来几条错误信息，然后flush生效，安静一会，然后再出来几条，再flush，再安静一会，而我现在的情况是错误信息一直源源不断的出来

local success, err, forcible = shared_packages:set(apkid, value, timeout)

if not success then

shared_packages:flush_all()

shared_packages:flush_expired()

end

On Thursday, July 18, 2013 2:50:42 AM UTC+8, agentzh wrote:

Hello!

2013/7/16 王博:
> 重复了几次，感觉好像存在某种临界值，flush_all&flush_expired开始可以正常工作一定时间，等到达某个阈值之后，就没用了，系统开始大量报no
> memory
>

貌似你并没有仔细阅读我的上一封邮件。在这里我再重复一遍：

“这个错误消息是无害的，在 openresty 软件包中包含的 nginx 核心中，我已经把这个错误消息改成了 info 级别的了，见下面的补丁：

https://github.com/agentzh/ngx_openresty/blob/master/patches/nginx-1.4.1-slab_alloc_no_memory_as_info.patch
"

Regards,
-agentzh

agentzh

Hello!

2013/7/17 王博:
> 我要描述的是，当我设置了flush_all &
> flush_expired之后，用不了多久，错误信息仍然“源源不断”的出来，就好象flush没有效果一样，如果flush生效，那么应该出来几条错误信息，然后flush生效，安静一会，然后再出来几条，再flush，再安静一会，而我现在的情况是错误信息一直源源不断的出来
>
>             local success, err, forcible = shared_packages:set(apkid, value,
> timeout)
>             if not success then
>                 shared_packages:flush_all()
>                 shared_packages:flush_expired()
>             end
>

因为你这里使用了 set 方法，所以当存储满了时候，即有“no memory”错误时，set
方法会自动强制删除若干未过期的元素以腾出一些空间。当它能腾出足够空间时，success 返回值便仍然为真，也就是说大部分时候，你的
flush_all 和 flush_expired 其实并没有被调用。你可以在你的 flush_all()
调用前添加一条日志消息，以确认你的 if 条件确实按你所期望的频度被满足。正因为 set
方法在存储满了的时候只是删除若干元素腾一些空间，所以很快存储又会用尽，你又会得到那个 alert 消息。这也是为什么我说这个 no
memory 错误是无害的。你只应当检查 Lua 函数的返回值以确认是否真的有问题。

Regards,
-agentzh

hi.laowang

我测试了set，safe_set等方法，都是一样的

local ok = shared_packages:safe_set(apkid, value, timeout)

if not ok then

print("xxxxxxxxxx")

shared_packages:flush_all()

shared_packages:flush_expired()

end

内存分配足够大，但错误信息xxxxxxxxxxx源源不断，所以推断flush未生效

On Thursday, July 18, 2013 10:08:02 AM UTC+8, agentzh wrote:

Hello!

2013/7/17 王博:
> 我要描述的是，当我设置了flush_all &
> flush_expired之后，用不了多久，错误信息仍然“源源不断”的出来，就好象flush没有效果一样，如果flush生效，那么应该出来几条错误信息，然后flush生效，安静一会，然后再出来几条，再flush，再安静一会，而我现在的情况是错误信息一直源源不断的出来
>
> local success, err, forcible = shared_packages:set(apkid, value,
> timeout)
> if not success then
> shared_packages:flush_all()
> shared_packages:flush_expired()
> end
>

因为你这里使用了 set 方法，所以当存储满了时候，即有“no memory”错误时，set
方法会自动强制删除若干未过期的元素以腾出一些空间。当它能腾出足够空间时，success 返回值便仍然为真，也就是说大部分时候，你的
flush_all 和 flush_expired 其实并没有被调用。你可以在你的 flush_all()
调用前添加一条日志消息，以确认你的 if 条件确实按你所期望的频度被满足。正因为 set
方法在存储满了的时候只是删除若干元素腾一些空间，所以很快存储又会用尽，你又会得到那个 alert 消息。这也是为什么我说这个 no
memory 错误是无害的。你只应当检查 Lua 函数的返回值以确认是否真的有问题。

Regards,
-agentzh

hi.laowang

内存分配空间足够大，不会发生flush后又立刻被占满的情况

On Thursday, July 18, 2013 10:49:30 AM UTC+8, 王博 wrote:

我测试了set，safe_set等方法，都是一样的

local ok = shared_packages:safe_set(apkid, value, timeout)
if not ok then
print("xxxxxxxxxx")
shared_packages:flush_all()
shared_packages:flush_expired()
end

内存分配足够大，但错误信息xxxxxxxxxxx源源不断，所以推断flush未生效

On Thursday, July 18, 2013 10:08:02 AM UTC+8, agentzh wrote:
Hello!

2013/7/17 王博:
> 我要描述的是，当我设置了flush_all &
> flush_expired之后，用不了多久，错误信息仍然“源源不断”的出来，就好象flush没有效果一样，如果flush生效，那么应该出来几条错误信息，然后flush生效，安静一会，然后再出来几条，再flush，再安静一会，而我现在的情况是错误信息一直源源不断的出来
>
> local success, err, forcible = shared_packages:set(apkid, value,
> timeout)
> if not success then
> shared_packages:flush_all()
> shared_packages:flush_expired()
> end
>

因为你这里使用了 set 方法，所以当存储满了时候，即有“no memory”错误时，set
方法会自动强制删除若干未过期的元素以腾出一些空间。当它能腾出足够空间时，success 返回值便仍然为真，也就是说大部分时候，你的
flush_all 和 flush_expired 其实并没有被调用。你可以在你的 flush_all()
调用前添加一条日志消息，以确认你的 if 条件确实按你所期望的频度被满足。正因为 set
方法在存储满了的时候只是删除若干元素腾一些空间，所以很快存储又会用尽，你又会得到那个 alert 消息。这也是为什么我说这个 no
memory 错误是无害的。你只应当检查 Lua 函数的返回值以确认是否真的有问题。

Regards,
-agentzh

agentzh

Hello!

2013/7/17 王博:
> 我测试了set，safe_set等方法，都是一样的
>
[...]
> 内存分配足够大，但错误信息xxxxxxxxxxx源源不断，所以推断flush未生效
>

请提供一个最小化的能复现该问题的完整示例。谢谢合作 :)

Best regards,
-agentzh

agentzh

Hello!

2013/7/17 Yichun Zhang (agentzh):
> 2013/7/17 王博:
>> 我测试了set，safe_set等方法，都是一样的
>>
> [...]
>> 内存分配足够大，但错误信息xxxxxxxxxxx源源不断，所以推断flush未生效
>>
>
> 请提供一个最小化的能复现该问题的完整示例。谢谢合作 :)
>

我刚在我本地尝试了下面这个很简单的例子来验证这里的行为：

    location = /t {
        content_by_lua '
            local dogs = ngx.shared.dogs
            local i = 0
            while true do
                local ok, err = dogs:safe_set("key-" .. i, i)
                if not ok then
                    ngx.say("aborted: ", err)
                    break
                end
                i = i + 1
            end
            ngx.say("inserted ", i, " keys.")

            dogs:flush_all()
            local count = dogs:flush_expired()
            ngx.say(count, " items freed.")

            i = 0
            while true do
                local ok, err = dogs:safe_set("key+" .. i, i)
                if not ok then
                    ngx.say("aborted: ", err)
                    break
                end
                i = i + 1
            end
            ngx.say("inserted ", i, " keys.")
        ';
    }

使用新发布的 ngx_openresty 1.4.1.1 运行这个示例，在我本地请求 /t 接口得到下面的输出：

    aborted: no memory
    inserted 735 keys.
    732 items freed.
    aborted: no memory
    inserted 735 keys.

我们看到第一轮使用 safe_set 一直插入到得到“no memory”错误，一共可以插入 735 个不同的键值对。然后使用
flush_all 和 flush_expired 清空所有空间，然后再进行第二轮的 safe_set 插入，同时一直插入到得到“no
memory”错误，可以看到，仍然可以插入 735 个 key. 请注意前后两轮 safe_set 插入的 key
都是不同的，所以可以绕过在 key 相同时，复用元素空间的优化。

这里可能唯一会让人有疑问的是 flush_expired 的返回值是 732 而不是 735. 其实原因很简单，因为 flush_all
在把所有元素标记为过期之后还会顺带着删除 LRU 队列中最久没使用过的最多 3 个元素，于是等到 flush_expired
释放空间时，便少了 3 个。

同时，我们可以对 nginx 错误日志中的那个“ngx_slab_alloc() failed: no memory”错误消息进行统计：

    $ grep 'no memory' t/servroot/logs/error.log
    2013/07/18 21:23:33 [info] 4013#0: ngx_slab_alloc() failed: no
memory in lua_shared_dict zone "dogs"
    2013/07/18 21:23:33 [info] 4013#0: ngx_slab_alloc() failed: no
memory in lua_shared_dict zone "dogs"

我们看到确实只有两条消息，即两轮 safe_set 插入的终止条件。注意，这里的错误日志消息是 info 级别，而不是
alert，因为我之前说了，ngx_openresty 中包含的 nginx 核心已经把这条无害的错误信息从 alert 级别修改为了
info 级别。

如我先前所说，如果你仍然认为这里有 bug，请提供一个最小化的完整示例，以及复现问题所需的相关步骤。

Best regards,
-agentzh