Mastodon Media Storage eindämmen

Gestern hat sich meine Mastodon-Instanz verabschiedet. Die CPU-Last ging massiv nach oben und die Mastodon-Services gaben ihren Geist auf. Wie sich nach einiger Zeit herausstellte, lag es am Media Storage, der den gesamten Speicherplatz aufgefressen hatte.

Warnung: Bevor du irgendwelche Änderungen machst, speichere dir einen Snapshot, sofern deine Umgebung diese Möglichkeit bietet. Solltest du einen Fehler machen, oder die Situation verschlimmbessern, kannst du wieder zum Ausgangspunkt zurück.

Das Problem

Alle Medien, die in deinen Timelines aufscheinen, werden in den Cache geladen. Dadurch muss das Medium bei erneutem Aufruf nicht nochmal vom originalen Server geladen werden. Die Daten werden einfach vom lokalen Server geholt und das läuft auch super schnell.

Der Nachteil daran: Das braucht innerhalb kürzester Zeit sehr viel Speicherplatz., da diese Medien nicht wieder gelöscht werden.

Speicherbedarf & Datenlöschung

Im Mastodon Admin-Dashboard sieht man – unter anderem – eine schöne Übersicht des Speicherverbrauchs.

Daran kann man gut erkennen, wie sich der Speicherplatzverbrauch entwickelt.

Die nächsten Schritte zeigen, wie du auf deinem Linux-System Informationen beziehst und den Cache zurücksetzen kannst.

Stelle sicher, dass du per su - mastodon zum Mastodon-Benutzer und ins Verzeichnis home/mastodon/live wechselst.

Alle notwendigen Aufgaben können mit der Admin CLI tootctl erledigt werden. Die Dokumentation findest du hier.

Speicherplatz auflisten

RAILS_ENV=production bin/tootctl media usage

Damit bekommst du eine Übersicht der unterschiedlichen Medientypen und des jeweiligen Speicherbedarfs:

Local steht hier für alle lokalen Accounts.

Speicherplatz freigeben

Hinweis: Mit dem Parameter --dry-run können Befehle als Trockenlauf ausgeführt werden. Das bedeutet, dass alles machen, nur die abschließende Ausführung nicht. So kann man sehen, was passieren würde, ohne ggf. Schaden anzurichten.

Mit nachfolgendem Aufruf wird das Löschen aller Media-Daten simuliert, die älter als 30 Tage sind.

RAILS_ENV=production bin/tootctl media remove --days 30 --dry-run

Das Ergebnis kann nun so aussehen:

Removed 62176 media attachments (approx. 76.1 GB) (DRY RUN)

Um den Befehl schlussendlich tatsächlich auszuführen, ist lediglich das --dry-run aus dem Befehl zu entfernen:

RAILS_ENV=production bin/tootctl media remove --days 30

Damit sind nun alle Medien, älter als 30 Tage, gelöscht.

Allerdings ist es nur die halbe Miete, da im Laufe der Zeit der Speicher wieder vollläuft. Es wäre also eine gute Sache, die Mediendateien regelmäßig zu entfernen.

Aber Achtung: Wenn Medien am originalen Server entfernt werden, können diese nicht mehr nachgeladen werden.

Cronjob anlegen

Mit crontab -e kann man die Cronjobs des eigenen Benutzers öffnen. In meinem Fall möchte ich alle zwei Tage den Cache prüfen und alles älter 30 Tage entfernen. Das kann mit folgendem Eintrag erledigt werden:

0 0 */2 * * RAILS_ENV=production bin/tootctl media remove --days 30

Per crontab -l kann nochmals überprüft werden, ob der Cronjob auch tatsächlich übernommen wurde.

Fertig.

Alternative

Wie ich erst danach sah, gibt es auch in der Administration ein entsprechendes Setting. Hier würde ich direkt nach der ersten Installation zumindest die Media cache retention period setzen.