Mastodon Optimierungen der kanoa.de Instanz

dominion · 1. Dezember 2022 um 11:17

Ursprünglich veröffentlicht unter: Mastodon Optimierungen der kanoa.de Instanz - adminForge

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.

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)

+ proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHE:10m inactive=7d max_size=1g;
server {

listen 443 ssl http2;

listen [::]:443 ssl http2;

proxy_pass_header Server;
 proxy_pass http://127.0.0.1:3000;


proxy_buffering off;



proxy_buffering on;

proxy_redirect off;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;


proxy_cache CACHE;


proxy_cache_valid 200 7d;


proxy_cache_valid 410 24h;


proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;


add_header X-Cached $upstream_cache_status;
tcp_nodelay on;

}

Anschließend aktivieren wir die Änderungen.

# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
systemctl reload nginx.service

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“.

DEFAULT_LOCALE=de

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.

ES_ENABLED=true
ES_HOST=es
ES_PORT=9200

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

es:
  restart: always
  image: docker.elastic.co/elasticsearch/elasticsearch:7.17.4
  environment:
    - "ES_JAVA_OPTS=-Xms512m -Xmx512m -Des.enforce.bootstrap.checks=true"
    - "xpack.license.self_generated.type=basic"
    - "xpack.security.enabled=false"
    - "xpack.watcher.enabled=false"
    - "xpack.graph.enabled=false"
    - "xpack.ml.enabled=false"
    - "bootstrap.memory_lock=true"
    - "cluster.name=es-mastodon"
    - "discovery.type=single-node"
    - "thread_pool.write.queue_size=1000"
  networks:
     - external_network
     - internal_network
  healthcheck:
     test: ["CMD-SHELL", "curl --silent --fail localhost:9200/_cluster/health || exit 1"]
  volumes:
     - ./elasticsearch:/usr/share/elasticsearch/data
  ulimits:
    memlock:
      soft: -1
      hard: -1
    nofile:
      soft: 65536
      hard: 65536

Ü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.

sidekiq_1: image: tootsuite/mastodon:v4.0.2 restart: always env_file: .env.production command: bundle exec sidekiq -c 25 environment: - DB_POOL=25 depends_on: - db - redis networks: - external_network - internal_network volumes: - ./public/system:/mastodon/public/system healthcheck: test: ['CMD-SHELL', "ps aux | grep '[s]idekiq\ 6' || false"] cpu_shares: 512

sidekiq_2:
image: tootsuite/mastodon:v4.0.2
restart: always
env_file: .env.production
command: bundle exec sidekiq -q default -q push -q pull -q ingress -c 25
environment:
- DB_POOL=25
depends_on:
- db
- redis
networks:
- external_network
- internal_network
volumes:
- ./public/system:/mastodon/public/system
healthcheck:
test: [‚CMD-SHELL‘, „ps aux | grep ‚[s]idekiq\ 6‘ || false“]
cpu_shares: 512

Ü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.

db:
  restart: always
  image: postgres:14-alpine
  shm_size: 256mb
  networks:
    - internal_network
  healthcheck:
    test: ['CMD', 'pg_isready', '-U', 'postgres']
  volumes:
    - ./postgres14:/var/lib/postgresql/data
  environment:
    - 'POSTGRES_HOST_AUTH_METHOD=trust'
  command: postgres -c 'max_connections=200'

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.

web:
  image: tootsuite/mastodon:v4.0.2
  restart: always
  env_file: .env.production
  command: bash -c "rm -f /mastodon/tmp/pids/server.pid; bundle exec rails s -p 3000"
  networks:
    - external_network
    - internal_network
  healthcheck:
    # prettier-ignore
    test: ['CMD-SHELL', 'wget -q --spider --proxy=off localhost:3000/health || exit 1']
  ports:
    - '127.0.0.1:3000:3000'
  depends_on:
    - db
    - redis
    # - es
  volumes:
    - ./public/system:/mastodon/public/system
  environment:
    - WEB_CONCURRENCY=4
    - MAX_THREADS=10

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

streaming:
  image: tootsuite/mastodon:v4.0.2
  restart: always
  env_file: .env.production
  command: node ./streaming
  networks:
    - external_network
    - internal_network
  healthcheck:
    # prettier-ignore
    test: ['CMD-SHELL', 'wget -q --spider --proxy=off localhost:4000/api/v1/streaming/health || exit 1']
  ports:
    - '127.0.0.1:4000:4000'
  depends_on:
    - db
    - redis
  environment:
    - STREAMING_CLUSTER_NUM=3
    - 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.

docker-compose down && docker-compose up -d

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.

https://relay.libranet.de/inbox
https://relay.retronerd.at/actor
https://relay.ratingen.social/inbox
https://federation.stream/inbox
https://en.relay.friendi.ca/inbox
https://relay.berserker.town/inbox
https://mastodon-relay.moew.science/inbox
https://relay.froth.zone/inbox
https://relay.101010.pl/inbox
https://relay.dresden.network/inbox
https://relay.chocoflan.net/inbox
https://relay.fedi.agency/inbox
https://relay.fedibird.com/inbox
https://relay.intahnet.co.uk/inbox
https://relay.freespeech.club/inbox
https://relay.social.tigwali.fr/inbox
https://relay.mistli.net/inbox
https://relay.gruenehoelle.nl/inbox
https://relay.kretschmann.social/inbox
https://relay.beckmeyer.us/inbox
https://relay.wig.gl/inbox
https://relay.pissdichal.de/inbox
https://relay.minecloud.ro/inbox
https://relay.an.exchange/inbox
https://relay.flm9.me/inbox
https://relay.douzepoints.social/inbox
https://relay.wagnersnetz.de/inbox
https://relay.fedinet.social/inbox

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.

@daily cd /opt/docker; ./mastodon-cleanup.sh

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

#!/bin/bash # Docker exec DOCKERCMD="docker exec mastodon-web-1"

This command will remove old media from other instances

$DOCKERCMD tootctl media remove --days=7

Do the same with statuses i’ve not interacted with from other instances

$DOCKERCMD tootctl statuses remove --days=7
$DOCKERCMD tootctl cache clear
$DOCKERCMD tootctl preview_cards remove --days 7

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.

LIBRE_TRANSLATE_ENDPOINT=https://translate.adminforge.de
LIBRE_TRANSLATE_API_KEY=67ac43f6-........

Ü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

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