matrix-org
Integrate the rust state compressor with Synapse.
@Azrenbeth I've pushed a couple of commits that attempt to reuse the postgres connection parameters from an existing connection. I haven't had a chance to test it though
@Azrenbeth I've pushed a couple of commits that attempt to reuse the postgres connection parameters from an existing connection. I haven't had a chance to test it though
That should now be working again!
It looks like we also block shutdown until the compression run has finished, which isn't ideal
It looks like we also block shutdown until the compression run has finished, which isn't ideal
Is there a way to interupt it? There shouldn't be any problem if the compressor gets stopped mid way through.
It looks like we also block shutdown until the compression run has finished, which isn't ideal
Is there a way to interupt it? There shouldn't be any problem if the compressor gets stopped mid way through.
There should be a way of doing it, you can mark threads as a "daemon" so they don't block shutdown, but can't remember quite how to do it off the top of my head
It looks like we also block shutdown until the compression run has finished, which isn't ideal
Is there a way to interupt it? There shouldn't be any problem if the compressor gets stopped mid way through.
There should be a way of doing it, you can mark threads as a "daemon" so they don't block shutdown, but can't remember quite how to do it off the top of my head
Ran out of time to work out how Twisted shuts down, but we'd want it to stop the compressor, not let it keep running after Synapse stops (to prevent accidentally having two compressor runs happen simultaneously)
We need to figure out exactly what to do here, as things stands this makes our CPU metrics useless. One thing we could do is run it in a child process?
We need to figure out exactly what to do here, as things stands this makes our CPU metrics useless. One thing we could do is run it in a child process?
That sounds sensible. Is there any reason not to?
We need to figure out exactly what to do here, as things stands this makes our CPU metrics useless. One thing we could do is run it in a child process?
That sounds sensible. Is there any reason not to?
I don't think so, just time.
We need to figure out exactly what to do here, as things stands this makes our CPU metrics useless. One thing we could do is run it in a child process?
As a clarification for future context: the issue is that it would frequently spike over 100% cpu, so you could no longer tell how close the python code was to saturating the cpu. In other words, we'd like it to be separate from the normal CPU metrics.
