Nginx的slab内存会影响Top命令出来的SHR吗？

zcheng1004 · 2017-12-15T09:38:51+00:00

我奇怪的是，为什么按 Readme 的写法会不成功？Readm...

Nginx的slab内存会影响Top命令出来的SHR吗？

zcheng1004

如题。本人最近在做Nginx模块开发，用到了slab共享内存。模块中slab内存的申请释放都审查过了没有发现未被释放的。

可是，只要对Nginx进行大量请求，就会发现Top命令里面的SHR一直在升高。请较一下各位大神，slab内存和Top命令出来的SHR信息有关系吗？我该从哪些方面进行排查。

对了，我用valgrind测试过，没有报内存泄漏问题。

zchao1995

nginx 的所有共享内存，都是在配置文件解析完毕后由 master 负责申请的，worker 进程运行期间每块共享内存大小都是固定的，也不会去申请。

Top 命令的 SHR 表示的是一个进程使用的共享内存的大小，这些内存可能也被其他的进程使用着。

另外你开发时使用的 nginx，有什么其他的非原生模块吗？

On Friday, December 15, 2017 at 9:38:51 AM UTC+8, cheng zhang wrote:

如题。本人最近在做Nginx模块开发，用到了slab共享内存。模块中slab内存的申请释放都审查过了没有发现未被释放的。

可是，只要对Nginx进行大量请求，就会发现Top命令里面的SHR一直在升高。请较一下各位大神，slab内存和Top命令出来的SHR信息有关系吗？我该从哪些方面进行排查。

对了，我用valgrind测试过，没有报内存泄漏问题。

zcheng1004

目前只有自己开发的一个模块在用。没有使用其他的非原生模块。

主要是使用subrequest机制进行子请求。Nginx中使用了slab共享内存机制对子请求的结果进行缓存，子请求的量也比较大。

在 2017年12月15日星期五 UTC+8上午10:21:22，tokers写道：

nginx 的所有共享内存，都是在配置文件解析完毕后由 master 负责申请的，worker 进程运行期间每块共享内存大小都是固定的，也不会去申请。

Top 命令的 SHR 表示的是一个进程使用的共享内存的大小，这些内存可能也被其他的进程使用着。

另外你开发时使用的 nginx，有什么其他的非原生模块吗？

On Friday, December 15, 2017 at 9:38:51 AM UTC+8, cheng zhang wrote:
如题。本人最近在做Nginx模块开发，用到了slab共享内存。模块中slab内存的申请释放都审查过了没有发现未被释放的。

可是，只要对Nginx进行大量请求，就会发现Top命令里面的SHR一直在升高。请较一下各位大神，slab内存和Top命令出来的SHR信息有关系吗？我该从哪些方面进行排查。

对了，我用valgrind测试过，没有报内存泄漏问题。

zcheng1004

而且很奇怪的是，我有监控模块对系统内存的使用率进行监控。监控模块显示使用率基本稳定。

但是每个Nginx进程占用的SHR一直在升高，随之RES也一直在升高。很奇怪。

在 2017年12月15日星期五 UTC+8上午10:21:22，tokers写道：

nginx 的所有共享内存，都是在配置文件解析完毕后由 master 负责申请的，worker 进程运行期间每块共享内存大小都是固定的，也不会去申请。

Top 命令的 SHR 表示的是一个进程使用的共享内存的大小，这些内存可能也被其他的进程使用着。

另外你开发时使用的 nginx，有什么其他的非原生模块吗？

On Friday, December 15, 2017 at 9:38:51 AM UTC+8, cheng zhang wrote:
如题。本人最近在做Nginx模块开发，用到了slab共享内存。模块中slab内存的申请释放都审查过了没有发现未被释放的。

可是，只要对Nginx进行大量请求，就会发现Top命令里面的SHR一直在升高。请较一下各位大神，slab内存和Top命令出来的SHR信息有关系吗？我该从哪些方面进行排查。

对了，我用valgrind测试过，没有报内存泄漏问题。

zcheng1004

而且，还有，我在配置文件中设置的共享内存大小时100M，后续都是从这个共享内存中存取数据。可是线上的Nginx进程的SHR尽量飙到了一两个G。似乎也有一直涨下去的可能。

按照您的说法，配置文件中配置100M的话，如果不够用，worker进程会向系统继续申请吗？

在 2017年12月15日星期五 UTC+8上午10:21:22，tokers写道：

nginx 的所有共享内存，都是在配置文件解析完毕后由 master 负责申请的，worker 进程运行期间每块共享内存大小都是固定的，也不会去申请。

Top 命令的 SHR 表示的是一个进程使用的共享内存的大小，这些内存可能也被其他的进程使用着。

另外你开发时使用的 nginx，有什么其他的非原生模块吗？

On Friday, December 15, 2017 at 9:38:51 AM UTC+8, cheng zhang wrote:
如题。本人最近在做Nginx模块开发，用到了slab共享内存。模块中slab内存的申请释放都审查过了没有发现未被释放的。

可是，只要对Nginx进行大量请求，就会发现Top命令里面的SHR一直在升高。请较一下各位大神，slab内存和Top命令出来的SHR信息有关系吗？我该从哪些方面进行排查。

对了，我用valgrind测试过，没有报内存泄漏问题。

zchao1995

这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR 统计的应该统计的是共享内存物理页的大小。

zcheng1004

也就是说，还是有一些slab申请的内存没有释放，造成的SHR一直在升高

在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：

这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR 统计的应该统计的是共享内存物理页的大小。

zcheng1004

我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G

在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：

这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR 统计的应该统计的是共享内存物理页的大小。

zchao1995

单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？

On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:

我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G

在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR 统计的应该统计的是共享内存物理页的大小。

zcheng1004

8个worker，每个worker都飙到一两个G。

在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：

单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？

On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G

在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR 统计的应该统计的是共享内存物理页的大小。

spacewanderlzx

你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。

在 2017年12月15日 下午2:28，cheng zhang <zche...@gmail.com> 写道：
> 8个worker，每个worker都飙到一两个G。
>
> 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>>
>> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>>
>> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>>>
>>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>>>
>>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>>>>
>>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>>>> 统计的应该统计的是共享内存物理页的大小。
>
> --
>

zcheng1004

您好，我这边VIRT一直是很稳定的，RES和SHR一直在升高，但是RES和SHR的差值一直不变。所以是SHR的升高导致了RES升高。

应该是模块中用到的共享内存申请和释放问题。我再去检查检查

在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：

你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。

在 2017年12月15日下午2:28，cheng zhang <zchen...@gmail.com> 写道：
> 8个worker，每个worker都飙到一两个G。
>
> 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>>
>> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>>
>> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>>>
>>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>>>
>>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>>>>
>>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>>>> 统计的应该统计的是共享内存物理页的大小。
>
> --
>

zcheng1004

您好，另外我想问一下，slab申请的内存一直是由slab进行管理，那么如果slab里面有大量空余没有使用的内存，什么时候会归还给系统啊

谢谢

在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：

你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。

在 2017年12月15日下午2:28，cheng zhang <zchen...@gmail.com> 写道：
> 8个worker，每个worker都飙到一两个G。
>
> 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>>
>> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>>
>> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>>>
>>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>>>
>>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>>>>
>>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>>>> 统计的应该统计的是共享内存物理页的大小。
>
> --
>

zchao1995

释放的情况有两种：

1) 你的 nginx 服务退出

2) 重启 nginx，但是某块共享内存的配置改变了（比如名字、大小），这块旧的共享内存就会被释放

zcheng1004

好的，谢谢了。我再去看看模块代码

在 2017年12月15日星期五 UTC+8下午4:00:08，tokers写道：

释放的情况有两种：

1) 你的 nginx 服务退出
2) 重启 nginx，但是某块共享内存的配置改变了（比如名字、大小），这块旧的共享内存就会被释放

spacewanderlzx

如果 Virt 稳定，只有 shr 上涨，就我来看并不是个问题。正如 tokers 指出的，Nginx
的共享内存只有在进程退出时才释放，所以随着程序运行，shr 自然会不断上涨的（直到用完事先规划好的份额）。
这是个预期行为。

如果你在意到底是哪一块共享内存消耗了 2G，可以在启动 Nginx 的时候加上 strace，记下 mmap
MAP_SHARED|MAP_ANONYMOUS 的返回地址，然后通过 pmap -X
$pid，就可以查看到每个共享内存分配值和实际使用到值。

在 2017年12月15日 下午3:44，cheng zhang <zche...@gmail.com> 写道：
> 您好，我这边VIRT一直是很稳定的，RES和SHR一直在升高， 但是RES和SHR的差值一直不变。所以是SHR的升高导致了RES升高。
>
> 应该是模块中用到的共享内存申请和释放问题。我再去检查检查
>
> 在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：
>>
>> 你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
>> 里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
>> 毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。
>>
>> 在 2017年12月15日 下午2:28，cheng zhang <zchen...@gmail.com> 写道：
>> > 8个worker，每个worker都飙到一两个G。
>> >
>> > 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>> >>
>> >> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>> >>
>> >> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>> >>>
>> >>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>> >>>
>> >>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>> >>>>
>> >>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>> >>>> 统计的应该统计的是共享内存物理页的大小。
>> >
>> > --
>> > --
>

zcheng1004

谢谢您的耐心回答。

因为线上的SHR一直在升高，到后面占用3、4个G，线上机器就非常卡顿了。

SHR是会随着程序的运行不断上涨，但是最终会稳定在某个值，可是我的程序一直没有稳定。

请问，有没有检查slab内存泄漏的工具啊。？

在 2017年12月15日星期五 UTC+8下午8:41:52，Zexuan Luo写道：

如果 Virt 稳定，只有 shr 上涨，就我来看并不是个问题。正如 tokers 指出的，Nginx
的共享内存只有在进程退出时才释放，所以随着程序运行，shr 自然会不断上涨的（直到用完事先规划好的份额）。
这是个预期行为。

如果你在意到底是哪一块共享内存消耗了 2G，可以在启动 Nginx 的时候加上 strace，记下 mmap
MAP_SHARED|MAP_ANONYMOUS 的返回地址，然后通过 pmap -X
$pid，就可以查看到每个共享内存分配值和实际使用到值。

在 2017年12月15日下午3:44，cheng zhang <zchen...@gmail.com> 写道：
> 您好，我这边VIRT一直是很稳定的，RES和SHR一直在升高，但是RES和SHR的差值一直不变。所以是SHR的升高导致了RES升高。
>
> 应该是模块中用到的共享内存申请和释放问题。我再去检查检查
>
> 在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：
>>
>> 你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
>> 里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
>> 毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。
>>
>> 在 2017年12月15日下午2:28，cheng zhang <zchen...@gmail.com> 写道：
>> > 8个worker，每个worker都飙到一两个G。
>> >
>> > 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>> >>
>> >> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>> >>
>> >> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>> >>>
>> >>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>> >>>
>> >>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>> >>>>
>> >>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>> >>>> 统计的应该统计的是共享内存物理页的大小。
>> >
>> > --
>> >
>
> --
>

zcheng1004

对了还有个问题，如果实现规划的共享内存用完了。会怎么样。Nginx继续申请更多的内存？

在 2017年12月15日星期五 UTC+8下午8:41:52，Zexuan Luo写道：

如果 Virt 稳定，只有 shr 上涨，就我来看并不是个问题。正如 tokers 指出的，Nginx
的共享内存只有在进程退出时才释放，所以随着程序运行，shr 自然会不断上涨的（直到用完事先规划好的份额）。
这是个预期行为。

如果你在意到底是哪一块共享内存消耗了 2G，可以在启动 Nginx 的时候加上 strace，记下 mmap
MAP_SHARED|MAP_ANONYMOUS 的返回地址，然后通过 pmap -X
$pid，就可以查看到每个共享内存分配值和实际使用到值。

在 2017年12月15日下午3:44，cheng zhang <zchen...@gmail.com> 写道：
> 您好，我这边VIRT一直是很稳定的，RES和SHR一直在升高，但是RES和SHR的差值一直不变。所以是SHR的升高导致了RES升高。
>
> 应该是模块中用到的共享内存申请和释放问题。我再去检查检查
>
> 在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：
>>
>> 你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
>> 里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
>> 毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。
>>
>> 在 2017年12月15日下午2:28，cheng zhang <zchen...@gmail.com> 写道：
>> > 8个worker，每个worker都飙到一两个G。
>> >
>> > 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>> >>
>> >> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>> >>
>> >> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>> >>>
>> >>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>> >>>
>> >>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>> >>>>
>> >>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>> >>>> 统计的应该统计的是共享内存物理页的大小。
>> >
>> > --
>> >
>
> --
>

zchao1995

不会。

如果申请的共享内存接近用完，基于这块内存的 slab 分配器只会宣告本次分配失败。使用这块共享内存的模块，可以制定自己的淘汰策略，以腾出空间来满足分配请求。比如 ngx_lua 里的共享内存字典的一些 API，都是基于 LRU 的策略来进行淘汰的。

On Monday, December 18, 2017 at 5:45:37 PM UTC+8, cheng zhang wrote:

对了还有个问题，如果实现规划的共享内存用完了。会怎么样。Nginx继续申请更多的内存？

在 2017年12月15日星期五 UTC+8下午8:41:52，Zexuan Luo写道：
如果 Virt 稳定，只有 shr 上涨，就我来看并不是个问题。正如 tokers 指出的，Nginx
的共享内存只有在进程退出时才释放，所以随着程序运行，shr 自然会不断上涨的（直到用完事先规划好的份额）。
这是个预期行为。

如果你在意到底是哪一块共享内存消耗了 2G，可以在启动 Nginx 的时候加上 strace，记下 mmap
MAP_SHARED|MAP_ANONYMOUS 的返回地址，然后通过 pmap -X
$pid，就可以查看到每个共享内存分配值和实际使用到值。

在 2017年12月15日下午3:44，cheng zhang <zchen...@gmail.com> 写道：
> 您好，我这边VIRT一直是很稳定的，RES和SHR一直在升高，但是RES和SHR的差值一直不变。所以是SHR的升高导致了RES升高。
>
> 应该是模块中用到的共享内存申请和释放问题。我再去检查检查
>
> 在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：
>>
>> 你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
>> 里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
>> 毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。
>>
>> 在 2017年12月15日下午2:28，cheng zhang <zchen...@gmail.com> 写道：
>> > 8个worker，每个worker都飙到一两个G。
>> >
>> > 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>> >>
>> >> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>> >>
>> >> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>> >>>
>> >>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>> >>>
>> >>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>> >>>>
>> >>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的 SHR
>> >>>> 统计的应该统计的是共享内存物理页的大小。
>> >
>> > --
>> >
>
> --
>

spacewanderlzx

> 因为线上的SHR一直在升高，到后面占用3、4个G，线上机器就非常卡顿了。
请问 3、4个G是否超过了 Nginx 启动时显示的 Virt 的值？

> 请问，有没有检查slab内存泄漏的工具啊。？
最简单粗暴的办法：定期执行pmap -X，然后diff看哪块映射地址分配的内存增长得快。至于映射地址对应的是哪个调用，可以在启动时用
strace 追踪到（前提是这些共享内存都是在启动时分配好的）。

在 2017年12月18日 下午5:43，cheng zhang <zche...@gmail.com> 写道：
> 谢谢您的耐心回答。
>
> 因为线上的SHR一直在升高，到后面占用3、4个G，线上机器就非常卡顿了。
>
> SHR是会随着程序的运行不断上涨，但是最终会稳定在某个值，可是我的程序一直没有稳定。
>
> 请问，有没有检查slab内存泄漏的工具啊。？
>
> 在 2017年12月15日星期五 UTC+8下午8:41:52，Zexuan Luo写道：
>>
>> 如果 Virt 稳定，只有 shr 上涨，就我来看并不是个问题。正如 tokers 指出的，Nginx
>> 的共享内存只有在进程退出时才释放，所以随着程序运行，shr 自然会不断上涨的（直到用完事先规划好的份额）。
>> 这是个预期行为。
>>
>> 如果你在意到底是哪一块共享内存消耗了 2G，可以在启动 Nginx 的时候加上 strace，记下 mmap
>> MAP_SHARED|MAP_ANONYMOUS 的返回地址，然后通过 pmap -X
>> $pid，就可以查看到每个共享内存分配值和实际使用到值。
>>
>> 在 2017年12月15日 下午3:44，cheng zhang <zchen...@gmail.com> 写道：
>> > 您好，我这边VIRT一直是很稳定的，RES和SHR一直在升高， 但是RES和SHR的差值一直不变。所以是SHR的升高导致了RES升高。
>> >
>> > 应该是模块中用到的共享内存申请和释放问题。我再去检查检查
>> >
>> > 在 2017年12月15日星期五 UTC+8下午3:31:54，Zexuan Luo写道：
>> >>
>> >> 你可以比较下刚启动 Nginx 时 Virt 占用大小，看看有没有超过 2G？虽然 shr 只统计实际用到的共享内存，但是 Virt
>> >> 里面会直接加上账面分配的共享内存数，所以从 Virt 可以得知 shr 的上限应该是多少。
>> >> 毕竟除了 lua_shared_dict，其他地方也会用到共享内存，说不定是其他地方的内存占用引起的。
>> >>
>> >> 在 2017年12月15日 下午2:28，cheng zhang <zchen...@gmail.com> 写道：
>> >> > 8个worker，每个worker都飙到一两个G。
>> >> >
>> >> > 在 2017年12月15日星期五 UTC+8下午2:28:00，tokers写道：
>> >> >>
>> >> >> 单个 worker 飙到一两个 G，还是所有 worker？还有 worker 数量是多少？
>> >> >>
>> >> >> On Friday, December 15, 2017 at 2:25:59 PM UTC+8, cheng zhang wrote:
>> >> >>>
>> >> >>> 我一直观察SHR的大小，申请的是100M，SHR中一路从3M，飙到一两个G
>> >> >>>
>> >> >>> 在 2017年12月15日星期五 UTC+8下午2:04:29，tokers写道：
>> >> >>>>
>> >> >>>> 这个应该是因为刚刚申请好共享内存但是没用，对应的 page 没有换进内存，只有你真正用了之后，触发缺页，才会换进来，top 里的
>> >> >>>> SHR
>> >> >>>> 统计的应该统计的是共享内存物理页的大小。
>> >> >
>> >> > --
>> >> > --
>> > --
>