CPU 100% after a few minutes idle in seed mode

[hsribei]

Happened both at instant.io and btorrent. Left a tab open to upload a book and, even though there's no one downloading, CPU shoots to 100% in a minute or two. Let me know if I can help diagnose. Thanks!

[DiegoRBaquero]

Yes! I hadn't noticed this happened but it's horrible. In my case the memory and CPU usage slowly increases. According to some people is because of the number of datachannels that are created and never killed. I haven't been able to confirm this as the chrome://webrtc-internals doesn't work that well itself and freezes after a second.

[feross]

I believe the issue is caused by out-of-control creation of WebRTC connections which are never cleaned up. We just need to destroy the simple-peer instances that are optimistically created in bittorrent-tracker when finding peers from the tracker server. They're never destroyed right now, so there's probably thousands of them after a few minutes.

This problem is worse with multiple trackers, as twice as many connections are attempted.

[loon3]

If you're using Chrome, you can watch the datachannels multiply in chrome://webrtc-internals/ until it eventually crashes. It would be nice to be able to set a parameter for the max number of datachannels in the client object.

[feross]

It would be nice to be able to set a parameter for the max number of datachannels in the client object.

Yep, there's already a maxConns option that's set to around 50, if I remember correctly! 😄

This issue is about data channels that aren't destroyed and cleaned up. They're not being counted as part of the 50.

[loon3]

I was actually messing around with maxConns parameter and have it set down to 5 now, but it didn't seem to affect the number of data channels that popup in the webrtc-internals window

[feross]

Yeah, that's because a data channel doesn't count until it's connected. It's kind of like how we don't count outgoing TCP connections until they connect.

See: https://github.com/feross/bittorrent-swarm/blob/master/index.js#L94

[loon3]

Ahh, ok that makes sense.

I've also found that the data channels persist even after all torrents in the client are destroyed.

[feross]

Yeah, there's literally zero cleanup code for connections. There's a TODO in the code to do that. 😅

[feross]

PR welcome!

[loon3]

Hahaha, yeah I found a few of the TODO's 😝

I'll take a look through the code and see if I can digest it enough to offer a good cleanup solution.

[feross]

Awesome. Happy to answer any questions as you try to figure it out.

[feross]

Working on this right now. Should have a fix soon.

[loon3]

Awesome! I was having a bit of difficulty removing peers created under onSocketData so it's very helpful to see how you solved it. Has this update been rolled into webtorrent.min.js?

[feross]

@DiegoRBaquero, I've tracked down part of what's causing this problem. The BTorrent tracker automatically kills the tracker connection after 60 seconds, since no data is sent and we don't currently send heartbeats. You said you had it hosted behind nginx right? You should increased the proxy_read_timeout option to something more than 60 seconds. Maybe 15 minutes?

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout

In the meantime, I'm going to switch back to one tracker since every time the disconnect happens, webtorrent reconnects and generates another 10 webrtc offers.

[DiegoRBaquero]

@feross Set to 15m

[feross]

Nice, seems to be working. I readded the second tracker to https://instant.io.

[feross]

@loon3 Yes, the update was released as 0.63.3 and is available in webtorrent.min.js now.

[loon3]

great! thanks!

[lock]

This thread has been automatically locked because it has not had recent activity. To discuss futher, please open a new issue.