Open matrixbot opened 2 weeks ago
This comment was originally posted by @stintel at https://github.com/matrix-org/dendrite/issues/2693#issuecomment-1236441615.
Not so long after opening this issue the dendrite-monolith-server process is back to eating a CPU core and > 1GB RAM, but at least clients seem to respond normally now, seeing proper room names and no longer crazy slow.
I wanted to ask this in the Dendrite room, but it appears my server is banned from the room (already in contact with abuse@ about that), so I'll ask it here: Do the profile files generated from the instructions on https://matrix-org.github.io/dendrite/development/profiling contain sensitive data?
This comment was originally posted by @neilalexander at https://github.com/matrix-org/dendrite/issues/2693#issuecomment-1236776283.
The profiles are safe, so might be worth inspecting what's going on there.
Has this bug been reported to the NeoChat team? Something is horribly wrong if it's registering new devices every few minutes.
This comment was originally posted by @stintel at https://github.com/matrix-org/dendrite/issues/2693#issuecomment-1237574784.
Has this bug been reported to the NeoChat team? Something is horribly wrong if it's registering new devices every few minutes.
Actually the client causing this might not have been NeoChat. It appears to be matrix-ircd, which for some reason shows up as a different client. After enabling real_ip_header I now see the correct client IP, which confirms it's matrix-ircd and not NeoChat. I have updated the issue to reflect this.
Looks like this is a known issue in matrix-ircd: https://github.com/matrix-org/matrix-ircd/issues/43. Nonetheless, I believe the possibility to limit the amount of devices a user can register is a reasonable feature request?
This comment was originally posted by @kegsay at https://github.com/matrix-org/dendrite/issues/2693#issuecomment-1339531674.
I believe the possibility to limit the amount of devices a user can register is a reasonable feature request?
YES PLEASE. The problem is that if you omit the device_id
field on registration/login, one is randomly generated. So just innocently missing this field can cause rampant device creation. This then exacerbates slow E2EE because there's so many devices to encrypt for.
This issue was originally created by @stintel at https://github.com/matrix-org/dendrite/issues/2693.
Background information
go version
: 1.18.5Description
Steps to reproduce
join
at line 1 column 268)While possibly a neochat bug, I belive Dendrite should have a configurable limit for max # of devices per user to avoid situations like this. The default should be reasonably low. I have just signed out >600 (!) devices, both dendrite and postgresql where eating all 4 vCPUs after doing so, with load average growing over 10.
I believe this could be related to my Dendrite instance permanently eating a CPU core and consuming consistently more than 1GB of RAM, and random rooms being completely out of sync for the last few months. Possibly also the cause of #2566? I have had that problem many times, and deleting the jetstream directory seemed to bring temporary relief, but eventually some channels stopped syncing again.
I've experienced issues for a while, but what finally led me to start digging was various room names being missing, instead member names separated by comma being displayed. Unfortunately I forgot to screenshot that and that problem seems to have solved after signing out all the duplicate devices.