nginx内存暴涨问题

lihang_net · 2016-03-25T18:27:22+00:00

Hello! 2016-03-24 21:53 GMT-07:00 jakiejia: > 请问，我在lua脚本里设置了一个...

nginx内存暴涨问题

lihang_net

hi,

春哥，最近在用nginx+subrequest+upstream 开发批量插入数据到多个后端服务器。

场景：

当用户请求一个大的数据包到nginx，然后nginx进行解析，模块会根据json信息，解析成几千个子请求然后同时去后端请求数据。得到响应的数据的时候，

我会再次进行解析，然后在进行第二次的子请求（几千个左右），然后等待子请求响应，把子请求的数据合并，输出给用户。

也就是说，我主请求会发 “多次” 子请求，来得到数据。一次子请求（几千个到上万个不等）

问题：

1. 是不是所有的子请求的数据都不会在请求完就释放内存，而是等待主请求请求完毕之后才释放内存？

2. 由于我的场景比较特殊，用户批量插入数据，数据量非常多，我会解析成几千个子请求去后端服务器请求数据，这对于subrequest 过多的情况，是不是非常不适合。

或者说，我主请求没处理完的时候，我主动去把请求过的子请求给释放掉内存？

3. 如果用户请求的数据很大，导致子请求非常的多，那物理内存会一直暴涨，也没有回收。

4. 如果用ngx+lua 那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？（因为我发现用ngx+lua 在大数据包，通过lua轻线程的方式，内存消耗不大）

附近里面是内存火焰图，春哥有空帮忙看看。这种场景是几千个子请求的场景，是比较变态。

../sample-bt-leaks.sxx -x $1 --arg time=5 -D STP_NO_OVERLOAD -D MAXMAPENTRIES=20000 > $1.bt

/download/FlameGraph-master/stackcollapse-stap.pl $1.bt > $1.cbt

/download/FlameGraph-master/flamegraph.pl --countname=bytes --title="Memory Leak Flame Graph" $1.cbt > $1.svg

https://github.com/openresty/stapxx#sample-bt-leaks

sample-bt-leaks.sxx 关于这个脚本的一些参数有说明吗？

以及我怎么去看内存火焰图，我发现里面的数据很大，都超过我的机器的内存了。好像不是很准确，求春哥指点。

pmap -d 11660

mapped: 82099308K writeable/private: 81985544K shared: 1028K

ps：我已经被子请求折腾的不行了，打算直接用 ngx+lua+ffi 的形式去开发。

Attachment: 11660.svg
Description: image/svg

Attachment: 12696.svg
Description: image/svg

Attachment: 12183.svg
Description: image/svg

agentzh

Hello!

2016-03-25 3:27 GMT-07:00 Lucien Li:
> 问题：
> 1. 是不是所有的子请求的数据都不会在请求完就释放内存， 而是等待主请求请求完毕之后才释放内存？
>

是的。子请求共享父请求的内存池。

> 2. 由于我的场景比较特殊， 用户批量插入数据， 数据量非常多， 我会解析成几千个子请求去后端服务器请求数据， 这对于subrequest
> 过多的情况，是不是非常不适合。

子请求数量过多，很不合适。

> 或者说， 我主请求没处理完的时候， 我主动去把请求过的子请求给释放掉内存？
>

很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。

> 3. 如果用户请求的数据很大， 导致子请求非常的多， 那物理内存会一直暴涨，也没有回收。
>

见上。

> 4. 如果用ngx+lua  那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？  （因为我发现用ngx+lua
> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>

单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
效率都比较高，同时也可以让 CPU 计算和 I/O
充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。

Regards,
-agentzh

xiongyunkun

曾经我也碰到过这样的发送很多子请求导致内存暴涨的问题，是因为采用ngx.location.capture_multi和ngx.location.capture导致的，后来问了春哥改用ngx.thread.spawn+lua-resty-http来处理就没有这个问题了，不知道你是不是这种情况？


在 2016-03-28 03:17:03，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
>Hello!
>
>2016-03-25 3:27 GMT-07:00 Lucien Li:
>> 问题：
>> 1. 是不是所有的子请求的数据都不会在请求完就释放内存， 而是等待主请求请求完毕之后才释放内存？
>>
>
>是的。子请求共享父请求的内存池。
>
>> 2. 由于我的场景比较特殊， 用户批量插入数据， 数据量非常多， 我会解析成几千个子请求去后端服务器请求数据， 这对于subrequest
>> 过多的情况，是不是非常不适合。
>
>子请求数量过多，很不合适。
>
>> 或者说， 我主请求没处理完的时候， 我主动去把请求过的子请求给释放掉内存？
>>
>
>很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。
>
>> 3. 如果用户请求的数据很大， 导致子请求非常的多， 那物理内存会一直暴涨，也没有回收。
>>
>
>见上。
>
>> 4. 如果用ngx+lua  那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？  （因为我发现用ngx+lua
>> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>>
>
>单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
>效率都比较高，同时也可以让 CPU 计算和 I/O
>充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。
>
>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

lihang_net

感谢春哥的，耐心解答！目前我正在用ngx+lua+协程的方式，来处理后端批量请求的。

在 2016年3月28日星期一 UTC+8上午3:17:06，agentzh写道：

Hello!

2016-03-25 3:27 GMT-07:00 Lucien Li:
> 问题：
> 1. 是不是所有的子请求的数据都不会在请求完就释放内存，而是等待主请求请求完毕之后才释放内存？
>

是的。子请求共享父请求的内存池。

> 2. 由于我的场景比较特殊，用户批量插入数据，数据量非常多，我会解析成几千个子请求去后端服务器请求数据，这对于subrequest
> 过多的情况，是不是非常不适合。

子请求数量过多，很不合适。

> 或者说，我主请求没处理完的时候，我主动去把请求过的子请求给释放掉内存？
>

很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。

> 3. 如果用户请求的数据很大，导致子请求非常的多，那物理内存会一直暴涨，也没有回收。
>

见上。

> 4. 如果用ngx+lua 那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？（因为我发现用ngx+lua
> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>

单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
效率都比较高，同时也可以让 CPU 计算和 I/O
充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。

Regards,
-agentzh

lihang_net

是的，我跟你的差不多，只不过我的子请求，是c模块，而你用的是lua里面的子请求，都是一样的子请求。我目前也在改用ngx.thread.spawn来处理，也没出现内存问题了。非常感谢，在请教下你，你在用ngx.thread.spawn的时候，有哪些优化点，我感觉，咱们的场景差不多，如果方便可以分享分享下哈！

在 2016年3月28日星期一 UTC+8上午10:17:09，xiongyunkun写道：


在 2016-03-28 03:17:03，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
>Hello!
>
>2016-03-25 3:27 GMT-07:00 Lucien Li:
>> 问题：
>> 1. 是不是所有的子请求的数据都不会在请求完就释放内存， 而是等待主请求请求完毕之后才释放内存？
>>
>
>是的。子请求共享父请求的内存池。
>
>> 2. 由于我的场景比较特殊， 用户批量插入数据， 数据量非常多， 我会解析成几千个子请求去后端服务器请求数据， 这对于subrequest
>> 过多的情况，是不是非常不适合。
>
>子请求数量过多，很不合适。
>
>> 或者说， 我主请求没处理完的时候， 我主动去把请求过的子请求给释放掉内存？
>>
>
>很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。
>
>> 3. 如果用户请求的数据很大， 导致子请求非常的多， 那物理内存会一直暴涨，也没有回收。
>>
>
>见上。
>
>> 4. 如果用ngx+lua  那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？  （因为我发现用ngx+lua
>> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>>
>
>单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
>效率都比较高，同时也可以让 CPU 计算和 I/O
>充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。
>
>Regards,
>-agentzh
>
>-- 
>

xiongyunkun

ngx.thread.spawn是在同一个worker进程里面生成多个线程，我之前的应用场景是用来spawn多个线程发送子请求来拉取日志数据入库，以及spawn多个线程对库中的日志数据进行统计分析，发现如果仅仅是拉取日志入库的话（不涉及大量CPU计算），spawn几十个是没有问题的，但是如果用来进行数据统计的话spawn太多反而不好，原因就是因为他们都在同一个worker进程里面，涉及到大量上下文切换

在 2016-03-28 10:56:34，"Lucien Li" <liha...@126.com> 写道：

是的，我跟你的差不多，只不过我的子请求，是c模块，而你用的是lua里面的子请求，都是一样的子请求。我目前也在改用ngx.thread.spawn来处理，也没出现内存问题了。非常感谢，在请教下你，你在用ngx.thread.spawn的时候，有哪些优化点，我感觉，咱们的场景差不多，如果方便可以分享分享下哈！
在 2016年3月28日星期一 UTC+8上午10:17:09，xiongyunkun写道：
曾经我也碰到过这样的发送很多子请求导致内存暴涨的问题，是因为采用ngx.location.capture_multi和ngx.location.capture导致的，后来问了春哥改用ngx.thread.spawn+lua-resty-http来处理就没有这个问题了，不知道你是不是这种情况？
在 2016-03-28 03:17:03，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
>Hello!
>
>2016-03-25 3:27 GMT-07:00 Lucien Li:
>> 问题：
>> 1. 是不是所有的子请求的数据都不会在请求完就释放内存， 而是等待主请求请求完毕之后才释放内存？
>>
>
>是的。子请求共享父请求的内存池。
>
>> 2. 由于我的场景比较特殊， 用户批量插入数据， 数据量非常多， 我会解析成几千个子请求去后端服务器请求数据， 这对于subrequest
>> 过多的情况，是不是非常不适合。
>
>子请求数量过多，很不合适。
>
>> 或者说， 我主请求没处理完的时候， 我主动去把请求过的子请求给释放掉内存？
>>
>
>很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。
>
>> 3. 如果用户请求的数据很大， 导致子请求非常的多， 那物理内存会一直暴涨，也没有回收。
>>
>
>见上。
>
>> 4. 如果用ngx+lua  那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？  （因为我发现用ngx+lua
>> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>>
>
>单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
>效率都比较高，同时也可以让 CPU 计算和 I/O
>充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。
>
>Regards,
>-agentzh
>
>-- 
>
--

lihang_net

如果仅仅是ngx.thread.spawn 确实挺快的，我这个场景是批量接口，一个请求过来，我会把数据分解，然后调用ngx.thread.spawn 开几十个，几千个不等，去后端服务器插入数据，或者拉取数据，在进行合并buffer，响应给用户。我这边测试，也是cpu比较高。正如，春哥说的， nginx是一个异步的框架，尽量的尽量即收即发，才能充分提高性能。

在 2016年3月28日星期一 UTC+8上午11:06:48，xiongyunkun写道：

ngx.thread.spawn是在同一个worker进程里面生成多个线程，我之前的应用场景是用来spawn多个线程发送子请求来拉取日志数据入库，以及spawn多个线程对库中的日志数据进行统计分析，发现如果仅仅是拉取日志入库的话（不涉及大量CPU计算），spawn几十个是没有问题的，但是如果用来进行数据统计的话spawn太多反而不好，原因就是因为他们都在同一个worker进程里面，涉及到大量上下文切换

在 2016-03-28 10:56:34，"Lucien Li" <lihan...@126.com> 写道：
是的，我跟你的差不多，只不过我的子请求，是c模块，而你用的是lua里面的子请求，都是一样的子请求。我目前也在改用ngx.thread.spawn来处理，也没出现内存问题了。非常感谢，在请教下你，你在用ngx.thread.spawn的时候，有哪些优化点，我感觉，咱们的场景差不多，如果方便可以分享分享下哈！
在 2016年3月28日星期一 UTC+8上午10:17:09，xiongyunkun写道：
曾经我也碰到过这样的发送很多子请求导致内存暴涨的问题，是因为采用ngx.location.capture_multi和ngx.location.capture导致的，后来问了春哥改用ngx.thread.spawn+lua-resty-http来处理就没有这个问题了，不知道你是不是这种情况？
在 2016-03-28 03:17:03，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
>Hello!
>
>2016-03-25 3:27 GMT-07:00 Lucien Li:
>> 问题：
>> 1. 是不是所有的子请求的数据都不会在请求完就释放内存， 而是等待主请求请求完毕之后才释放内存？
>>
>
>是的。子请求共享父请求的内存池。
>
>> 2. 由于我的场景比较特殊， 用户批量插入数据， 数据量非常多， 我会解析成几千个子请求去后端服务器请求数据， 这对于subrequest
>> 过多的情况，是不是非常不适合。
>
>子请求数量过多，很不合适。
>
>> 或者说， 我主请求没处理完的时候， 我主动去把请求过的子请求给释放掉内存？
>>
>
>很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。
>
>> 3. 如果用户请求的数据很大， 导致子请求非常的多， 那物理内存会一直暴涨，也没有回收。
>>
>
>见上。
>
>> 4. 如果用ngx+lua  那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？  （因为我发现用ngx+lua
>> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>>
>
>单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
>效率都比较高，同时也可以让 CPU 计算和 I/O
>充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。
>
>Regards,
>-agentzh
>
>-- 
>
--

lihang_net

在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work

在 2016年3月28日星期一 UTC+8上午11:19:32，Lucien Li写道：

如果仅仅是ngx.thread.spawn 确实挺快的，我这个场景是批量接口，一个请求过来，我会把数据分解，然后调用ngx.thread.spawn 开几十个，几千个不等，去后端服务器插入数据，或者拉取数据，在进行合并buffer，响应给用户。我这边测试，也是cpu比较高。正如，春哥说的， nginx是一个异步的框架，尽量的尽量即收即发，才能充分提高性能。

在 2016年3月28日星期一 UTC+8上午11:06:48，xiongyunkun写道：
ngx.thread.spawn是在同一个worker进程里面生成多个线程，我之前的应用场景是用来spawn多个线程发送子请求来拉取日志数据入库，以及spawn多个线程对库中的日志数据进行统计分析，发现如果仅仅是拉取日志入库的话（不涉及大量CPU计算），spawn几十个是没有问题的，但是如果用来进行数据统计的话spawn太多反而不好，原因就是因为他们都在同一个worker进程里面，涉及到大量上下文切换

在 2016-03-28 10:56:34，"Lucien Li" <lihan...@126.com> 写道：
是的，我跟你的差不多，只不过我的子请求，是c模块，而你用的是lua里面的子请求，都是一样的子请求。我目前也在改用ngx.thread.spawn来处理，也没出现内存问题了。非常感谢，在请教下你，你在用ngx.thread.spawn的时候，有哪些优化点，我感觉，咱们的场景差不多，如果方便可以分享分享下哈！
在 2016年3月28日星期一 UTC+8上午10:17:09，xiongyunkun写道：
曾经我也碰到过这样的发送很多子请求导致内存暴涨的问题，是因为采用ngx.location.capture_multi和ngx.location.capture导致的，后来问了春哥改用ngx.thread.spawn+lua-resty-http来处理就没有这个问题了，不知道你是不是这种情况？
在 2016-03-28 03:17:03，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
>Hello!
>
>2016-03-25 3:27 GMT-07:00 Lucien Li:
>> 问题：
>> 1. 是不是所有的子请求的数据都不会在请求完就释放内存， 而是等待主请求请求完毕之后才释放内存？
>>
>
>是的。子请求共享父请求的内存池。
>
>> 2. 由于我的场景比较特殊， 用户批量插入数据， 数据量非常多， 我会解析成几千个子请求去后端服务器请求数据， 这对于subrequest
>> 过多的情况，是不是非常不适合。
>
>子请求数量过多，很不合适。
>
>> 或者说， 我主请求没处理完的时候， 我主动去把请求过的子请求给释放掉内存？
>>
>
>很多内存分配都是在内存池里完成的，而 nginx 的内存池只能提前释放大块，不会提前释放小块。
>
>> 3. 如果用户请求的数据很大， 导致子请求非常的多， 那物理内存会一直暴涨，也没有回收。
>>
>
>见上。
>
>> 4. 如果用ngx+lua  那在lua里面同时开很多”协程“ ，这样是不是性能和内存会不会也会有问题？  （因为我发现用ngx+lua
>> 在大数据包，通过lua轻线程的方式，内存消耗不大）
>>
>
>单机一两百万个协程是没有问题的。无论如何，你都应当尽量使用流式处理，避免在内存中缓存所有的数据。尽量即收即发，涓涓细流，内存和 CPU
>效率都比较高，同时也可以让 CPU 计算和 I/O
>充分地重叠。另外，单个请求的后端并发过高也不利于性能，适当控制并发度和排队，反向有利于性能提升。
>
>Regards,
>-agentzh
>
>-- 
>
--

agentzh

Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm， 如果量太大， 肯定都在一个work里面的。 这个没法避免。我在想， 有什么好的办法，
> 例如在前面加一层分解proxy， 然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

lihang_net

感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。

内存貌似一直在涨。我的解决办法是

按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

2. 关于lua的gc 他是什么时候去gc的呢？

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，

相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：

Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

lihang_net

春哥，您好！目前分析出内存比较高，主要是userdata，但是我差不多就是纯lua开发的，没用第三方的库！但是内存很高，不过我开的会在一次请求里面开成千个协程，同时去后端服务器获取数据，或者插入数据。以下是我分析的结果：

lgcstat

lgcpath

从这里显示，是不是可以说吗是由于cjson导致的userdata占用过大的？

还有什么办法可以直接dump到文件来分析。

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：

Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

doujiang24

hello，

在 2016年4月1日上午11:13，Lucien Li <liha...@126.com>写道：

感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好

https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

lihang_net

您好，请问下，您是在生产环境下这样做的吗？

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：

hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

doujiang24

在 2016年4月4日下午11:05，Lucien Li <liha...@126.com>写道：

您好，请问下，您是在生产环境下这样做的吗？

是的

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：
hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

--

lihang_net

collectgarbage("setpause", 90)

这个90 是你经过测试的，得出比较合理的值，还是随便评估的一个值，我可以调的更小吗？不知道您这个值是怎么得出来的？

在 2016年4月5日星期二 UTC+8下午1:31:51，doujiang写道：

在 2016年4月4日下午11:05，Lucien Li <lihan...@126.com>写道：
您好，请问下，您是在生产环境下这样做的吗？

是的

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：
hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

--

doujiang24

hello，

在 2016年4月5日下午2:48，Lucien Li <liha...@126.com>写道：

collectgarbage("setpause", 90)

这个90 是你经过测试的，得出比较合理的值，还是随便评估的一个值，我可以调的更小吗？不知道您这个值是怎么得出来的？

根据文档评估的，但是效果是测试过的

实际上，我们对 gc 有两个要求，1. 够快，2. 不会消耗太多 cpu

你可以在你的场景里测试不同值的效果

在我的场景里是够用的了

在 2016年4月5日星期二 UTC+8下午1:31:51，doujiang写道：

在 2016年4月4日下午11:05，Lucien Li <lihan...@126.com>写道：
您好，请问下，您是在生产环境下这样做的吗？

是的

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：
hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

--

--

lihang_net

我的场景比较变态，一次请求，我要开成千个协程，去请求后端，导致单个cpu一下子100%

在 2016年4月5日星期二 UTC+8下午4:15:30，doujiang写道：

hello，

在 2016年4月5日下午2:48，Lucien Li <lihan...@126.com>写道：
collectgarbage("setpause", 90)

这个90 是你经过测试的，得出比较合理的值，还是随便评估的一个值，我可以调的更小吗？不知道您这个值是怎么得出来的？

根据文档评估的，但是效果是测试过的
实际上，我们对 gc 有两个要求，1. 够快，2. 不会消耗太多 cpu
你可以在你的场景里测试不同值的效果
在我的场景里是够用的了

在 2016年4月5日星期二 UTC+8下午1:31:51，doujiang写道：

在 2016年4月4日下午11:05，Lucien Li <lihan...@126.com>写道：
您好，请问下，您是在生产环境下这样做的吗？

是的

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：
hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

--

--

lihang_net

我想加一层proxy，来切分一次请求的数据，然后在发给nginx+lua，这样就利用了多核

在 2016年4月5日星期二 UTC+8下午4:47:41，Lucien Li写道：

我的场景比较变态，一次请求，我要开成千个协程，去请求后端，导致单个cpu一下子100%

在 2016年4月5日星期二 UTC+8下午4:15:30，doujiang写道：
hello，

在 2016年4月5日下午2:48，Lucien Li <lihan...@126.com>写道：
collectgarbage("setpause", 90)

这个90 是你经过测试的，得出比较合理的值，还是随便评估的一个值，我可以调的更小吗？不知道您这个值是怎么得出来的？

根据文档评估的，但是效果是测试过的
实际上，我们对 gc 有两个要求，1. 够快，2. 不会消耗太多 cpu
你可以在你的场景里测试不同值的效果
在我的场景里是够用的了

在 2016年4月5日星期二 UTC+8下午1:31:51，doujiang写道：

在 2016年4月4日下午11:05，Lucien Li <lihan...@126.com>写道：
您好，请问下，您是在生产环境下这样做的吗？

是的

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：
hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

--

--

lihang_net

经过我压力测试

collectgarbage("setpause", 90) 耗cpu比较严重，严重影响了我的qps

collectgarbage("collect") 这个耗cpu一点，比上面的要好很多，并且qps也影响不大

在 2016年4月5日星期二 UTC+8下午4:15:30，doujiang写道：

hello，

在 2016年4月5日下午2:48，Lucien Li <lihan...@126.com>写道：
collectgarbage("setpause", 90)

这个90 是你经过测试的，得出比较合理的值，还是随便评估的一个值，我可以调的更小吗？不知道您这个值是怎么得出来的？

根据文档评估的，但是效果是测试过的
实际上，我们对 gc 有两个要求，1. 够快，2. 不会消耗太多 cpu
你可以在你的场景里测试不同值的效果
在我的场景里是够用的了

在 2016年4月5日星期二 UTC+8下午1:31:51，doujiang写道：

在 2016年4月4日下午11:05，Lucien Li <lihan...@126.com>写道：
您好，请问下，您是在生产环境下这样做的吗？

是的

建议你把 setpause 设置小一点，比如 90

在 2016年4月2日星期六 UTC+8下午8:01:48，doujiang写道：
hello，

在 2016年4月1日上午11:13，Lucien Li <lihan...@126.com>写道：
感谢春哥的耐心指导。可是我们的业务就有批量接口，这个很变态！

在请教下春哥，我用ngx+lua 的时候内存一直很高，这个跟用户一次post过来的数据非常大，有时候可能需要拆分为几千个协程去后端服务器请求。
内存貌似一直在涨。我的解决办法是
按照您说的把 request = {} 置空，然后在调用collectgarbage("collect")

1. 我想请教下关于我每次请求去处理完逻辑调用lua的gc，是不是这样会影响性能？

collectgarbage("collect") 会进行一次全局 gc，确实对性能不友好
https://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

建议你把 setpause 设置小一点，比如 90

2. 关于lua的gc 他是什么时候去gc的呢？

https://www.lua.org/manual/5.1/manual.html#2.10

3. 我测试了下，如果我不是每次请求的时候去调用collectgarbage("collect")，会导致内存一直涨，目前观察到700-800M 了，
相反如果我每次请求去collectgarbage("collect")，内存会相对小很多，并且不会一直涨。请教下这是gc释放不够及时导致的吗？

这样看起来应该是的

在 2016年4月1日星期五 UTC+8上午2:37:10，agentzh写道：
Hello!

2016-03-27 20:24 GMT-07:00 Lucien Li:
> 在同一个work 这个是因为每个work都有个lua vm，如果量太大，肯定都在一个work里面的。这个没法避免。我在想，有什么好的办法，
> 例如在前面加一层分解proxy，然后在打到我后端处理ngx+lua 这样可以利用多个work
>

尽量使用流式处理啊，流式处理。别把大的数据全缓冲了。

Regards,
-agentzh

--

--

--