请教一下, workerman结合ci框架, 在定时调用ci的model方法时, 内存缓慢的增加, 有什么思路可以解决? 如下图, 是跑了3个月后的内存情况
[attach]1755[/attach]
可能是ci框架或者业务代码有内存泄漏。 最简单的方法是按照手册设置下处理一定数量请求后重启进程。 参考手册 http://doc.workerman.net/faq/max-requests.html 另外看到每个进程的连接数很多,7-8千,这个感觉不正常。服务端返回数据完毕后最好把连接关闭,避免连接数不断增加造成内存泄漏。
好的 1 关于内存泄露, 我按照文档改了 2 关于连接数过多, 是因为我用的是 JsonRpc/Clients/RpcClient 来做rpc, 是通过异步发送请求(如 asend_getInfoByUid()), 我看 RpcClient 的代码是没有主动closeConnection(), 必须显式调用异步接收响应(如 arecv_getEmail())才能触发 closeConnection(). 但这个异步接收响应实际上是阻塞的, 我就是因为不想阻塞才使用异步请求的. 也就是说异步rpc中, 每次调用都会新建一个连接, 而不能复用连接
JsonRpc客户端不会复用连接。你可以自己改造下手动关闭连接
直接定时释放超时的连接
可能是ci框架或者业务代码有内存泄漏。
最简单的方法是按照手册设置下处理一定数量请求后重启进程。
参考手册 http://doc.workerman.net/faq/max-requests.html
另外看到每个进程的连接数很多,7-8千,这个感觉不正常。服务端返回数据完毕后最好把连接关闭,避免连接数不断增加造成内存泄漏。
好的
1 关于内存泄露, 我按照文档改了
2 关于连接数过多, 是因为我用的是 JsonRpc/Clients/RpcClient 来做rpc, 是通过异步发送请求(如 asend_getInfoByUid()), 我看 RpcClient 的代码是没有主动closeConnection(), 必须显式调用异步接收响应(如 arecv_getEmail())才能触发 closeConnection(). 但这个异步接收响应实际上是阻塞的, 我就是因为不想阻塞才使用异步请求的.
也就是说异步rpc中, 每次调用都会新建一个连接, 而不能复用连接
JsonRpc客户端不会复用连接。你可以自己改造下手动关闭连接
直接定时释放超时的连接