!Friendica Admins
Ich hatte heute im Vormittagsbereich unter:

1.) "Administration - Worker-Warteschlange inspizieren" plötzlich sehr viele Einträge. Auf dem Server mit htop konnte ich viele Prozesse "worker -- no_cron" erkennen.
Und unter
2.) "Administration - Verzögerte Worker-Warteschlange inspizieren" mehren sich Einträge mit dem Befehl "APDelivery" mit immer gleichen Hinweisen auf:
"wall-new: 213555: https://fedi.4x31.dev/users/id/inbox"
"wall-new: 217383: https://fire.mysteriousinsight.xyz/pub/shared_inbox"

Die unter 1.) genannten sehr vielen Einträge haben sich im Laufe von ca. 3 Stunden langsam wieder aufgelöst (während ich vergeblich versucht habe die Ursache mit Lösung zu finden). Während der sehr vielen Einträge stockte die Friendica-Instanz. Teilweise konnten wir nichts mehr unternehmen. Der Seitenaufruf endete zwischenzeitlich mit einem HTTP-Statuscode 503 (Der Server steht temporär nicht zur Verfügung).

Die unter 2.) genannten Einträge bestehen fort.

Für mich ist nun unergründlich, was das war und wie hier vorgebeugt werden kann.

Hinweis zu Versionen:
Friendica-Instanz Version: 2025.07-rc
Datenbankversion: 1584/1584
Post-Update-Version: 1550/1550

Friendica Admins hat dies geteilt.

Als Antwort auf Steffen 🦉🇪🇺

Die Medien in diesem Beitrag werden Besuchern nicht angezeigt. Um sie anzusehen, gehe bitte zum Originalbeitrag.

@Steffen 🦉🇪🇺 also zumindest was den Eintrag "wall-new: 217383: https://fire.mysteriousinsight.xyz/pub/shared_inbox" angeht, liegt es daran das der Server bzw. die Domain nicht mehr existiert oder es zumindest keinen DNS Eintrag dafür gibt.
Als Antwort auf OldKid ⁂

Die Subdomain fire.mysteriousinsight.xyz wird nicht aufgelöst und sie ist mir auf anderen Webservern bereits negativ aufgefallen. Jedoch die Domain mysteriousinsight.xyz ist auflösbar (72.60.178.9, 2a02:4780:41:f493::1).

Aber wieso kommt die Subdomain fire.mysteriousinsight.xyz in die "Verzögerte Worker-Warteschlange"? Und wie bekomme ich sie dort wieder raus? Diese Einträge werden immer mehr.

Gibt es überhaupt Möglichkeiten die Warteschlangen zu beeinflussen? Möglichst ohne in der Datenbank direkt operieren zu müssen?

Friendica Admins hat dies geteilt.

Als Antwort auf Michael 🇺🇦

In htop konnte ich viele "worker -- no_cron" Prozessen sehen, wobei jeder einzelne Prozess unterschiedliche Last erzeugte. Einige waren über 10% CPU Last. Das gab mir sehr zu denken.

Ich habe nun erstmal unter "Administration - Seite" - "Worker" - "Entkoppelter Empfänger" deaktiviert. Natürlich ohne genau zu wissen, ob das etwas nützt.

Friendica Admins hat dies geteilt.

Als Antwort auf Steffen 🦉🇪🇺

Wenn Du den entkoppelten Empfänger deaktivierst, verlagerst Du die Last vom Backend auf das Frontend. D.h. wenn Du viele eingehende Posts hast, kann es sehr schnell die Load des Systems massiv hochtreiben oder zu Timeouts führen, wenn Threads vervollständigt werden. Mit dem entkoppelten Empfänger wird die Last auf das Backend verteilt, was sich seine Zeit nehmen kann und was man besser skalieren kann.
Als Antwort auf Michael 🇺🇦

Danke für die Info. Demnach aktiviere ich "Entkoppelter Empfänger" wieder.
Gibt es in den Tiefen der Friendica-Konfiguration Möglichkeiten aufkommende Last besser auszugleichen? Ich würde zu gerne wissen, was an der vorübergehenden Last die Ursache war. Ich tappe ungern so im dunklen, wie in diesem Fall.

Ich habe zum Beispiel außerhalb von Friendica unter "Individuelle php.ini Einstellungen" in ISPConfig (verwaltet die Friendica-Instanz) auf Empfehlung folgendes eingetragen:
memory_limit = 512M
upload_max_filesize = 32M
post_max_size = 32M
max_execution_time = 180

Nachtrag:
Ich habe noch einiges in Erfahrung bringen können bezüglich meiner "Mängel-Beschreibung". Daraufhin habe ich folgende Anpassungen vorgenommen:
1.) in Frienica -> Administration - Seite -> Worker:
"Entkoppelter Empfänger" wieder aktiviert
"Worker Abrufbegrenzung" vorerst auf 3 eingestellt (eventuell später auf 4, 5 oder sogar 6)
2.) In ISPConfig unter der Friendica-Instanz (PHP-FPM-Einstellungen):
PHP-FPM FastCGI Prozess Manager: dynamic
PHP-FPM pm.max_children = 20
PHP-FPM pm.start_servers = 3
PHP-FPM pm.min_spare_servers = 2
PHP-FPM pm.max_spare_servers = 5
PHP-FPM pm.max_requests = 500

Jetzt muss ich warten und beobachten, ob sich gesamtheitlich diese Einstellungen positiv auswirken. Insgesamt sollten sie jedoch die Leistungsfähigkeit unserer Friendica-Instanz verbessern. Ich werde später hier berichten. Möglicherweise haben andere ähnliche Sorgen.

Friendica Admins hat dies geteilt.

Als Antwort auf Steffen 🦉🇪🇺

Es wäre ggf. gut, wenn Du externes Monitoring aktivieren würdest, das die typischen Systemmerkmale (Load, Hauptspeicherausnutzung, Zugriffe pro Zeiteinheit, ...) protokollieren würde. Das würde schon helfen zu erkennen, wo das System ggf. Hilfe benötigt.

Wo läuft bei Dir Friendica? 512 MB klingt nach extrem wenig.

Als Antwort auf Michael 🇺🇦

Was meinst du mit "externes Monitoring aktivieren"? Innerhalb Friendica? Ich nutze für alles bezüglich des gesamten Servers Monit und Munin. Im Einzelfall sehe ich dann im jeweiligen log und nutze meist htop.
Den Wert memory_limit habe ich bereits 1024M hoch gesetzt. Aber am memory_limit wird es nicht liegen. Es geht mehr um die Worker-Prozesse.
Friendica läuf auf einen unserer Webserver, die bei Hetzner stehen. Der Server selbst hat Debian 12 und ist erst vor 3 Monaten frisch installiert wurden. Die Hardware ist u.a. CPU = AMD Ryzen 5 3600 6-Core Processor und RAM = 64GB. Nach der Betriebssystem-Installation istallieren wir immer als erstes ISPConfig. Erst danach richten wir alles weitere ein. Auf genannten Server läuft aktuell nur Friendica und BigBlueButton. BigBlueButton wird nur von uns und eher selten genutzt.

Friendica Admins hat dies geteilt.

Als Antwort auf Steffen 🦉🇪🇺

Ich meinte so etwas wie Monit. Das hilft ja dabei zu erkennen, dass z.B. zu einem Zeitpunkt sehr viele externe Zugriffe hattest. Kann Monit JSON-Daten per HTTP abrufen? Friendica hat einen Statistik-Endpunkt, wo du dann sehr gut sehen kannst, wie viele Worker gerade ausgeführt werden, wie viele noch auf Ausführung warten, ...

Siehe dazu github.com/friendica/friendica…

Als Antwort auf Michael 🇺🇦

Danke für den Hinweis von stats. Das habe ich mal aktiviert und kann via Browser die Ergebnisse sehen und entsprechend werten. Monit kann keine JSON-Daten auswerten.

Was ich zu meiner Fehlerbeschreibung herausfinden konnte:
1.) Es sind zu viele Worker gleichzeitig gelaufen. Vermutlich sogar mehrfach die gleichen immer wieder. PHP-FPM/Apache hatte zu viele Prozesse, das Limit war erreicht.
2.) Ich hatte die vorkonfigurierten PHP-FPM Werte nicht entsprechend meiner Serverumgebung und der Friendica-Instanz angepasst.

Warum sich letztendlich das Ganze wieder von selbst auflösen konnte, habe ich bis jetzt nicht herausfinden können. Nur so viel: Ich hatte php8.4-fpm und apache2 neu gestartet.

Stand heute habe ich die gestrig beschriebenen Werte noch einmal fein-justiert:
Friendica:
Worker Abrufbegrenzung = 4
php.ini:
memory_limit = 1024M
upload_max_filesize = 32M
post_max_size = 32M
max_execution_time = 180
php-fpm:
PHP-FPM FastCGI Prozess Manager: dynamic
PHP-FPM pm.max_children = 20
PHP-FPM pm.start_servers = 4
PHP-FPM pm.min_spare_servers = 2
PHP-FPM pm.max_spare_servers = 6
PHP-FPM pm.max_requests = 500

Vorläufiges Ergebnis:
Aktuell läuft die Friendica-Instanz ziemlich flott. Und ich hoffe es bleibt so. Die Hauptursache waren die relativ falschen PHP-FPM Werte. Die beschriebenen Werte sind auf Grundlage der Serverhardware erarbeitet (CPU: AMD Ryzen 5 3600 6-Core Processor und RAM: 64GB).

Friendica Admins hat dies geteilt.

Als Antwort auf Michael 🇺🇦

Ich konnte letztendlich nachvollziehen, dass PHP-FPM/Apache zu viele Prozesse hatte, weil das Limit erreicht war. PHP-FPM konnte keine neuen Anfragen mehr bedienen. Somit spielen die PHP-FPM Werte eine Rolle.

Jetzt interessiert mich noch eine andere Sache:
Aktuell füllt sich immer noch die Verzögerte Worker-Warteschlange weiter. Und das betrifft immer die gleichen Domains / Subdomains.
1.) fire.mysteriousinsight.xyz
2.) fedi.4x31.dev

Ich habe beide erstmal auf die Blockliste gesetzt. Weiterhin haben wir 2 Kontakte gefunden, die von diesen Domains kommen. Wenn wir den Umstand ignorieren, weil unsere Instanz zügig läuft, wird dennoch die Verzögerte Worker-Warteschlange immer voller und irgendwann unübersichtlich. Dem sollten wir vorbauen.

Ich konnte dazu folgende Vorgehensweise finden, die jedoch nicht wirklich funktionieren:
php bin/console.php worker purge-delivery
php bin/console.php worker restart
oder härter die einzelne ID:
php bin/console.php worker delete <job-id>
Das scheint aus früheren Versionen zu sein.
Gibt es Methoden, die diesbezüglich funktionieren?

Friendica Admins hat dies geteilt.