hello, on my server on which only Lemmy is running, I don’t understand why it fills up space all the time. Every day it increases by about 1GB thus risking reaching the limit after a short time.
It is not the images’ fault because there is a size limit for uploading and they are also transformed into .webp.
The docker-compose file is the one from Ansible 0.18.2 with the limits for loggin already in it (max-size 50m, max-file 4).
What could it be? Is there anything in particular that I can check?
Thanks!
28% - 40G (3 July)
29% - 42G (4 July)
30% - 43G (5 July)
31% - 44G (6 July)
36% - 51G (10 July)
37% - 52G (11 July)
37% - 53G (12 July)
39% - 55G (13 July)
39% - 56G (14 July)
You must log in or register to comment.
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.
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
pictrsstraight 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.
Not to mention the added load to all the servers that are sending you crap you don’t even look at.
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.
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.
