您好， 我感觉你这种情况跟我很像！ 我的是用户post一个较大的数据过来， 我会分解， 然后开几千个协程，同事去连接后端服务器， 那么每个协程的连接都会占用内存大小， 而没有及时的释放， 导致了我的内存持续上涨， 请问你最好是怎样处理的呢？
在 2015年9月10日星期四 UTC+8下午4:00:58，doujiang写道：多谢春哥指导 :)在 2015年9月10日 上午11:45，Yichun Zhang (agentzh) <age...@gmail.com>写道： > 我们的长链服务中有比较高的频率会执行一次完整的 `tcpsock:new connnect ... setkeepalive` > 我们发现每次 connect 的时候，都会从 request_pool 申请一个 cleanup > struct，虽然不多20多个字节，但是次数多了也就不少了，所以我们希望能复用这个 cleanup > （怎么发现的其实很好玩，用的神器 systemtap，stap++，一直想写个详细点的分享过程，无奈中间很多卡壳，还没完工） > 是的，这里 ngx_lua 更好的做法是自己在它的 ctx 内部回收和复用 cleanup struct，就像它目前通过 ctx 里的 free_bufs 和 free_recv_bufs 等链表回收和复用 chain link 结构一样。 非常感谢，这个方法看起来比较完美 :) 这里我想插一句：cosocket 的 userdata 本身应该可以榨一些油水，把它缩得更小一些。当然，那是另外一个主题了。 好滴，回头有空再仔细研究研究呵呵，涉及到 GC 都会较难复现和测试。所以我们经常使用 collectgarbage() 函数强制进行完整的 GC cycle 来暴露潜在的问题（我们甚至会注册每 Lua 语句触发的 debug hook 以较高的密度来强制完整的 GC cycle）。这些都是很有效的测试手段。 我最后的测试用例也用到了 collectgarbage，只是在我这场景里比较悲催的是，还不能 GC 太早，GC太早还复现不了 Regards, -agentzh -- --
多谢春哥指导 :)在 2015年9月10日 上午11:45，Yichun Zhang (agentzh) <age...@gmail.com>写道： > 我们的长链服务中有比较高的频率会执行一次完整的 `tcpsock:new connnect ... setkeepalive` > 我们发现每次 connect 的时候，都会从 request_pool 申请一个 cleanup > struct，虽然不多20多个字节，但是次数多了也就不少了，所以我们希望能复用这个 cleanup > （怎么发现的其实很好玩，用的神器 systemtap，stap++，一直想写个详细点的分享过程，无奈中间很多卡壳，还没完工） > 是的，这里 ngx_lua 更好的做法是自己在它的 ctx 内部回收和复用 cleanup struct，就像它目前通过 ctx 里的 free_bufs 和 free_recv_bufs 等链表回收和复用 chain link 结构一样。 非常感谢，这个方法看起来比较完美 :) 这里我想插一句：cosocket 的 userdata 本身应该可以榨一些油水，把它缩得更小一些。当然，那是另外一个主题了。 好滴，回头有空再仔细研究研究呵呵，涉及到 GC 都会较难复现和测试。所以我们经常使用 collectgarbage() 函数强制进行完整的 GC cycle 来暴露潜在的问题（我们甚至会注册每 Lua 语句触发的 debug hook 以较高的密度来强制完整的 GC cycle）。这些都是很有效的测试手段。 我最后的测试用例也用到了 collectgarbage，只是在我这场景里比较悲催的是，还不能 GC 太早，GC太早还复现不了 Regards, -agentzh --
> 我们的长链服务中有比较高的频率会执行一次完整的 `tcpsock:new connnect ... setkeepalive` > 我们发现每次 connect 的时候，都会从 request_pool 申请一个 cleanup > struct，虽然不多20多个字节，但是次数多了也就不少了，所以我们希望能复用这个 cleanup > （怎么发现的其实很好玩，用的神器 systemtap，stap++，一直想写个详细点的分享过程，无奈中间很多卡壳，还没完工） > 是的，这里 ngx_lua 更好的做法是自己在它的 ctx 内部回收和复用 cleanup struct，就像它目前通过 ctx 里的 free_bufs 和 free_recv_bufs 等链表回收和复用 chain link 结构一样。
这里我想插一句：cosocket 的 userdata 本身应该可以榨一些油水，把它缩得更小一些。当然，那是另外一个主题了。
呵呵，涉及到 GC 都会较难复现和测试。所以我们经常使用 collectgarbage() 函数强制进行完整的 GC cycle 来暴露潜在的问题（我们甚至会注册每 Lua 语句触发的 debug hook 以较高的密度来强制完整的 GC cycle）。这些都是很有效的测试手段。
Regards, -agentzh --
