Upvote me daddy
Interesting to hear this from a dirty lemmy.fmhy.ml-er! π
I think I found what eats the memory. DB iops isn't the cause - looks like the server doesn't reply before all the database operations are done. The problem is the unbounded queue in the activitypub_federation crate, spawned when creating the ActivityQueue struct. The point is, this queue holds all the "activities" - events to be sent to federated instances. If, for whatever reason, the events aren't delivered to all the federated servers, they are retried with an exponential backoff for up to 2.5 days. If even a single federated instance is unreachable, all events remain in memory. For a large instance, this will eat up the memory for every upvote/downvote, post or comment.
Lemmy needs to figure out a scalable eventual consistency algorithm. Most importantly, to store the messages in the DB, not in memory.
But... but... Rust...
These are upvotes and downvotes. I doubt views are logged anywhere, apart from the webserver.
Big true! I'm actually spending most of my time on Lemmy down in the comment section π
In terms of an optimal load spread, it's best if the lemmiverse is split into multiple equally sized instances. If you use an instance just for yourself, it doesn't actually decrease the load on the main servers in any way. The only thing you get is a guarantee that your instance won't suddenly go down.
This dude literally understood infinity in the shower...
Imagine using Windows in 2023
Are there really over 10 million lemmy users? I almost don't believe it
*covfefe