Mirant el que ocupa espai es bàsicament al base de dades:
4.4G /tmp
28G /var
A /tmp hi ha dos dumps de la base de dades de quan fem la còpia de seguretat. I a /var són 1GB de logs i la resta la base de dades. Així que el que ocupa és la base de dades.
Aparentment amb postgres es poden configurar tablespaces i poder tenir taules en particions diferents al disc. El que no estic segur si es pot fer després d´haver creat la taula ni què passaria amb les migracions al actualitzar akkoma. Així que segurament millor fer el snapshot.
si només són 28G, hi caben en el disc separat de 40.
es podria fer un mount-bind d’aquest disc a /var/lib/postgres , després d’haver mogut al disc el contingut de /var/lib/postgres
Perdoneu que se’m va passar actualitzar per aquí. Al tenir espai part de la comanda ja va funcionar però una part no.
El problema
Un cop el Marcel va arreglar l’espai al disc, la comanda (pleroma_ctl database prune_objects --keep-threads --prune-orphaned-activities) tenia problemes amb la part --prune-orphaned-activities.
Sembla que aquesta consulta a la base de dades és bastant ineficient i no podia fer-se abans del “timeout” al no haver-se fet en molt temps.
La solució
Executar la comanda manualment amb un límit fins haver eliminat totes les activitats necessàries pleroma_ctl database prune_orphaned_activities --limit 10000
Fer que la base de dades pugui utilitzar l’espai alliberat (de la taula d’ojectes i d’activitats) executant dins de la base de dades el següent:
VACUUM ANALYZE;
REINDEX TABLE objects;
REINDEX TABLE activities;
Conclusió
La base de dades ja només ocupa uns 18GB
