-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Media worker accumulates over 1000 connections to mega.nz #15440
Comments
Do you have an example mega.nz URL that causes this, for us to debug with? :) |
https://mega.nz/folder/test1 etc. will trigger URL preview requests Testing it on a separate server, previewing those URLs also opens connections that seem to never close -- while another url such as https://example.org/ will close after a few minutes. |
I note that mega.nz hints that the connection may be kept-alive, though it does not provide an upper bound on the duration:
Synapse doesn't have any special handling of keep-alive that I can see; it delegates to synapse/synapse/http/client.py Lines 394 to 404 in c932614
|
Possibly related: #8302, GHSA-4822-jvwx-w47h |
We don't pass a timeout directly to synapse/synapse/http/client.py Lines 406 to 412 in c932614
But this internally calls synapse/synapse/http/client.py Lines 406 to 412 in c932614
(which has the same effect as passing a timeout to treq.request). We also have a timeout for reading the body of the request: synapse/synapse/http/client.py Line 728 in c932614
So TL;DR I can't see an obvious path in Synapse that would mean url preview connections hang around longer than they should do. Are there any relevant logs including the string |
I looked into this a little bit and found some interesting (?) things:
The default number of connections per host that Twisted usually has is 2, I think this is way overkill from the URL previewer. The comments say the number was upped for connections to push servers; I think we should have a separate |
From some conversations with the Twisted developers, it seems like this is related to TLS not shutting down properly. (There's a bunch of issues about this on the Twisted bug tracker.) Will try to investigate a bit more. |
I think twisted/twisted#7926 is the canonical upstream issue, the tl;dr is that you sometimes end up in OpenSSL calling I'm not quite sure what the proper behavior here is though, it sounds like you should attempt to read (and write?) to the TLS connection until a response is received? Relevant twisted code is at https://github.com/twisted/twisted/blob/7e57b24a9fb20c590eac97d7b8ba0730c3633873/src/twisted/protocols/tls.py#L331-L349 One of the developers suggested some of the hacks in https://gist.github.com/adiroiban/0824467069b25f308b1c71249b146132 might be useful, but I haven't tried them. |
I don't have time to work on this at the moment but to re-iterate I think there's two things to follow up on here:
|
Description
Our homeserver is accumulating connections to mega.nz (31.216.145.5) at a rate of approximately 2 per hour, most likely corresponding to URL preview requests for mega.nz. The largest amount I've seen is 1025 connections, spanning two media_worker instances.
Steps to reproduce
netstat -an | grep 31.216.145.5
I am observing the same https connections being open from 10 hours ago, as well as additional new ones opening.
The URL preview requests complete as expected, but the https connections are never closed, and new ones are slowly added over time.
I would expect that at some point the connections would be closed, rather than being staying open indefinitely.
Homeserver
another homeserver
Synapse Version
1.81
Installation Method
Debian packages from packages.matrix.org
Database
PostgreSQL
Workers
Multiple workers
Platform
lxc container with no outgoing http proxy configured for url previews
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response
The text was updated successfully, but these errors were encountered: