Nach mehreren Tagen Messung möchte ich unsere Untersuchung zum ungewöhnlich
anwachsenden PHP-FPM-Pool abschließen.
Der wichtigste Befund ist inzwischen recht eindeutig:
Von 196.466 ausgewerteten Slowlog-Ereignissen enthielten 195.069 einencurl_exec()-Aufruf, also rund 99,3 Prozent.
Zusätzlich konnten wir einen betroffenen PHP-FPM-Prozess während eines realen
Ereignisses mit ss und strace beobachten. Dabei wartete der Prozess über viele Sekunden wiederholt in poll() auf Daten eines externen HTTPS-Sockets. Über ss ließsich derselbe File-Descriptor derselben PID eindeutig einer externen Verbindung zuordnen. Gleichzeitig bestanden mehrere weitere PHP-FPM-Verbindungen zu denselben wenigen Gegenstellen.
MariaDB und Redis antworteten im selben Zeitraum dagegen sehr schnell. Der Engpass
lag also nicht primär im lokalen System, sondern im Warten auf externe HTTP-
Kommunikation.
Nach der schrittweisen Anpassung der Wartezeiten und der FPM-Reserve hat sich das
Verhalten deutlich beruhigt. Auch der Load Average ist wieder auf ein normales Niveau
zurückgegangen. Die Zahl der Slowlog-Ereignisse fiel ab dem 4. September massiv ab.
Der Slowlog ist deshalb inzwischen wieder deaktiviert.
Mein persönliches Fazit aus der Untersuchung geht inzwischen über die konkrete
Friendica-Instanz hinaus:
Eine föderierte Instanz muss nicht nur selbst stabil laufen. Sie muss auch so mit
langsamen, fehlerhaften oder zeitweise unerreichbaren Gegenstellen umgehen können,
dass deren Zustand die eigene Funktionsfähigkeit möglichst wenig beeinflusst.
Ich habe die Ergebnisse deshalb noch einmal ausführlicher in einem Fachartikel
zusammengefasst:
Föderation braucht Fehlertoleranz an den Instanzgrenzen
Dabei verzichte ich bewusst auf konkrete Grenzwerte oder eine allgemeine „Best-Practice-
Konfiguration“. Die Werte hängen zu stark von Instanzgröße, Nutzung, Federation-
Volumen und Systemumgebung ab. Entscheidend ist aus meiner Sicht nicht das Kopieren
einzelner Parameter, sondern das Verständnis der Zusammenhänge und die Messung auf
der eigenen Instanz.
