Mastodon Optimierungen der kanoa.de Instanz

Für die adminForge Mastodon Instanz kanoa.de haben wir kürzlich die Anleitung Mastodon Grafana Statistiken (Docker) geschrieben.

Nun möchten wir den #MastoAdmin’s die Anpassungen der noch kleinen Mastodon Instanz nicht vorenthalten.

erstelle dir ein Mastodon Konto auf kanoa.de

Punkt 1: NGINX Caching

Fangen wir vorne am Webserver an und nehmen eine kleine Anpassung mit großer Wirkung vor. Wer die offizielle nginx.conf nutzt, hat den Cache bereits aktiviert und muss nichts weiter tun.

Alle anderen sollten diese Zeilen ihrer NGINX vHost-Config hinzufügen. (Zeilen mit – löschen und mit + hinzufügen)

Anschließend aktivieren wir die Änderungen.

Punkt 2: Standardsprache ändern

In der .env.production wurde die Sprache auf „de“ gesetzt. Dies ist wichtig für Mastodon-Indexer. Diese fragen per API die Sprache ab und Default wäre sonst „en“.

Punkt 3: Volltextsuche aktivieren

Mit aktivierter Volltextsuche können angemeldete Benutzer die Suche auf Status, Erwähnungen, Favoriten und Lesezeichen ausweiten.

In der .env.production setzen wir folgende Elasticsearch-Variablen.

Für den Docker-Weg fügt bitte den Elasticsearch-Abschnitt eurer docker-compose.yml hinzu, ansonsten folgt bitte der offiziellen Anleitung.

Übernehmt die Änderungen mit docker-compose up -d.

Punkt 4: Mehrere Sidekiq Container

Sidekiq arbeitet im Hintergrund sämtliche Anfragen auf die Mastodon Instanz ab. Drum gilt, je schneller desto besser. Ich habe mich für 2 Container mit je 25 Threads entschieden. Dies ist via Docker sehr leicht erweiterbar und kann bei Bedarf auch auf mehrere Server gespannt werden.

Wichtig ist hier die command und enviroment Einstellung.

Wichtig: Es darf nur einen Sidekiq für die Warteschlange „scheduler“ geben. Aus diesem Grund sollte Sidekiq 2 und später 3, 4 usw. fest definierte Queues haben.

Bei kanoa.de sieht es wie folgt aus:
Sidekiq_1 Warteschlangen: default, push, ingress, mailers, pull, scheduler
Sidekiq_2 Warteschlangen: default, push, pull, ingress

Mit DB_POOL legen wir die Verbindungsanzahl zur Datenbank fest, dazu gleich mehr.

Übernehmt die Änderungen mit docker-compose up -d.

Punkt 5: Verbindungsanzahl optimieren

Die Datenbank lässt per Default 100 Verbindungen zu. Auf kanoa.de haben wir 200 konfiguriert und die Mastodon-Dienste darauf abgestimmt.

Zuerst geben wir PostgreSQL 200 Verbindungen, beachtet die command Zeile.

Der web Container erhält von uns auch mehr Verbindungen. Dies ermöglicht es Puma mehr Anfragen gleichzeitig abzuarbeiten. Setzt WEB_CONCURRENCY hoch auf 4 und MAX_THREADS auf 10. Das macht zusammen 40 Verbindungen zur Datenbank.

Der streaming Container bekommt nun auch mehr Verbindungen, insgesamt 60. Wir setzen STREAMING_CLUSTER_NUM=3 und DB_POOL=20.

Zusammengerechnet liegen wir bei 150 Verbindungen (2x Sidekiq mit 25, 40 Puma und 60 Streaming).

Dies könnt ihr nach Wünschen und Serverausstattung anpassen.

Wir starten den gesamten Stack einmal neu und die Änderungen sollten in eurem Sideqik und PgHero Dashboard zu sehen sein.

Punkt 6: Relais

Ein Föderierungsrelay ist ein vermittelnder Server, der eine große Anzahl öffentlicher Beiträge zwischen Servern austauscht, die es abonnieren und zu ihm veröffentlichen. Es kann kleinen und mittleren Servern dabei helfen, Inhalte des Fediverse zu entdecken, was andernfalls das manuelle Folgen anderer Leute auf entfernten Servern durch lokale Nutzer erfordern würde.

kanoa.de hat eine lange Liste an Mastodon-Relay-Servern.

Punkt 7: Mastodon Cleanup

Vor allem der Media Cache wächst ständig an.10-20 GB pro Tag ist keine Seltenheit. Wir räumen somit am besten jede Nacht per Cronjob auf.

Öffnet crontab -e und fügt diese Zeile hinzu.

Fügt mit einem Editor eurer Wahl diesen Inhalt dem Script /opt/docker/mastodon-cleanup.sh hinzu.

Mit diesem Script werden Daten älter als 7 Tage gelöscht. Aber keine Sorge, bei Bedarf werden ältere Bilder, Files etc. wieder neu vom Remote-Server geladen.

Punkt 8: Übersetzer

Die letzte Anpassung ist die Aktivierung des Übersetzungsdienstes LibreTranslate. Hierzu verwenden wir unsere eigene LibreTranslate Instanz.

In der .env.production haben wir folgende Zeilen hinzugefügt.

Übernehmt die Änderungen mit docker-compose up -d.

Es kann hier auch DeepL als Alternative genutzt werden, wer LibreTranslate nicht selbst hosten möchte.

Weitere Vorschläge nehmen wir gerne via Mastodon entgegen 😉

Euer adminForge Team

UnterstützenDas Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende.

 

4

dominion

Linux Systemadministrator

Starte eine Diskussion unter community.adminforge.de

Historischer Kommentar Archiv

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert