Skip to content
This repository has been archived by the owner on Sep 29, 2024. It is now read-only.

线上服务使用go-socket.io,遇到消耗大量内存 #172

Closed
pathbox opened this issue Mar 24, 2017 · 7 comments
Closed

线上服务使用go-socket.io,遇到消耗大量内存 #172

pathbox opened this issue Mar 24, 2017 · 7 comments

Comments

@pathbox
Copy link

pathbox commented Mar 24, 2017

为了兼容以前的服务,以前是用socket.io 写的,和前端配合。但是,服务撑不住了,改用go-socket.io重构了代码。 现在的情况是,1w+ 的socket connection 消耗了14G内存。 就是用普通的go websocket 方案,也不会消耗这么多内存。
所以,想问的问题有两个:

  1. go-socket.io 是用go重新写了一遍socket.io的库,还是只是一层socket.io api, 真正底层服务还是用到了socket.io
  2. go-socket.io 是怎么引用到socket.io 的,每个goroutine是一个连接,还是一个 socket.io 的服务了,导致消耗了大量内存. 可以告知代码位置吗?
@pathbox
Copy link
Author

pathbox commented Mar 24, 2017

还有就是,namespace 不能用额, 然后 被我们自己修复增加了个方法

@googollee
Copy link
Owner

googollee commented Mar 24, 2017 via email

@pathbox
Copy link
Author

pathbox commented Mar 24, 2017

Thank you very much

@pathbox
Copy link
Author

pathbox commented May 26, 2017

Today, I find the reason that leads to memory leak, it is not the go-socket.io. go-socket.io is working well.

@fnf521
Copy link

fnf521 commented Apr 17, 2018

I met the same problem,ask what is the reason?

@pathbox
Copy link
Author

pathbox commented Apr 21, 2018

@fnf521 The reason is not from go-socket.io. It is about the session or global map

@jjhesk
Copy link

jjhesk commented Feb 19, 2019

@fnf521 I have also talked about that in my comments in here @googollee

I think we have to follow their findings and make it integrated into iris-go. Check it out: https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb
https://speakerdeck.com/eranyanay/going-infinite-handling-1m-websockets-connections-in-go

from what I understand now, there are 2 major caveats:

  1. goroutines - reduce amount of goroutines from raising a new connection
  2. buffer allocations - keep a reference to the underlying buffers given by Hijack()

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants