Ihr glaubt nicht, wie wir gestern darum gekämpft haben, dass https://digitalcourage.social wieder eine gute Leistung abliefert – und wir haben gewonnen!
Wir haben 1. ein akutes Problem gelöst (Wachstumsschmerzen) und 2. eines, das schon Monate andauerte und Menschen mit bestimmten Internet-Anschlüssen extrem langsame Verbindungen zu unserem Server beschert hat.
Wer sich für die Details interessiert, findet sie in diesem Thread. 1/↓
Problem 1 bestand darin, dass Aufgaben, die Mastodon im Hintergrund von einer Komponente namens #Sidekiq abarbeiten lässt, immer mehr wurden. Zeitweise dauerte es über eine halbe Stunde, bis neue Beiträge in den Zeitleisten erschienen. Auch das Anhängen von Medien an Tröts dauerte so lange!
Ursache war der starke Anstieg der Nutzendenzahlen seit dem 27.10.2022.
Das haben wir zuerst dadurch zu lösen versucht, dass wir der virtuellen Maschine auf unserer eigenen Hardware mehr Ressourcen (RAM, vCPUs) gaben. Aber es wurde dadurch nicht besser.
Erst als wir Rat bei erfahreneren Mastodon-Admins suchten, kamen wir auf die richtige Spur. Ingo @ij riet uns, mehr Sidekiq-Prozesse zu starten, und schlug uns eine Lösung mit zusätzlichen #systemd-Service-Files vor. Wer Docker einsetzt, kann das gleiche auch auf anderem Weg erreichen: https://blog.freeradical.zone/post/surviving-thriving-through-2022-11-05-meltdown/#technical-details
Mehr dazu: https://docs.joinmastodon.org/admin/scaling/
Ingos Vorschlag hat unser Lastproblem gelöst. Unser ewiger Dank gehört dir!
Problem 2 haben wir in der Vergangenheit irrtümlich als #Telekomproblem bezeichnet, weil es uns vor allem von #Telekom-Kund·innen gemeldet wurde. Wir bitten dafür um Verzeihung, liebe #DTAG! Auch Nutzende von (bestimmten?) #Glasfaser-Anschlüssen waren betroffen. Und wohl auch ein paar andere.
Wer einen der betroffenen Internet-Anschlüsse hat, bekam Downloads (z.B. Bilder) von https://digitalcourage.social 50 bis 100 mal langsamer geliefert.
Nachdem wir im Fediverse nach Netzwerkexpert·innen gesucht hatten, wurden wir über mehrere Ecken an @tfiebig vermittelt, der uns extrem geduldig bei der langwierigen Fehlersuche half und schließlich eine provisorische Lösung vorschlug. 1000 Dank, Tobias!
Wer's ganz genau wissen will: Weil diese virtuelle Maschine aus unklaren Gründen ein Problem mit Path MTU discovery hat, mussten wir die #MTU auf den Wert 1320 festnageln (#clamping, #DOCSIS).
Die Diagnose des Problems ist noch nicht ganz abgeschlossen, aber jetzt haben alle wieder die volle Download-Geschwindigkeit. \o/ 3/↓
@wusel @freiheit Es hat sich im prinzip runter gehangelt; Da sind einige dinge, die nicht ganz so viel sinn ergeben; Um das wirklich zu zerlegen, muss ich die Infra einmal nachbauen (inkl. fehler, was da die herausforderung ist), um einmal 'ordentlich' mit 'den fingern zu gucken'. Das geht auf prod meist nicht so gut. 🙃😬😉
Wie gesagt, auf der todo (und, beim drueber nachdenken, braucht das vmtl. doch bis nach dem wochenende 🤔)