Nach nicht einmal 2 Wochen hab ich die 20GB SSD 80% voll. Die Purge-Scripts, die ich heute ausgeführt und dann in den cron übernommen habe, haben gerade einmal 1GB frei geräumt.
Im Netz finde ich viele Anleitungen, wie ich den Speicher auslagern könnte. Persönlich ist mir die S3 Technologie noch fremd. Doch da würde ich mich schon einlesen. Aber was ist mit dem Datenschutz? Ich hab dann wieder einen Mitspieler mehr …
Generelle Frage: Wie löst ihr dieses Problem mit der Datenmenge? Selfhosted, also Server im Besenkammerl?
@chpietsch@digitalcourage.social @jakob@soc.schuerz.at #Mastoadmin
Man könnte einen Server mieten, der nur so vor Speicher strotzt und da mit z.B. Minio eine S3 kompatible Schnittstelle bereitstellen. Damit wäre das Thema Datenschutz wieder im grünen Bereich.
Der Server würde nicht viel CPU oder RAM brauchen, nur an Speicher würde ich dann auch nicht sparen.Aktuell läuft meine Instanz auf einem kleinen Hetzner, eine VCPU und ich glaube 2GB RAM. Geht sich locker aus. Sind auch wenig User noch. Es geht also wirklich nur um die “Festplatte”. Warum Minio und nicht gleich Amazon S3? Wegen OpenSource? Minio ist auch ein US-Unternehmen, OSS ist ja für die DSGVO nicht relevant, da geht es eher um die geographische Platzierung der Daten.
Minio, weil man es selbst betreiben kann. Den Serverstandort und wer darauf zugriff hat, würdest dann du bestimmen. Bei Amazon S3 selbst weiß man nie, wer darauf Zugriff hat und da Amazon ein US-Unternehmen ist, ist es an den Patriot-Act gebunden und muss Daten bei Nachfrage an CIA, FBI, … herausgeben.
interessant – muss ich mir nochmals genauer ansehen …
S3 auf keinen Fall. Da zahlt man massig viel unkontrollierbare Gebühren, da man für Traffic zahlt. (Habe das auf den unschönen Weg gelernt durch eine 80$ Rechnung für 20 Tage 🙈)
Ich habe meine Files jetzt auf Linode. 5$ im Monat und unbegrenzt Traffic.
Aber falls die Daten in Zukunft mehr werden, werde ich vielleicht wirklich über nen Minio-Proxy ein Hetzner Cloud Volume mounten.
Kommt auf den Anbieter an, gibt auch ganz interessante Angebote.
Oh, sorry… Mit S3 meinte ich AWS S3 😅🙈
gut dann ja
Hi, seit dem Release von 4.x kannst du die Purge Scripts vergessen, das wurde als Hintergrundaufgabe eingebaut.
Die Aussage, das nach 2 Wochen 20 GB belegt wurden, hat nur in Verbindung mit der Information Relevanz, wie viele User auf der Instanz sind und mit wie vielen sie verbunden ist.
Was sagt denn der command
bin/tootctl media usagewo der ganze Speicher verbraucht wird?PS: Es gibt auch einen Matrix Kanal für Instanzadministratoren: https://matrix.to/#/#fedimins:tchncs.de
Ahja, ich fand diese Purge-Scripts eh schon absurd - was wäre das für eine SW, die so was nicht fix verbaut hat. Auch sind ja im GUI verdächtig ähnliche Eingabemöglichkeiten zu finden. Ich hab die Scripts nur trotzdem versucht, weil es in der Original-Doku noch so steht. Danke jedenfalls für den Hinweis!
Am Server sind ~8 User nur aber halt auch ein Relais eingetragen. Den meisten Platz verbraten Avatare und “Vorschaukarten”.
$ env RAILS_ENV=production live/bin/tootctl media usage Attachments: 610 MB (5,35 MB local) Custom emoji: 57,6 MB (277 KB local) Preview cards: 15,8 MB Avatars: 1,26 GB (337 KB local) Headers: 3,2 GB (466 KB local) Backups: 0 Bytes Imports: 0 Bytes Settings: 202 KBWie sich Relais auf den Speicher auswirken, weiß ich nicht, hab diese nie genutzt.
Aber die Daten von Mastodon belegen keine 20 GB bei dir. Hast du vielleicht irgendwelche Logs laufen, die deine Platte füllen?
Update
Also zu allererst muss ich gestehen nicht lange genug nachgedacht zu haben: Natürlich steigt bei einem neu installierten Server der Festplattenverbrauch anfangs rascher an. Logrotate aber auch die Vorhaltefristen von Mastodon für Medien greifen ja erst nach einigen Tagen – ab dann sollte sich die Auslastung der HD einpendeln. Und so war es dann auch. Nachdem ich die Aufbewahrungsfrist für Inhalte auf 1/3/3 (statt 1/7/7) reduziert hatte, sank die Auslastung auf ~75% (~14GiB) und dort blieb sie auch. Hab jetzt die die Aufbewahrungsfristen wieder auf 1/7/7 erhöht und beobachte die Situation. Sehr nützlich dafür ist wie immer ein Monitoring. Hab das erstmals mit mit Nagios sondern mit Telegraf/Influxdb/Grafana realisiert. Vor allem auch in Hinblick auf die Möglichkeit Alerts zu setzen, die mich rechtzeitig warnen.
Hier sehen wir an den Sägezähnchen, dass zwei mal in der Nacht irgendwas gelöscht wird: Einmal kurz vor Mitternacht und ein zweites mal früh morgens. Ich tippe auf logfiles und Mastodon-Inhalte. Danke @Tealk@lemmy.rollenspiel.monster du hast mich auf die richtige Spur gebracht.
Mit Grafana bin ich auch gerade am Einarbeiten, wollte ich eig. schon lange mal anfangen und habs immer wieder vor mich hergeschoben
Bei läuft der inzwischen und ich hab den Mastodon und den PeerTube Server damit unter Kontrolle. Hab schon überlegt, ob eine gemeinsame Nutzung des influxDB/Grafana-Hosts nicht sinnvoll wäre. Ausgelastet ist der noch lange nicht und auf den überwachten Geräten muss dann nur telegraf installiert werden. Das ist der einfachste Teil von allem. Also ich würde mich um den eh schon laufenden Server kümmern und freu mich, wenn sich andere mit der Grafana-Oberfläche beschäftigen. Dzt. hänge ich beim Erstellen von Alerts …
Gester hab ich schon nen Server aufgesetzt und soweit alles installiert, jetzt muss ich rausfinden wie ich die Daten von a nach b bekomme also von den Linux Maschinen sowie von Mastodon und co
Und noch ein Update: Journald hat als default eingestellt, dass mindestens 15% der Dateisystemgröße frei bleiben müssen. Ist das nicht mehr der Fall, werden ältere Logs (Journale) gelöscht. Das wusste ich auch nicht und bin davon ausgegangen, dass Logs “wie früher” zeitabhängig wegrotiert werden. Also wenn der Platzverbrauch rasch auf bis zu 85% ansteigt, ist das relativ normal.
Quelle: https://www.freedesktop.org/software/systemd/man/journald.conf.html
Die Schwellwerte im Monitoring sind daher bei 86% für WARNING und 95% für CRITICAL zu setzen – imho.
Aktuell schaut der Graph so aus:
Am 1.1. hab ich die Behaltefristen im Mastodon wieder auf 1/7/7 gestellt und auch gleich die Volltextsuche installiert. Am 5.1. dann einmal die Journale aufgeräumt (
journalctl --vacuum-size=...) um mich ohne Stress der genaueren Analyse zu widmen. Geändert hab ich an der journald-Konfiguration nur, dass die Behaltefrist auf 90 Tage beschränkt wird – wie es in der DSE steht. Für die größenanhängigen Parameter scheinen mir die defaults zu passen.
