Gregory's ServerMastodon's database size can often be reduced either through Postgres' VACUUM command or the pg_repack extension, the latter usually being more effective as a lot of the size is in index bloat which VACUUM does not touch. Mind that I do not recommend running VACUUM FULL unless you absolutely need to reclaim disk space on the system.
 13 comments
  @Gargron
I'm doing that safely on pleroma from time to time, even with vacuum full it works fine. Though it somehow resets postgres caching states and instance runs slower for few hours/days. And it needs 2x free space.  @Gargron what does it mean for the end users? Would their old posts get deleted after a specific time? @Gargron Glad to know. I thought it meant the server/instance admin could set a period of time after which the older posts would get auto-deleted. That got me thinking. Anyway, as you've stated it's not the case, so I don't have anything to be anxious about. Thanks. Keep up the good work.  @Gargron this makes me wonder two things: If some activity past that date is referenced again (say, boosted), or is specifically requested by a user (say, by URL), would it be fetched and stored again? Or does that mean an instance with that enabled will not work with anything beyond that dateAs long as we're talking about sizes, is there any way to deal with cached account headers? That seems to be the biggest folder here by far, nothing I know intootctl touches it. @Gargron Modern Postgres supports autovacuum. Admins shouldn't need to do that. @Gargron About index bloat, that could also be solved with a |
Speaking of vacuuming, the upcoming version of Mastodon will provide admins with the option to define a content retention policy that will evict all remote posts past a defined date. A harsh, but most effective way to keep the database (and by extension, media cache) to a constant size, as far as activity by local users allows.