Might want to check out this issue. Honestly, I'm not sure what exactly the activity table consists of or what it does but it's been eating through everyone's disk space pretty fast.
this post was submitted on 14 Jul 2023
49 points (98.0% liked)
Lemmy Support
4634 readers
14 users here now
Support / questions about Lemmy.
founded 5 years ago
MODERATORS
well, indeed it could be just that. I just checked and it's size is 15GB 😱
The activity table is every message that is sent or received between your instance and the rest of the fediverse; posts, comments, votes, admin actions, etc.
Extra config options always result in more complexity, so I would strongly prefer to change the hardcoded pruning interval instead.
Why would that be the case?
I'm not too sure as well. Most people running their own Lemmy instance probably want more config options to fit their needs. I like how much I can configure with pictrs straight from the docker compose file for example.
It warms my heart to see lemmy instance owners learning about the nuances of db administration 🥰
I don’t think you should be enjoying the fact that there are some problems that could realistically cause a large portion of Lemmy instances to become unsustainable. We should be working towards a way that we can ensure the Lemmy ecosystem thrives.
I mean… it was kind of a joke. At the same time, if someone is hosting a database on their own hardware, it is important to understand when and how the database actually releases disk.
That said, I completely agree that this is an issue that does need to be addressed.
You can delete old entries from the table. The space will not be released to the filesystem automatically though, but you won't have to worry about it until enough days pass where it's filled up the same amount that was freed.
Im sure it couldn't be difficult to do a rolling purge to keep the file at a fixed size?
If you need the space back on the filesystem, you could rebuild the table with VACUUM FULL. Do note that the table would be unavailable during that process as it would be locked exclusively. https://www.postgresql.org/docs/current/sql-vacuum.html
You'd need to take your site down for a while since write access is necessary to that table to avoid duplicates. But yeah, once you've done a vacuum full you could find a way to each day trim old entries.
Entries older than 6 months are deleted by default, but as far as I understand it might be safe to manually delete them sooner than that?
I'm purging much more aggressively than that an so far so good.
Good to know, thanks! I have space to spare, but I'll probably make it more aggressive to save on backup size
Bearing in mind that posts and comments from communities your users are subscribed to will flow into your instance, not as a reference, but as a copy. So all those “seeding” scripts are terrible ideas in bringing in content you don’t care about and filling up space for the heck of it. If you’re hosting a private instance, you can unsubscribe from things that won’t interest you, thereby slow down the accumulation of contents that are irrelevant and just wasting space.
Yes I had considered that, but considering that ours is not a giant but moderate instance (a thousand subscribers) it seemed exaggerated to get to have 1GB occupied every day.
load more comments
(2 replies)
Not to mention the added load to all the servers that are sending you crap you don't even look at.
Back in the early 2000s, Usenet servers could store posts in a fixed-size database with the oldest posts expiring as new posts came in. This approach would mean that you can't index everything forever, but it does allow you to provide your users with current posts without having infinite storage space.
Back in the early 2000s, Usenet servers could store posts in a fixed-size database with the oldest posts expiring as new posts came in. This approach would mean that you can't index everything forever, but it does allow you to provide your users with current posts without having infinite storage space.
view more: next ›