E = mc^2 🤯

…there might be other reasons too…

If I had to suggest something:

• Quick switching between accounts on different instances (a couple of clicks, instead of another website in another tab)
• More configurable UI. Quickly switch between seeing/not seeing read posts, NSFW, NSFW blur
• Combined communities list and/or wall between all your accounts, so that you see more

Cool! What do you want to add to it to distinguish itself from the browser version?

Lukoshenko did say that Prigozhin is moving freely in Russia, as opposed to staying in Belarus, as negotiated. Something might be brewing.

*covfefe

Rust has no garbage collector though. Memory is freed up as soon as the variable leaves the current scope.

I’m guessing the server was still set up to restart every 30 mins at the time this pic was taken. Then they tried disabling that and it was fine.

Oh. I’m mainly using the browser for pretty much everything.

I think Memmy, an iOS client that released just today or yesterday, allows you to.

You can see content without an account. Unless it’s NSFW, I guess.

YARRRR! I’m not a wannabe. I’m an irate pirate!

Great! 😁 I was just wondering because the memory graph showed sharp falls in memory usage every ~30 mins.

Is the memory leak still there?

Interesting to hear this from a dirty lemmy.fmhy.ml-er! 😈

He was free()d

I think the devs have been aware of the issue, theoretically, for a while. A proper solution requires some significant changes, so it was being postponed because this wasn’t considered urgent.

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.

3 days without pooping is 3 days wasted

I’m calling it - if there’s actually a memory leak in the Rust code, it’s gonna be the in memory queues because the DB’s iops can’t cope with the number of users.

But… but… Rust…

These are upvotes and downvotes. I doubt views are logged anywhere, apart from the webserver.