请教systemtap出错原因

lancelijade

agentzh,

我在检查一个共享内存问题时运行 ngx-shm 提示下面的问题，请问可能是什么原因？列表时报几个shdict坏了，读其中一个好的的时候继续失败。操作系统版本和软件版本在最下面。

[root@ptest nginx-systemtap-toolkit]# ./ngx-shm -p 345
Tracing 345 (/usr/local/openresty/nginx/sbin/nginx)...

WARNING: shm zone "xingxing" is corrupted or not yet loaded into the process memory space: pool != pool->addr (pool->addr: 0x0)
shm zone "xingxing"
    owner: ngx_http_lua_shdict
    total size: 6144000 KB

WARNING: shm zone "xingxing1G" is corrupted or not yet loaded into the process memory space: pool != pool->addr (pool->addr: 0x0)
shm zone "xingxing1G"
    owner: ngx_http_lua_shdict
    total size: 1024000 KB

shm zone "xx1"
    owner: ngx_http_lua_shdict
    total size: 1024000 KB

shm zone "xx2"
    owner: ngx_http_lua_shdict
    total size: 1024000 KB

shm zone "xx3"
    owner: ngx_http_lua_shdict
    total size: 1024000 KB

WARNING: shm zone "xx-test" is corrupted or not yet loaded into the process memory space: pool != pool->addr (pool->addr: 0x0)
shm zone "xx-test"
    owner: ngx_http_lua_shdict
    total size: 10240 KB

Use the -n <zone> option to see more details about each zone.
39 microseconds elapsed in the probe.
[root@ptest nginx-systemtap-toolkit]# ./ngx-shm -p 345 -n xx2
ERROR: read fault [man error::fault] at 0x00002aac9eb6b0e0 (addr) near operator '@cast' at <input>:76:26
Tracing 345 (/usr/local/openresty/nginx/sbin/nginx)...

shm zone "xx2"
    owner: ngx_http_lua_shdict
    total size: 1024000 KB
WARNING: Number of errors: 1, skipped probes: 0
WARNING: /opt/bin/staprun exited with status: 1
Pass 5: run failed. [man error::pass5]

[root@ptest nginx-systemtap-toolkit]# uname -a
Linux ptest 2.6.18-371.4.1.el5.centos.plus #1 SMP Thu Jan 30 06:16:27 EST 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@ptest nginx-systemtap-toolkit]# /usr/local/openresty/nginx/sbin/nginx -V
nginx version: openresty/1.5.8.1
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)
TLS SNI support disabled
configure arguments: --prefix=/usr/local/openresty/nginx --add-module=../ngx_devel_kit-0.2.19 --add-module=../echo-nginx-module-0.51 --add-module=../xss-nginx-module-0.04 --add-module=../ngx_coolkit-0.2rc1 --add-module=../set-misc-nginx-module-0.24 --add-module=../form-input-nginx-module-0.07 --add-module=../encrypted-session-nginx-module-0.03 --add-module=../srcache-nginx-module-0.25 --add-module=../ngx_lua-0.9.4 --add-module=../headers-more-nginx-module-0.25 --add-module=../array-var-nginx-module-0.03 --add-module=../memc-nginx-module-0.14 --add-module=../redis2-nginx-module-0.10 --add-module=../redis-nginx-module-0.3.7 --add-module=../auth-request-nginx-module-0.2 --add-module=../rds-json-nginx-module-0.13 --add-module=../rds-csv-nginx-module-0.05 --with-ld-opt=-Wl,-rpath,/usr/local/openresty/luajit/lib --with-pcre-jit --with-pcre-conf-opt=--enable-utf --with-pcre=/root/software/ngx_openresty-1.5.8.1/../pcre-8.34 --with-http_ssl_module

[root@ptest nginx-systemtap-toolkit]# /opt/bin/stap -v
A script must be specified.
Try '--help' for more information.
[root@passport94 nginx-systemtap-toolkit]# /opt/bin/stap -V
Systemtap translator/driver (version 2.3/0.156, non-git sources)
Copyright (C) 2005-2013 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: LIBRPM LIBSQLITE3 BOOST_SHARED_PTR TR1_UNORDERED_MAP NLS JAVA

谢谢

Lance

agentzh

Hello!

On Mon, Mar 17, 2014 at 3:05 AM, Lance wrote:
> 我在检查一个共享内存问题时运行 ngx-shm
> 提示下面的问题，请问可能是什么原因？列表时报几个shdict坏了，
[...]
> WARNING: shm zone "xingxing" is corrupted or not yet loaded into the process
> memory space: pool != pool->addr (pool->addr: 0x0)

这里的警告消息已经指出了问题所在，即这个 xingxing 域开头的内存页很可能尚未被这个 worker 进程加载进它的进程空间（即计入
RES 这一项内存使用指标）。

注意，即使对于共享内存里的内存页，各个进程里面的加载也是 lazy
的，只有当进程实际读取或者写入对应的内存页时，操作系统内核才会把对应的页实际加载进该进程的进程空间。

由于 systemtap 以安全模式工作在内核空间里，所以它并不能在读取尚未加载进对应的进程空间的内存页（因为它不能在目标进程内触发
page fault，那样可能会导致 segmentation fault，而让目标进程崩溃）。

绕过此问题的一种折衷的办法是在 init_worker_by_lua
里把各个共享内存字典自己访问一遍，这样其对应的内存页都会被实际加载进各个 worker 的进程空间。

Regards,
-agentzh

lancelijade

那第二段错误呢？即去读已经初始化成功的 xx2 报的错，我试过 xx1 xx3 ，它们肯定已经被填充过数据，实际试图分析的时候报这样的错

[root@ptest nginx-systemtap-toolkit]# ./ngx-shm -p 345 -n xx2
ERROR: read fault [man error::fault] at 0x00002aac9eb6b0e0 (addr) near operator '@cast' at <input>:76:26
Tracing 345 (/usr/local/openresty/nginx/

sbin/nginx)...

shm zone "xx2"
owner: ngx_http_lua_shdict
total size: 1024000 KB
WARNING: Number of errors: 1, skipped probes: 0
WARNING: /opt/bin/staprun exited with status: 1
Pass 5: run failed. [man error::pass5]

Lance

2014-03-18 3:44 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

On Mon, Mar 17, 2014 at 3:05 AM, Lance wrote:
> 我在检查一个共享内存问题时运行 ngx-shm
> 提示下面的问题，请问可能是什么原因？列表时报几个shdict坏了，

[...]

> WARNING: shm zone "xingxing" is corrupted or not yet loaded into the process
> memory space: pool != pool->addr (pool->addr: 0x0)

这里的警告消息已经指出了问题所在，即这个 xingxing 域开头的内存页很可能尚未被这个 worker 进程加载进它的进程空间（即计入
RES 这一项内存使用指标）。

注意，即使对于共享内存里的内存页，各个进程里面的加载也是 lazy
的，只有当进程实际读取或者写入对应的内存页时，操作系统内核才会把对应的页实际加载进该进程的进程空间。

由于 systemtap 以安全模式工作在内核空间里，所以它并不能在读取尚未加载进对应的进程空间的内存页（因为它不能在目标进程内触发
page fault，那样可能会导致 segmentation fault，而让目标进程崩溃）。

绕过此问题的一种折衷的办法是在 init_worker_by_lua
里把各个共享内存字典自己访问一遍，这样其对应的内存页都会被实际加载进各个 worker 的进程空间。

Regards,
-agentzh

--

agentzh

Hello!

2014-03-17 21:56 GMT-07:00 Lance:
> 那第二段错误呢？即去读已经初始化成功的 xx2 报的错，我试过 xx1 xx3 ，它们肯定已经被填充过数据，实际试图分析的时候报这样的错
>

被进程 A 填充过数据并不等于所有的内存页都已经加载进进程 B 的进程空间。

类似地，xx2 这个 shm 区域开头部分的内存页被加载进目标进程的进程空间，并不意味着该 shm
区域内的所有内存页都被加载过了。毕竟一个内存页一般只有 4k 字节。而 OS 是按页来加载的。

Regards,
-agentzh

lancelijade

这段话没看懂............... 我的意思是 xx1 xx2 xx3 都已经被填充过数据，当然不一定是 1G 都已经填满，但肯定有数据，可以正常 get 读到，这里碰到现在的报错，是我哪里打开方式不对？

Lance

2014-03-18 13:07 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2014-03-17 21:56 GMT-07:00 Lance:

> 那第二段错误呢？即去读已经初始化成功的 xx2 报的错，我试过 xx1 xx3 ，它们肯定已经被填充过数据，实际试图分析的时候报这样的错
>

被进程 A 填充过数据并不等于所有的内存页都已经加载进进程 B 的进程空间。

类似地，xx2 这个 shm 区域开头部分的内存页被加载进目标进程的进程空间，并不意味着该 shm
区域内的所有内存页都被加载过了。毕竟一个内存页一般只有 4k 字节。而 OS 是按页来加载的。

Regards,
-agentzh

--

agentzh

Hello!

2014-03-17 22:09 GMT-07:00 Lance:
> 这段话没看懂...............   我的意思是 xx1 xx2 xx3 都已经被填充过数据，当然不一定是 1G
> 都已经填满，但肯定有数据，可以正常 get 读到，这里碰到现在的报错，是我哪里打开方式不对？
>

这主要涉及进程的虚拟内存机制。

共享内存区域只是占据了各个进程的虚拟地址空间，而对应的虚拟内存页是按需加载的。xx1 里的数据如果是由进程 A 填充的，那么如果进程 B
从未遍历过这些数据，或者没有遍历全这些数据，那么会存在一些内存页尚未被实际加载进进程 B 中。这是 OS 的一项优化。

比如 xx1 里的数据是由 nginx master 进程填充的，而 fork 之后的所有 worker 进程默认并不会立即加载 xx1
里的任何虚拟内存页。只有当各个 worker 进程实际访问 xx1 里的某些数据时，对应的虚拟内存页才会被实际加载进对应的 worker
进程。

Regards,
-agentzh

lancelijade

那这样的设计会导致在某些worker中读不到shdict的数据吗？假如真是这样是不是就与shdict的设计不符了呢？

Lance

2014-03-18 13:18 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2014-03-17 22:09 GMT-07:00 Lance:

> 这段话没看懂............... 我的意思是 xx1 xx2 xx3 都已经被填充过数据，当然不一定是 1G
> 都已经填满，但肯定有数据，可以正常 get 读到，这里碰到现在的报错，是我哪里打开方式不对？
>

这主要涉及进程的虚拟内存机制。

共享内存区域只是占据了各个进程的虚拟地址空间，而对应的虚拟内存页是按需加载的。xx1 里的数据如果是由进程 A 填充的，那么如果进程 B
从未遍历过这些数据，或者没有遍历全这些数据，那么会存在一些内存页尚未被实际加载进进程 B 中。这是 OS 的一项优化。

比如 xx1 里的数据是由 nginx master 进程填充的，而 fork 之后的所有 worker 进程默认并不会立即加载 xx1
里的任何虚拟内存页。只有当各个 worker 进程实际访问 xx1 里的某些数据时，对应的虚拟内存页才会被实际加载进对应的 worker
进程。

Regards,
-agentzh

--

agentzh

Hello!

2014-03-17 22:18 GMT-07:00 Yichun Zhang (agentzh):
> 共享内存区域只是占据了各个进程的虚拟地址空间，而对应的虚拟内存页是按需加载的。xx1 里的数据如果是由进程 A 填充的，那么如果进程 B
> 从未遍历过这些数据，或者没有遍历全这些数据，那么会存在一些内存页尚未被实际加载进进程 B 中。这是 OS 的一项优化。
>

进一步地，如果进程 B 访问 xx1 共享内存区域里的某一个它尚未加载的内存页里的数据时，会产生一个 page fault，此时 OS
内核会把对应的内存页给加载进来，于是进程 B 可以顺利地读到那一页里的数据。这对于用户态进程是透明的。

而对于 systemtap 这样的外部追踪工具而言，当它访问进程 B 里的某一个尚未加载的内存页时，它并不能在进程 B 里产生一个 page
fault，因为这是不安全的，如果对应的 page 非法，则会导致进程发生段错误而崩溃。由于 systemtap 工作在内核的层面上，所以
OS 的按需加载内存页的优化会产生实际的影响，也就你在工具里看到的 read fault 错误。

一种绕过的办法是在用户进程启动时总是自己遍历一遍共享内存里的所有数据，这样可以确保相关的内存页都已经被 OS 实际加载进其进程空间。这样
systemtap 在访问时就不会读不到数据了。

Regards,
-agentzh

lancelijade

ok 我尝试一下先遍历后再继续分析

Lance

2014-03-18 13:23 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2014-03-17 22:18 GMT-07:00 Yichun Zhang (agentzh):

> 共享内存区域只是占据了各个进程的虚拟地址空间，而对应的虚拟内存页是按需加载的。xx1 里的数据如果是由进程 A 填充的，那么如果进程 B
> 从未遍历过这些数据，或者没有遍历全这些数据，那么会存在一些内存页尚未被实际加载进进程 B 中。这是 OS 的一项优化。
>

进一步地，如果进程 B 访问 xx1 共享内存区域里的某一个它尚未加载的内存页里的数据时，会产生一个 page fault，此时 OS
内核会把对应的内存页给加载进来，于是进程 B 可以顺利地读到那一页里的数据。这对于用户态进程是透明的。

而对于 systemtap 这样的外部追踪工具而言，当它访问进程 B 里的某一个尚未加载的内存页时，它并不能在进程 B 里产生一个 page
fault，因为这是不安全的，如果对应的 page 非法，则会导致进程发生段错误而崩溃。由于 systemtap 工作在内核的层面上，所以
OS 的按需加载内存页的优化会产生实际的影响，也就你在工具里看到的 read fault 错误。

一种绕过的办法是在用户进程启动时总是自己遍历一遍共享内存里的所有数据，这样可以确保相关的内存页都已经被 OS 实际加载进其进程空间。这样
systemtap 在访问时就不会读不到数据了。

Regards,
-agentzh

--

lancelijade

在一台生产服务器上依然报类似的错误，xx1一直在正常密集使用的。用 sample-bt 之类的工具也能抓出结果，说明stap应该是正常工作了。

[root@pa nginx-systemtap-toolkit]# ./ngx-shm -p 13596 -n xx1
ERROR: read fault [man error::fault] at 0x00002aac60453b80 (addr) near operator '@cast' at <input>:76:26
Tracing 13596 (/usr/local/openresty/nginx/sbin/nginx)...

shm zone "xx1"
owner: ngx_http_lua_shdict
total size: 1024000 KB
WARNING: Number of errors: 1, skipped probes: 0
WARNING: /usr/bin/staprun exited with status: 1
Pass 5: run failed. [man error::pass5]

Lance

2014-03-18 13:24 GMT+08:00 Lance <lance...@gmail.com>:

ok 我尝试一下先遍历后再继续分析

Lance

2014-03-18 13:23 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2014-03-17 22:18 GMT-07:00 Yichun Zhang (agentzh):

> 共享内存区域只是占据了各个进程的虚拟地址空间，而对应的虚拟内存页是按需加载的。xx1 里的数据如果是由进程 A 填充的，那么如果进程 B
> 从未遍历过这些数据，或者没有遍历全这些数据，那么会存在一些内存页尚未被实际加载进进程 B 中。这是 OS 的一项优化。
>

进一步地，如果进程 B 访问 xx1 共享内存区域里的某一个它尚未加载的内存页里的数据时，会产生一个 page fault，此时 OS
内核会把对应的内存页给加载进来，于是进程 B 可以顺利地读到那一页里的数据。这对于用户态进程是透明的。

而对于 systemtap 这样的外部追踪工具而言，当它访问进程 B 里的某一个尚未加载的内存页时，它并不能在进程 B 里产生一个 page
fault，因为这是不安全的，如果对应的 page 非法，则会导致进程发生段错误而崩溃。由于 systemtap 工作在内核的层面上，所以
OS 的按需加载内存页的优化会产生实际的影响，也就你在工具里看到的 read fault 错误。

一种绕过的办法是在用户进程启动时总是自己遍历一遍共享内存里的所有数据，这样可以确保相关的内存页都已经被 OS 实际加载进其进程空间。这样
systemtap 在访问时就不会读不到数据了。

Regards,
-agentzh

--

agentzh

Hello!

2014-03-19 1:11 GMT-07:00 Lance:
> 在一台生产服务器上依然报类似的错误，xx1一直在正常密集使用的。

这在生产上也是很正常的现象。毕竟

1. xx1 一直被密集使用，并不意味着它被你当前追踪的 nginx worker 进程密集使用；

2. 即使 xx1 被你当前追踪的 nginx worker 进程密集使用，也并不意味着 xx1 中所有已分配的内存页都已经被该进程访问过。

如果你想确保你不会看到这样的 read fault，那么请按我之前给你的建议，在每个 worker 进程启动时把 xx1
里已经分配过的内存页都自己在用户态里访问一遍（比如通过一个 nginx C 模块来做）。当然，这样会造成 OS
加载所有相关的内存页，造成一定的资源浪费。

> 用 sample-bt 之类的工具也能抓出结果，说明stap应该是正常工作了。
>

这个和 systemtap 没有关系。

我已经反复和你说过了，你看到的只是 OS 的虚拟内存机制的一种优化带来的无害的效应。唯一的问题只是你无法在 stap
里面看到目标进程从未访问过的内存页里的数据（因为 systemtap 要确保尽量不对被追踪的目标进程产生副作用，而 page fault
就是一种副作用，而且是一种有可能导致目标进程崩溃的副作用）。我也向你提供了解决此问题的办法，即让 nginx worker
启动时自己遍历一遍共享内存里所有已被分配过的内存页。

Regards,
-agentzh

mayuxiang

openrestyagentzh， 您好~

补充些信息：
发现此问题的场景是这样子的， xx1 分配 1G 的内存空间，对外提供某种查询服务。
其中有个较大的数据文件 16M~17M 大小，会每小时变化并写入 xx1 中，xx1:set( key, value, 0 ) 预期的是这块数据不过期并定时更新其缓存的数据内容。
xx1 更多的是密集读取， xx1:get( k ) 无效时会产生写入， xx1:set( k, v, 600 ) 预期是带有过期的缓存数据。

问题出现在 每小时写入的那块， succ, err, forcible = xx1:set( key, value, 0 ) 明确 err返回是  failed to set: no memory ，而与此同时并未出现密集读取所关联的写入 xx1:set( k, v, 600 ) 的任何相似的日志。

在出现此问题的时候 xx1:get_keys( 0 )并简单的计算了下 dict 的容量，好像并未达到 1G 的限制，我的理解是：如果接近 1G 的话，xx1 中已经正常存在这个 17M左右的数据，那么再覆盖写入的时候不容易出现 no memory 吧~ 另外，如果真的 1G 已满，那么密集读取 xx1:get( k ) 所关联（新k值时）的写入 xx1:set( k, v, 600 ) 处更应该会出现 no memory 吧~

-----------------
xingxing @ 2014-03-20 10:52:45
>Hello!
>
>2014-03-19 1:11 GMT-07:00 Lance:
>> 在一台生产服务器上依然报类似的错误，xx1一直在正常密集使用的。
>
>这在生产上也是很正常的现象。毕竟
>
>1. xx1 一直被密集使用，并不意味着它被你当前追踪的 nginx worker 进程密集使用；
>
>2. 即使 xx1 被你当前追踪的 nginx worker 进程密集使用，也并不意味着 xx1 中所有已分配的内存页都已经被该进程访问过。
>
>如果你想确保你不会看到这样的 read fault，那么请按我之前给你的建议，在每个 worker 进程启动时把 xx1
>里已经分配过的内存页都自己在用户态里访问一遍（比如通过一个 nginx C 模块来做）。当然，这样会造成 OS
>加载所有相关的内存页，造成一定的资源浪费。
>
>> 用 sample-bt 之类的工具也能抓出结果，说明stap应该是正常工作了。
>>
>
>这个和 systemtap 没有关系。
>
>我已经反复和你说过了，你看到的只是 OS 的虚拟内存机制的一种优化带来的无害的效应。唯一的问题只是你无法在 stap
>里面看到目标进程从未访问过的内存页里的数据（因为 systemtap 要确保尽量不对被追踪的目标进程产生副作用，而 page fault
>就是一种副作用，而且是一种有可能导致目标进程崩溃的副作用）。我也向你提供了解决此问题的办法，即让 nginx worker
>启动时自己遍历一遍共享内存里所有已被分配过的内存页。
>
>Regards,
>-agentzh
>
>-- 
>e>

agentzh

Hello!

2014-03-19 20:13 GMT-07:00 myx:
> 发现此问题的场景是这样子的， xx1 分配 1G 的内存空间，对外提供某种查询服务。
> 其中有个较大的数据文件 16M~17M 大小，
[...]
> 问题出现在 每小时写入的那块， succ, err, forcible = xx1:set( key, value, 0 ) 明确 err返回
> 是  failed to set: no memory

呃，这是另外一个问题了，和这个主题标题里讲的“systemtap 出错”完全无关了 :)

你这里应该是撞见了 NGINX 核心里的 slab 分配器中的一个已知的问题：

    https://github.com/chaoslawful/lua-nginx-module/issues/279

即当插入的 key-value 对的大小超过 page size（一般为 4KB）时，共享内存里使用的 nginx slab
池会出现严重的内存碎片化问题，直至抛出 no memory 错误。

建议尝试 nginx-devel 邮件列表里的下面这个针对 nginx 核心的补丁：

    http://www.mail-archive.com/nginx-devel@nginx.org/msg01489.html

我正打算这几天把该补丁整合进 openresty 默认包含的 nginx 核心中去。

Regards,
-agentzh

mayuxiang

openresty agentzh， 您好~

了解咯，十分感谢~

-----------------
xingxing @ 2014-03-21 13:57:02
>Hello!
>
>2014-03-19 20:13 GMT-07:00 myx:
>> 发现此问题的场景是这样子的， xx1 分配 1G 的内存空间，对外提供某种查询服务。
>> 其中有个较大的数据文件 16M~17M 大小，
>[...]
>> 问题出现在 每小时写入的那块， succ, err, forcible = xx1:set( key, value, 0 ) 明确 err返回
>> 是  failed to set: no memory
>
>呃，这是另外一个问题了，和这个主题标题里讲的“systemtap 出错”完全无关了 :)
>
>你这里应该是撞见了 NGINX 核心里的 slab 分配器中的一个已知的问题：
>
>    https://github.com/chaoslawful/lua-nginx-module/issues/279
>
>即当插入的 key-value 对的大小超过 page size（一般为 4KB）时，共享内存里使用的 nginx slab
>池会出现严重的内存碎片化问题，直至抛出 no memory 错误。
>
>建议尝试 nginx-devel 邮件列表里的下面这个针对 nginx 核心的补丁：
>
>    http://www.mail-archive.com/nginx-devel@nginx.org/msg01489.html
>
>我正打算这几天把该补丁整合进 openresty 默认包含的 nginx 核心中去。
>
>Regards,
>-agentzh
>
>-- 
>e>

agentzh

Hello!

2014-03-20 12:25 GMT-07:00 Yichun Zhang (agentzh):
> 你这里应该是撞见了 NGINX 核心里的 slab 分配器中的一个已知的问题：
>
>     https://github.com/chaoslawful/lua-nginx-module/issues/279
>
> 即当插入的 key-value 对的大小超过 page size（一般为 4KB）时，共享内存里使用的 nginx slab
> 池会出现严重的内存碎片化问题，直至抛出 no memory 错误。
>
> 建议尝试 nginx-devel 邮件列表里的下面这个针对 nginx 核心的补丁：
>
>     http://www.mail-archive.com/nginx-devel@nginx.org/msg01489.html
>

我上周重写了这个补丁，使用更为高效的做法，即在平时释放内存页的过程中就顺带着合并前后相邻的空闲内存页：

    https://github.com/openresty/ngx_openresty/blob/master/patches/nginx-1.7.0-slab_defrag.patch

我们已经在生产上使用了这个新补丁。它也将被直接包含在下一个 openresty 发布中 :)

Best regards,
-agentzh

lancelijade

看到相关讨论了，期待下个发布版！

Lance

2014-05-12 12:39 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2014-03-20 12:25 GMT-07:00 Yichun Zhang (agentzh):

> 你这里应该是撞见了 NGINX 核心里的 slab 分配器中的一个已知的问题：
>
> https://github.com/chaoslawful/lua-nginx-module/issues/279
>
> 即当插入的 key-value 对的大小超过 page size（一般为 4KB）时，共享内存里使用的 nginx slab
> 池会出现严重的内存碎片化问题，直至抛出 no memory 错误。
>
> 建议尝试 nginx-devel 邮件列表里的下面这个针对 nginx 核心的补丁：
>
> http://www.mail-archive.com/nginx-devel@nginx.org/msg01489.html
>

我上周重写了这个补丁，使用更为高效的做法，即在平时释放内存页的过程中就顺带着合并前后相邻的空闲内存页：

https://github.com/openresty/ngx_openresty/blob/master/patches/nginx-1.7.0-slab_defrag.patch

我们已经在生产上使用了这个新补丁。它也将被直接包含在下一个 openresty 发布中 :)

Best regards,

-agentzh

--