Skip to main content


Hallo !Friendica Support ich habe seit Montagabend das Problem, dass mein System im Speziellen die CPU auf Anschlag läuft. Im Verdacht habe ich den Worker.
Wurde in diesem Bereich etwas geändert?
Verwendete Version:
Friendica 'Giant Rhubarb' 2022.09-dev - 1474

Auf welche Stichwörter soll/kann ich im Friendica-Log (Info) mal suchen?
@Friendica Support
Hmm, auch @Tobias hatte ja berichtet, dass seine Maschine auf Anschlag läuft. Seltsamerweise zeigt meine Kiste das gegenteilige Verhalten. D.h. seit ein paar Tagen ist die Load massiv runtergegangen.

Schaue bitte per top oder htop welche Prozesse wie viel Last erzeugen und wie Deine Load im Allgemeinen ist. (Bei mir ist die Load derzeit um 1 und die CPUs laufen so zwischen 10 und 40%)
@Michael Vogel@Tobias
Hier mal der Load- und CPU-Verlauf der letzten sieben Tage. MAn sieht sehr schön wann das Problem losging:

281080


281082


Aktuell verursachen laut htop zwei von drei laufende Workerprozess so um die 80 Prozent CPU-Last.
@Michael Vogel@Tobias
P.S.: Ich sehe auch gerade, dass vermutlich wegen dieses Problems bei weiten noch nicht alle von mir erstellten Antworten mit weiteren hinweisen hier an das @Friendica Support übertragen wurden.
@Michael Vogel@Tobias@Tuxi (Friendica) 🐧 ✅ Bei mir ist seit der Aktualisierung von #PHP auf #7.4 der Load teils ueber 40.0 gestiegen. Ich musste ein Cron-Job-Script schreiben, dass alle 5 Minuten schaut, wie hoch der Load ist und dann den #FPM einfach mit killall -KILL php7.4-fpm rauswirft.
@Roland Häder@Michael Vogel@Tobias
Ich bin schon seit "ewigen" Zeiten auf 7.4. Bis Montagabend gab es nie Probleme damit.
Ich gehe stark davon aus, dass meine Programmierung Schuld ist. Ich muss es halt "nur" finden und beheben.
@Michael Vogel bei mir ist es meistens der worker, gelegendlich schiebt sich dann die mariadb davor, aber das war selten der Fall.
@Tobias@Michael Vogel Den habe ich mit renice 19 $(pidof php) "netter" gemacht, damit ist er etwas langsamer, dafuer aber bremst er nicht FPM und auch nicht die MariaDB aus.
Das ganze führt dann dazu, dass anscheinend der Workerprozess selber nicht (mehr) arbeitet denn nach einer Weile erscheint im Backend folgender Hinweis:
Der Hintergrundprozess (worker) wurde zuletzt um 2022-07-27 05:50:16 UTC ausgeführt. Das war vor mehr als einer Stunde. Bitte überprüfe deine crontab-Einstellungen.

Nachrichten-Warteschlangen
1144 - 2064

Die Workerprozesse laufen für meinen Geschmack auch deutlich zu lange?
Mäh ...
Ich muss hier noch mein System in einen stabilen Zustand bringen und erstelle dann einen PR dafür.
@Tuxi (Friendica) 🐧 ✅ Mach mal ein renice 19 $(pidof php), dann sollten die wenigstens dein System nicht ausbremsen. Hier haben die selten so lange gebraucht, die Warteschlange abzuarbeiten.
@Roland Häder
Direkt auf der Konsole ausführen?
Was macht dieser Befehl?
@Tuxi (Friendica) 🐧 ✅ Dieser bewirkt, wie ich schon schrieb, dass die PHP-Prozesse mit niedrigster Prioritaet (Leerlauf) ausgefuehrt werden. Sie werden noch ausgefuehrt! Schliesslich klappt es ja auch hier.
Weiterer Hinweis: Im Error Log vom MySQL habe ich solche Einträge gefunden:
Aborted connection 73 to db: 'dbname' user: 'username' host: 'localhost' (Got an error reading communication packets)
Okay ich habe gerade gesehen, dass dieser Error-Eintrag kommt, wenn ich über htop einen Workerprozess kille.
@Tuxi (Friendica) 🐧 ✅ I don't know if it can be helpful, but recently we have a similar load problem every 2 weeks. We solve the problem in this way:
- stop worker
- put friendica in maintenance mode
- restart mariadb
- optimize friendica db
- switch off maintenance mode
- start worker
@Luca Nucifora
What do you mean by "optimize friendica db"?
@Tuxi (Friendica) 🐧 ✅ with 'mysqloptimize' or 'mysqlcheck -o' .. in our instance the 'contact' table is the most problematic, but I prefer to optimize all the tables
@Tuxi (Friendica) 🐧 ✅@Luca Nucifora E.g. #adminer allows to select all tables and then choose "Optimize" which removes junk data from the database's file.
@Michael Vogel
Hier sieht man schön einen Vergleich der Load und CPU. Ab 09:00 habe ich damit begonnen, Workerprozesse die ca. 70 Prozent Last verursachen manuell zu killen.
Die Prozess-Id der PHP-Prozesse steht auch im Log. D.h. wenn Du das Log auf "Debug" setzt und dann schaust, welcher PHP-Prozess so richtig austickt, kannst Du im Log sehen, was das System gemacht hat.
@Tuxi (Friendica) 🐧 ✅ No offense taken, but long posts can be a problem e.g. #fedilab does not truncate such posts resulting in frustrating scrolling required in users timeline to move to next post.
@Roland Häder@Michael Vogel
Japp hab ich jetzt gemacht.... Sorry nochmal. Bin gewohnt das bei mir im Browser solch lange Sachen autom. zusammengeklappt werden. Habe dabei allerdings nicht die App-User bedacht.
@Tuxi (Friendica) 🐧 ✅@Michael Vogel@Roland Häder Es gibt immer irgendwelche Cases, wo das Verhalten (warum auch immer) anders ist. Am besten gar nicht solche Annahmen machen und auf Nummer sicher gehen.
@Tuxi (Friendica) 🐧 ✅ Uhrm, der paste war jetzt wirklich unnötig lang... und ist immernoch hier drinn, kannste den nicht mal bitte rausnehmen? ;)
@hackbyte (friendica)
Nö den hab ich gestern (Nachmittag?) noch gelöscht. 🤔
@Michael Vogel
Ohaaaa..... Ich habe gerade ein tail -f kombiniert mit einem grep auf eine der Amoklaufenden Workerprozess-ID gemacht. Da überschlägt sich ja das Log. Hier mal ein Auszug --> https://bin.disroot.org/?c29e176f4b087ad3#2xzGgW9c8nLt6AUwMc3kX1RcwsNW7xBg5SHDFTw4Xu6y
Uberspace hat mir gerade eine eMail mit ähnlichen Screenshots geschickt, also auch bei mir sehr hohe MySql Last ...
Ich bin jetzt auf den commit zurück gewechselt, bevor der PullRequest von @Michael Vogel gemerged wurde. Einfach, damit die Instanz wieder nutzbar ist.

git checkout 37c3a92d2cb6bc2bd9632a8d5bf2ace371dbb89a

Im Friendica Verzeichnis. Wenn Michael da neue Ideen zum Testen hat, werde ich die dann auch austesten.
@Tobias@Michael Vogel Oh, das ist aber detached dann. Wenn ich solch einen Fall habe, dann mache ich meistens eher ein git reset --hard <commit-id> und bleibe somit auf dem Zweig verbunden, nur halt auf einen aelteren Commit.
@Tobias@Michael Vogel
Reicht da ein git checkout 37c3a92d2cb6bc2bd9632a8d5bf2ace371dbb89a auf der Konsole aus oder muss man da auch noch was anderes machen?
This entry was edited (2 years ago)
@Tuxi (Friendica) 🐧 ✅ das reicht aus, oder du machst halt das git reset --hard 37c3a92d2cb6bc2bd9632a8d5bf2ace371dbb89a was Roland vorgeschlagen hatte.
@Tobias@Tuxi (Friendica) 🐧 ✅ 3. Alternative: An Tobias' Varriante -b temp anhaengen. Damit wird eine Branch temp mit dem Stand vom Kommit 37c3a92d2cb6bc2bd9632a8d5bf2ace371dbb89a erzeugt. Wenn spaeter der Fehler auf develop oder wo du auch drauf bist (ich wuerde eine geziehlte Version empfehlen, stable koennte auch klappen) behoben, kannst du mit git checkout develop (oder auf welche Branch auch immer!) du wieder zurueckwechseln. Bitte vergesse die noetigen Schritte wie ./bin/composer.phar install --no-dev && ./bin/console dbstructure update && ./bin/console postupdate, sowie das Neustarten des Workers nicht. 😀
@Tobias@Roland Häder
Welches Vorgehen ist besser? Und ich zerschieße mir da nichts?
@Tuxi (Friendica) 🐧 ✅@Tobias Solange du Backups machst und es keine Datenbank-Updates gab (keine Downgrades der Datenbank moeglich), sollte es eigentlich klappen.
Ich hab eine Menge out of memory Fehler. PHP-FPM darf 256MB pro Prozess nutzen, versucht aber ständig mehr anzufordern. Ansonsten läuft aber alles.
@Steffen K9 🐰@Tuxi (Friendica) 🐧 ✅ Oh, 256MB ueberschritten, das ist sehr viel. Kannst du festellen, wo das FPM-Prozesskind (ja, deutsch!) gestorben ist? Oh, es klingt so "falsch"! Aber kein #Denglisch ... 😉
Das Problem tritt aktuell nicht mehr auf. War wahrscheinlich vom Loop verursacht. Jetzt habe ich nur noch 10k queries per second auf der Datenbank. 😀
@Tuxi (Friendica) 🐧 ✅ Hast du mal die neusten Aenderungen probiert? Dort hat @Michael Vogel einen Fix fuer die hohe CPU-Last eingebaut.
@Roland Häder@Michael Vogel
Ach kam gestern noch was? Gleich mal sehen.....
@Michael Vogel damit ist es wieder erträglich geworden, aber weit entfernt vom Zustand vor dieser Änderung. Davor lief der RasPi hier so auf einer LOAD von 1 bei vier Kernen, meist etwas drüber. Jetzt läuft er zwischen 3 und 4, eher im oberen Bereich. Um den Netzwerk-Stream aufzubauen braucht es jetzt etwa drei mal so lange wie vorher.

Klar ist jetzt nur eine Momentaufnahme, aber die Worker-Queue ist so gut wie leer ( 13 - 8 ). Aber bitte sag mir das es wieder besser wird, oder es eine versteckte Option gibt mit der ich das regeln kann 😉

Das ist echt schräg. Auf meiner Kiste sieht es wie folgt aus:

Die Load schwankt in der Regel so zwischen 1,5 und 3 und die Kerne liegen recht häufig im einstelligen Bereich.

Kannst Du per htop, iotop und Co. schauen, wo das System langsam ist?

@Michael Vogel@Tobias
Hier bei mir schaut es Stand jetzt so aus:
281587

Und wenn überhaupt, wird die Warteschlange extremst langsam abgebaut.
Spannenderweise sollte das System eigentlich jetzt auch die Datenbank entlasten.
Vielleicht muss mein System jetzt auch einfach noch ein bisschen nachholen aus den letzten zwei Tagen @Michael Vogel? Nur, dass halt keine Queue aufgebaut ist über die Zeit...

Was ich sehe sind PHP8 Prozesse und die MariaDB die sich in h/top abwechseln und die die Spitzenplätze einnehmen. Wenn ich mit mytop rein schaue, werden immer nur ein, zwei aktuelle Befehle angezeigt, da scheint nichts lang laufendes zu sein.

Eigentlich hatte ich das System mal so eingestellt, dass nichts an neuen Accounts gesucht werden soll und auch keine Threads Vervollständigt werden sollen. Oder Threads importiert werden sollen auf die Kontakte reagiert haben. Wird halt jetzt trotzdem gemacht und verschwendet System Ressourcen. Das mag auf Knoten sinnvoll sein, auf denen Menschen in der Gemeinschaftsseite stöbern um in der globalen Timeline zu sehen was es noch so interessantes gibt, aber die globale Timeline ist bei mir auf dem Familien-Knoten deaktiviert.
@Michael Vogel so, das System hat sich ein bisschen weiter beruhigt, war also wohl was nachzuholen. Die qps in mytop ist deutlich geringer geworden, da werden also vorhin sehr viele (relativ gesprochen und auf das System bezogen) Queries durch die Datenbank gejagt worden sein.
Jupp, bei den Spikes die die Last auf 150% hoch treiben werden 60 mal mehr Queries verarbeitet als wenn die Last "unten" ist.
@Michael Vogel System is running hot again... and the worker is getting terminated by the system.
Hast Du die neuen Einstellungen zum Decoupling und der Rekursionstiefe ausprobiert?
D.h. er respektiert nicht mehr die Einstellungen zur Vervollständigung?
@Michael Vogel die Unterhaltungen auf die von Kontakten reagiert wird, werden mir nicht im Netzwerk-Stream angezeigt, aber landen auf der Gemeinschaftsseite (wenn ich die mal einschalte). Nur die öffentlichen Beiträge natürlich.

Du hattest mir mal gesagt, das geht im Moment nicht anders und dafür sollte die Zeit nach der nicht erwünschte Nachrichten gelöscht werden sollen auf 1 gesetzt werden, s.d. die wenigstens nach einem Tag wieder gelöscht werden.
Ah okay. Ja, das geht nicht anders, da wir beim Empfang zunächst die Nachrichten empfangen und später unterverteilen. Und da können unterschiedliche Leute unterschiedliche Einstellungen haben.
Es wäre aber in der Programmierung schwieriger und fehlerträchtiger, diese Prüfung an mehreren Stellen zu haben, das ist das Problem.
@Michael Vogel@Roland Häder
Habe vor ca. 30 Minuten ein git pull gemacht. Werde das System weiter beobachten und berichten. Jetzt läuft für das erste der Worker voll nachdem seit gestern Abend ~ 21:00 keiner mehr gelaufen ist.
Die neue Lösung geht mehr auf die Worker - aber dadurch sollte sich die Last besser verteilen. Und es gab eine Stelle mit einer Endlosschleife.
@Michael Vogel
Was mir eben auffällt, dass auch mein Platte voll läuft. Von gestern Morgen auf heute Morgen um gut 20 GB. Das ist untypisch.
Was belegt den Platz?
@Michael Vogel
Nachtrag: Nachdem ich die Workerprozesse, MySQL und PHP-FPM neu gestartet hatte wurde ~25 GB Plattenplatz freigegeben.
@Michael Vogel
Anscheinend hat das Update keine Lösung des Problems gebracht:
281533

Die CPU-Last steigt wieder allerdings scheint der Load nicht zu steigen. 🤔
Auch wird die Warteschlange (aktuell gut 2500) noch abgebaut.

Die rot eingezeichnete Linie ist der Zeitpunkt, an dem ich das Update gemacht habe und danach MySQL und PHP-FPM neu gestartet habe.
Die gelb eingezeichnete Linie war heute Morgen der Neustart der Workerprozesse sowie MySQL und PHP-FPM.
Aus meiner Sicht sieht es gut aus. Davor war eine konstante Last zu sehen (was wahrscheinlich von der Endlosschleife kam). Jetzt ist das System zwar beschäftigt, man sieht aber, dass es "normale" Tätigkeiten sind, weil es Schwankungen gibt. vor allem sieht die Load recht gut aus, denke ich.
@Michael Vogel
Was meinst Du mit "normale Tätigkeiten"? Prozesse außerhalb vonFriendica?
Nö, normale Friendica-Tätigkeiten, aber eben keine Endlosschleifen.
@Michael Vogel
Was mir jetzt schon auffällt: Erstellte Beiträge von mir werden jetzt wesentlich schneller versendet. 👍
Also iwie ist die Warteschlange in den letzten 2,5 h von ca. 2500 auf gut 6500 angestiegen.
Kann das auf einmal so explodieren oder ist da etwas anderes im argen?
@Michael Vogel
Das Loglevel ist auf Notice.
Hier die Ausgabe von ca. 30 Sekunden Laufzeit
tail -f /var/log/friendica.log | grep Load:
--> https://bin.disroot.org/?6d997e1fc1759f07#HC31ymKC8qBxfm8rjQ8AQ1e1MuURzffhnPMr6TmWsfph

Ein tail -f /var/log/friendica.log | grep jpm bringt nach ca. 15 Minuten kein Ergebnis.
Setze mal diese Parameter in Deine Config-Datei:
        'worker_debug' => true,
        'worker_jpm' => true,
        'worker_jpm_range' => '1',

Außerdem suche mal im Logfile nach Fehlern:
cat friendica.log | grep ERROR.*"Uncaught Exception"
@Michael Vogel
Parameter habe ich gesetzt. Jetzt wird bei der Suche nach "jpm" was angezeigt:
https://bin.disroot.org/?93a01b2174c6b7b2#4kxNGCDm7fVVXGHykgn7Jo12PFV5w8mpvCJF9dB4Dcpq

Ein cat friendica.log | grep ERROR.*"Uncaught Exception" bringt ne Menge. Hier ein Auszug: https://bin.disroot.org/?b67de8425308dd7a#2dG34fHLuuzcMNWgDA7CE3BnLoAHidjheVgtJahW9ki8

Sorry aber das sind für mich böhmische Dorfer....
Die "Uncaught Exception" sind alles fatale Fehler, die wir angehen müssen. D.h. es wäre klasse, wenn Du jeden einzelnen Eintrag einzeln unter https://github.com/friendica/friendica/issues/11630 berichten könntest. (Soweit ich das sehe, sind das nur zwei unterschiedliche Fehler).

Die Worker-Zeilen sehen an sich gut aus. Das einzige ist, dass Du irre viele Einträge mit niedriger Prio hast. Aber ansonsten arbeitet Dein System alles recht gut ab.
@Michael Vogel@Tuxi (Friendica) 🐧 ✅Contact::getDefaultAvatar()'s erster Parameter ist in der Tat ein Datenfeld. Gucke dir z.B. die Zeile mit if (!empty($contact['id'])) { an. Dort wird $contact als Datenfeld verwendet.
Hallo @Michael Vogel 👋
Die Warteschlange hat sich zum Glück über Nacht abgebaut:
Nachrichten-Warteschlangen 2228 - 17

Habe eben auch ein "git pull" gemacht um die aktuellsten Änderungen zu haben. Die Worker verbrauchen immer noch extrem viel CPU:

281808


Kann ich das mit der niedrigen Prio irgendwie beeinflussen?

Die "Uncaught Exception" werde ich jetzt mal ein paar Minuten tailen und dann in dem von Dir angegebenen Ticket berichten.
Es gibt die neue Admin-Einrichtung "Generate counts per contact group when calculating network count" unter "Performance". Wenn das deaktiviert wird, wirst Du die beiden oberen Queries nicht mehr sehen.

Die anderen sehen sauber aus. Alle Queries, die praktisch keine Laufzeit haben (Spalte "Time") sind völlig okay.
@Michael Vogel
Danke Michael. Habe es jetzt mal deaktiviert. Werde weiter beobachten und berichten, ob es bzgl. der hohen CPU-Auslastung was gebracht hat.
@Tuxi (Friendica) 🐧 ✅@Michael Vogel Bitte probiere mal die Worker-Threads mit renice 19 $(pidof php) "netter" zu machen, dann sollten diese weniger CPU-Zyklen verbrauchen und somit mehr fuer den Webserver und die Datenbank frei werden, was wichtiger ist (Frontend lahmt sonst). Hat keine Nebenwirkungen! 😀
Mit dem PR https://github.com/friendica/friendica/pull/11790 kommen zwei neue Konfigurationen ins Spiel. Da kann man dann entweder das direkte Verarbeiten aktivieren oder deaktivieren. Und man kann die maximale Rekursionstiefe definieren. Dies könnte einen Einfluss auf die Performance des Systems haben, aber ich wage nicht zu prophezeien, welche Parameter in welche Richtung welchen Einfluss haben werden.
Mir hat das Update heute Früh den Server lahmgelegt...
Am Abend hab ich erneut ein Update gemacht, dann hat sich friendica wieder beruhigt.
Danke für den Fix!!
Der JPM-Wert von 0 deutet offensichtlich auf Probleme hin. Bitte schaue, ob Du Fehler im Log hast (siehe mein diesbezüglicher Post)
@Michael Vogel
Meinst Du "Uncaught Exception" ?
Wenn ja, dann läuft schon der ganze Abend ein "tail -f" drauf ohne Treffer.
Dann schau nach, ob es lang laufende Prozesse, die sich ggf. auch viel Prozessorzeit schnappen oder ob das alles nur extrem kurz laufende Scripte sind. So oder so merke Dir die Prozessid und suche danach im Log. Das System sollte Dir darstellen, was das System da macht.
Die Meldung an sich ist nicht das Problem. Aber augenscheinlich ist der Umgang damit das Problem. Schau mal, ob das mit https://github.com/friendica/friendica/pull/11802 gelöst ist.
@Michael Vogel
Bin seit fünf Minuten auf den aktuellsten Dev-Stand. Mal sehen.
@Tuxi (Friendica) 🐧 ✅
Vielleicht wäre es einfacher wenn du für ein Produktivsystem immer die letzte final nutzt und nur fürs Testsystem ein Dev ?🤔
@Michael Vogel
@7homas ♓@Michael Vogel
Hatte in den letzten Jahren nie ein Problem mit einer DEV. Aber ja es liegt in der Natur der Dinge, dass es ein Risiko ist.
Und so wie es bis jetzt aussieht, ist das System nutzbar. Es hat sich zumindest bis jetzt kein User beschwert.
@Tuxi (Friendica) 🐧 ✅
OK ... Das war nur ein Gedanke - spreche da ja aus Erfahrung als Programmierer... Ich habe da immer 3 Instanzen am laufen.
Ein Final und Produktivsystem
Ein PreFinal zum testen bevor es ins Final geht
Ein Entwicklungssystem (das schon öfters Mal nicht funktioniert)

Na wenn es wieder läuft dann ist gut 👍🏻
@Michael Vogel
Ich entwickle auf meinem Produktivsystem - und ja, das widerspricht allen Regeln, ist aber für mich eine gut funktionierende Lösung.
@Michael Vogel
Booooohhh 😱
Hatte ja mir das auch schon Mal gezogen und den Quellcode durchstöbert... Aber nachdem man schnell seinen Account "verbrennen" Kann waäe mir das zu heikel.
Mein Dev system hab ich normalerweise immer auf einem proxmox laufen im Heimnetz und das live dann auf einem Server im Internet. Hast du Erfahrung wie Friendica auf einer lokalen Docker Instanz auf dem Entwicklungsnotebook laufen würde?
@Tuxi (Friendica) 🐧 ✅
Nö, kein Stück. Bei Docker ist @Philipp Holzer der Experte, denke ich.
Ja. Eigentlich ist auch der develop-Branch in der Regel recht stabil. Allerdings gab es jetzt einige sehr massive Änderungen, die sich massiv auf die Stabilität ausgewirkt haben. Das ging so weit, dass ich mein eigenes System für ein paar Wochen nicht aktualisiert habe. Ich hoffe, dass diese Phase jetzt vorbei ist und wir wieder in stabile Fahrwasser geraten.

BTW: Die Verlagerung der Verarbeitung eingehender Nachrichten in das Backend hat wohl erst dazu geführt, dass wir Dinge wie diese Endlosschleifen überhaupt entdecken konnten. Frontend-Prozesse haben in der Regel maximale Laufzeiten, also werden diese z.B. nach 2 Minuten automatisch beendet. Da fällt es nicht auf, wenn das System sich zwei Minuten lang um sich selber dreht - im Hintergrund schon.
@Michael Vogel@Tuxi (Friendica) 🐧 ✅
Ja aber ich denke dennoch ist so ein Dev mit Vorsicht zu nehmen. OK wenn du das als git nimmst kannst du Zurückrollen aber ...nun ja widerspricht wohl meiner Ansicht von Software 😊
@Michael Vogel@Roland Häder
Weder ein renice 19 $(pidof php) noch ein Updaten auf die neueste Version haben eine Lösung gebracht. Nach wie vor 100 % CPU und eine Load von ~12
Spannend...

Bei brachte schon das update gestern Abend DIE Erleichterung... der Server war zeitweise davor ganz außer Gefecht...
Hast Du die alten PHP-Prozesse gekillt?

Hier sieht echt alles gut aus:
Ich hab jetzt den worker daemon neu gestartet und auf einmal über 1000 einträge in der warteschlange gehabt.
Die wurden dann aber sauber in wenigen minuten bis runter auf 0 abgearbeitet.
Habe das System gestern nach der Optimierung und einem git pull bewusst stehen lassen.
Die CPU-Last waren stundenlang bei 100 Prozent und die Load bei ca. 27. Heute Morgen war dann die übliche Meldung im Backend, das seit xx🤐x kein Worker mehr gelaufen ist.

Habe eben um 08:55 ein erneutes git pull ausgeführt um wirklich auf dem neuesten Stand zu sein und das System neu gestartet. Nach dem Neustart dauerte es nur ein paar Minuten bis die CPU wieder knapp bei 100 Prozent war, nachdem die Worker losgelaufen sind. Aktuell ist die Load bei ~6 und die Warteschlange bei 2222 - 1451

Werde die Kiste jetzt einfach mal laufen lassen....
Aktueller Stand nach 7 Stunden: Konstant eine CPU-Last von 100 Prozent und eine Load von 20. Ebenfalls ist die Auslieferung von neuen Beiträgen massiv (> 1 Std.) verzögert.
Auch ist die Ladezeit der Seite zähflüssiger.
This entry was edited (2 years ago)
Ich teste seit heute Morgen den Workaround, alle 30 Minuten mit killall php die Workerprozesse neu zu starten. So bleibt anscheinend die Load in einem einigermaßen akzeptablen Bereich. Mal sehen....
Kann man in den php-settings nicht langlaufenden prozessen eine maximale Lebensdauer mitgeben?
Ich bin dabei, ein paar Workarounds zu erstellen.
@Tuxi (Friendica) 🐧 ✅
kannst du nicht die PHP Prozesse begrenzen und auch den Speicherverbrauch?
Dann würde der Server wenigstens nicht mehr "am Rad drehen"
@7homas ♓
Dann würden die Prozesse aber nicht neu starten, sondern in einer ewigen Schleife laufen.
PR ist erstellt: https://github.com/friendica/friendica/pull/11809

Ich weiß nicht, ob er das Problem beseitigt, ich hoffe es aber.
Danke @Michael Vogel für deinen unermüdlichen Einsatz. 👍 🍺
@Michael Vogel
P.S.: Dummer Frage: sobald der Status "Merged" ist, ist der Fix verfügbar, oder?
@Tuxi (Friendica) 🐧 ✅@Michael Vogel Ja, richtig. Dann folgst du "bleeding-edge", also die all zu neuen Entwicklungen. 😀
Mein Server läuft jetzt zwar nicht mehr heiß, aber dafür sieht die Wörner Warteschlange jetzt so aus und sie wächst weiter ...

Nachrichten-Warteschlangen
51 - 59082
@Montag@Michael Vogel
Nachdem ich gestern das Update gezogen habe, kamen auf einmal zigtausend Nachrichten in die Warteschlange, die auch heute Nacht abgearbeitet wurden.
Was die CPU-LAst betrifft, kann ich heute keine Besserung feststellen immer noch so zwischen 95 und 100 Prozent. Allerdings scheint die Load "akzeptabler" zu sein bei ~10. Allerdings immer noch nicht das gleiche Niveau wie vor der Änderung.
Die Oberfläche scheint jetzt nicht mehr so zäh zu sein.

Sagt mal, kann man diese Loops, von denen ihr sprecht, in den Logs erkennen?
Jetzt sind es 70.000 ...
Bist Du auf dem letzten Stand? Läuft Dein System auf 100%? Wenn ja, ist wichtig zu wissen, ob die Last von einem Worker kommt. Und wenn ja, ist zu schauen, was dieser Worker macht. D.h. in der Logdatei muss man schauen, was da zu dieser Prozess-Id steht.
Moin @Michael Vogel, bin auf dem letzten Stand, alles andere schaue ich mir heute Abend an.
Die ContactDiscovery wurde nicht geändert. Die kann nicht die Ursache sein.
Ich werde einfach mal etwas abwarten. Ich habe den Eindruck, dass die Worker-Warteschlange jetzt auch ganz langsam wieder abgebaut wird.

Der jpm Wert im friendica.log liegt heute Abend auch deutlich höher als gestern. Keine Ahnung, ob sich da jetzt was beruhigt hat, aber meine Seite läuft und Uberspace beschwert sich auch nicht mehr bei mir dass ich zu viele Ressourcen verbrauche. 😉

Die durchschnittliche Load ist heute auch deutlich niedriger als gestern, wobei ich ehrlich gesagt nicht genau weiß, was mir der Wert Load: 2.67/20 aus dem Friendica Log sagen soll, ob das viel oder wenig ist.
Aus meiner Sich ist eine Load um die 2 ein vernünftiger Wert. Pirati.ca hat lange mit einer Load um 7 stabil gewerkelt. Ich liege im Moment auch etwa zwischen 2 und 3.
Find ich spannend, dass blockierungen solche Effekte auslösen.
Hallo @Michael Vogel ich habe im Backend wieder diese Meldung bekommen:
285977

Im htop schaut das ganze folgendermaßen aus:
285979

Und hier die Entwicklung er Systemauslastung:
285981


Hier sind die Logs zu den ersten drei Prozess-IDs aus dem htop Screenshot:
https://upload.disroot.org/r/gSegG4xz#RSwKYTncbeix/yOhy5Nl1jQDntfyOtMfNDqdXPWvKfQ=

https://upload.disroot.org/r/5MkhkEFE#ppGhN/U4YK/MhhNdZ6/TIgqbTO6o3Or8+eC1/wt6DwU=

https://upload.disroot.org/r/pE6WSghg#CJu3xl2mK4H6hF9PzW2iKS1MSqvMVSQWxOSduOAwHeY=

Softwarestand ist der von heute Morgen 07:30

Wenn Du weitere Infos brauchst gerne melden. Ich starte jetzt mal nichts neu und warte bis morgen früh.
@Michael Vogel
Hinweis: Der obige Kommentar mit den Screenshots und den Logs ist vor 10 Stunden erstellt worden und wurde bis jetzt nicht abgesendet. Habe jetzt sämtliche PHP-Prozesse, MySQL neu gestartet und ein git pull ausgeführt.
Hier der Zustand der Maschine von den letzten 24h:
@Michael Vogel
Irgendwie habe ich als Laie den Verdacht, dass es mit diesen massenhaften Einträgen zu tun hat?
[NOTICE]: item parent was not found - ignoring item
Die gesamte Zeile wäre wichtig.
@Michael Vogel
Das ist der letzte Eintrag aus dem952435er log:
2022-08-02T20:00:26Z worker [NOTICE]: item parent was not found - ignoring item {"thr-parent-id":10381066,"uid":97,"worker_id":"68dcc88","worker_cmd":"Notifier"} - {"file":"Item.php","line":709,"function":"getTopLevelParent","uid":"f40d83","process_id":952435}
Oookay, der ist spannend. Den Notifier hätte ich jetzt nicht in Verdacht.
@Michael Vogel
Und die drei anderen Logs die ich oben "angehängt" habe, haben ähnlich Einträge.
Wichtig in dem Zusammenhang ist der Wert bei worker_cmd.
@Michael Vogel
Wie man im Log sieht, gibt es über 22500Zeilen mit diesen Einträgen "worker_cmd":"Notifier".
Ich lass jetzt mal ein tail -f auf "worker_cmd":"Notifier" mitlaufen. Einen Treffer hatte ich bereits kurz nach dem Start.
Der Notifier ist für die Auslieferung von Beiträgen zuständig. D.h. Du wirst ihn sehr häufig sehen. Die Frage ist, welche Worker-Kommandos Du zusammen mit der Meldung "item parent was not found" findest.

Und ja, die Ursache des Problems ist augenscheinlich gut versteckt.
@Michael Vogel
Mache ein tail -f /var/log/friendica.log | grep "item parent was not found" | grep "Notifier"
Die Frage ist, welche Worker-Kommandos Du zusammen mit der Meldung "item parent was not found" findest.
Verstehe nicht ganz. Was meinst Du mit Worker-Kommandos? Auf was muss ich genau achten?
Ich meinte den Wert hinter "worker_cmd". Die Meldung mit dem Parent wird von verschiedenen Seiten ausgelöst.
@Michael Vogel
Wie gesagt, bei dem 35er Log ist es massenhaft ein "worker_cmd":"Notifier"
Bei dem 60er ein "worker_cmd":"ProcessQueue"
Und bei dem 93er ein "worker_cmd":"ProcessReplyByUri"
Wie gesagt, das lässt sich in den drei Logs oben schön erkennen.
Okay, das Notifier-Dingens sehe ich hier auch. Ich schaue dann mal heute Abend, ob das kritisch ist.
Hi @Michael Vogel, nachdem ich vor ein paar Minuten erneut die gelbe Warnmeldung im Backend bekommen habe, dachte ich mir, dass für Dich eventuell die Ausgabe von einem cat /var/log/friendica.log | grep "item parent was not found" | grep "worker_cmd" interessant sein könnte? Achtung sehr groß. 😉

Hier das Ergebnis:
https://upload.disroot.org/r/vEZwCnHM#JGvAMW/tC0Z4HNB4ft9UrUqvsAvIoi/FHzl9Q4zDkWg=
Mein System scheint sich beruhigt zu haben, von gestern 70.000 Einträgen in der Worker Warteschlange sind "nur" noch 25.000 übrig und die werden auch langsam abgebaut.
@Montag
Und wie schaut es mit der Last aus? Also CPU und Load?
Moderat, es gibt ein paar kurzzeitige spitzen, aber alles offensichtlich im grünen Bereich (Uberspace schreibt mich zumindest nicht mehr an, dass ich zu viele Ressourcen verbrauche).
@Montag
Hast Du Zugriff auf die Konsole und kannst mal für längere Zeit ein htop ausführen?
Ja, allerdings erst wieder heute Abend.
Hm, hat sich leider doch nicht beruhigt, es gab wieder eine eMail von Uberspace dass ich zu viele Ressourcen brauche ... Es wurden zu viele mysql Abfragen gleichzeitig gestartet und haben den Host komplett ausgelastet ...

Zumindest die Nachrichtenwarteschlange ist jetzt wieder bei deutlich unter 100.
@Montag
Hier eskaliert es auch gerade:
Ich habe meine Instanz jetzt erst mal in den Wartungsmodus geschaltet, den worker aus der crontab genommen und in der local.config.php einige Werte massiv verringert. Irgendwie ist das ziemlich der Wurm drinnen.
Ich arbeite mit dem workerdaemon... bin auch am aktuellen devel, und habe keine dieser Probleme.

Nur Dienstags wars arg.

Vielleicht probiert ihr den mal, statt worker aus der crontab...
Ich gehe mittlerweile davon aus, dass es immer dann besonders intensiv ist, wenn es sich um eine Instanz handelt, wo eingestellt ist, dass nur Posts von Leuten angezeigt werden, die die Person auch abonniert hat. Das ist insofern schräg, da es eigentlich nichts ausmachen sollte - aber ich habe dennoch das Gefühl. Es gibt eine neue Konfiguration, mit der man das holen fehlender Beiträge komplett deaktivieren kann. Das sollte all den Instanzen helfen, die derzeit gar nicht laufen.

Man muss dazu 'fetch_parents' => false, in der Config-Datei setzen.
Danke @Michael Vogel, habe das jetzt mal in meiner Config aktiviert.
@Michael Vogel
Habe jetzt so um die 10000 Einträge in der Warteschlange. Werde diese jetzt mal abarbeiten lassen und dann sehen wie es sich entwickelt.
Wie stelle ich sowas für eine Instanz ein, dass nur posts von abonnierten usern geholt werden sollen?
@Jakob :friendica:@Michael Vogel
Ich meine das es dies als Systemeinstellung für eine ganze Instanz nicht gibt. So eine ähnliche Einstellung gibt es, glaube ich zumindest, in den Einstellungen eines Users selber.
Aber ich bin mir da überhaupt nicht sicher.... 🤔
@Michael Vogel
Du meinst diese Einstellunge, oder?
286857


Werde die jetzt mal testweise deaktivieren....
Jepp, die meinte ich. Im Moment stochere ich ein wenig im Nebel, füge Log.Meldungen hinzu, teste Sachen aus, ...
@Michael Vogel
Hmmmm...... Also gefühlt hat die Änderung dieser Einstellung nichts gebracht. Allerdings ist der Load nicht so explodiert wie die Nacht davor, die CPU ist allerdings immer noch bei 97 Prozent im Schnitt.
Kann ich wieder auf die alte Einstellung von mir zurück oder soll ich diese für eine Analyse noch so lassen?
Ich hoffe, dass ich hier alle Daten habe und dass das, was ich gerade zusammenbaue, das Problem lösen wird.
@Michael Vogel
Okay, dann stell ich wieder um.
Ping mich einfach an, wenn ich hier updaten und dann testen kann. 😀
Sag mal @Michael Vogel hast Du gestern irgendwas gefixt? Habe gestern Nachmittag mein System aktualisiert. Seit dem ist die CPU-Last deutlich zurückgegangen. Zwar noch nicht auf dem gleichen Niveau wie vor dem Bug aber ich würde mal schätzen, dass sich die Last so um 40 - 50 Prozent reduziert hat.
Ich habe das gesamte Wochenende über daran rumgefeilt. Es ist gut zu sehen, dass es einen positiven Einfluss zu haben scheint.
Ich möchte nicht der Überbringer schlechter Nachrichten sein, aber bei mir ist die Last noch immer 4x so hoch wie vorher und bei 80-90% CPU Auslastung (12 Kerne). Ich habe immer noch diese mehrere Stunden laufenden Worker Prozesse, die die Last verursachen und die Datenbank mit 10k qps stressen - keine langsamen Queries, sondern einfach sehr, sehr viele.
Wie sind Deine Einstellungen für fetch_by_worker, decoupled_receiver, max_recursion_depth und fetch_parents?
- keine Ahnung, muss gucken
- false
- 30
- false
fetch_by_worker ist nicht konfiguriert, also vermutlich auf Default (false).
@Tuxi (Friendica) 🐧 ✅@Steffen K9 🐰 config.php oder local.config.php?
Habe in der local.config.php nur die database config und system
Du hast fetch_parents deaktiviert? Zumindest mit dem letzten Stand des Systems sollte das der ultimative Killswitch sein ...

Wenn die Last durch Worker verursacht wird, schau bitte nach, was diese ausführen. Das geht darüber, dass Du dir die Pid des jeweiligen Prozesses merkst und dann das Log nach dieser Pid durchsuchst.
Ja, habe ich deaktiviert nachdem du das eingeführt hast. Hab danach auch PHP CLI und FPM komplett neu gestartet. Ändert bei mir nichts.
Den Rest mache ich morgen. Müde. 😴
Ich habe jetzt diese Einstellungen:
		'fetch_by_worker' => true,
		'decoupled_receiver' => true,
		'max_recursion_depth' => 50,

Damit läuft mein System absolut entspannt.
Kann es sein, dass das ganze mit nginx und php-fpm besser rennt als mit apache?
Nö, das ist davon unabhängig.
Warum hatte ich die Probleme dann bloß an einem Tag? Und seither nicht mehr?
Es muss an irgendwelchen Einstellungen liegen, denn ich habe die Probleme auch nicht. Ich weiß aber nicht wirklich, welche Einstellungen das sein könnten.
@Michael Vogel
Habe das jetzt auch so übernommen und werde berichten. Sollten diese Einstellungen nicht mit einem Update gesetzt werden oder wie ist das?
Nö. Erst wenn es einigermaßen sicher ist, welche Einstellungen die besten sind, werden die die Voreinstellung.
Teste deine Config gerade. Scheint bei mir keinerlei Unterschied zu machen, was ich einstelle.
This entry was edited (2 years ago)
Diese Zeilen hier stammen alle von der lokalen Verteilung von Beiträgen. Wie Du sehen kannst, sind das immer unterschiedliche uri-id-Werte. Das hat also alles seine Richtigkeit hier.
Hmm, okay. Das ist ein Prozess der sich um die lokale Zustellung von auf dem System erstellten Beiträgen kümmert. Eventuell habe ich da einen Ansatz.
@Michael Vogel
Wenn Du weitere Infos brauchst, dann melde Dich. Habe jetzt erst mal alles neu gestartet. Die CPU geht trotzdem sofort wieder auf 100 Prozent.
@Michael Vogel
Habe jetzt wieder Prozesse die seit über 5h laufen. Seltsamerweise finde ich zu den IDs keinerlei Einträge im Log.
Was sind das für Prozesse? Worker oder welche aus dem Frontend?

Ich habe hier jetzt einen möglichen Fix für die Sache mit dem Notifier erstellt. Ich werde das über Nacht beobachten und dann einen PR erstellen.
@Michael Vogel
Das kann ich Dir leider nicht mehr sagen....
@Michael Vogel
Meine aber, dass es der worker -- no_cron war.
Aber ohne Pistole. 😉
Okay. Ich hoffe, dass https://github.com/friendica/friendica/pull/11847 hier Erleichterung bringen wird.
Kann es sein, dass ich diese Probleme nicht habe, weil ich den workerdaemon verwende?
warum hab ich die dann nicht?
@Michael Vogel
Habe vor ~ 4h das Update gemacht. Sage jetzt mal vorsichtig: Es schaut bis jetzt gut aus.
290645

Ich glaube man sieht deutlich wann ich das Update gemacht habe und die Worker neu gestartet habe. 😉

Mal den Langzeittest abwarten.

P.S.: Soll ich im Log auf irgendwelche Auffälligkeiten achten? Wenn ja auf was? Begriffe?
Okay, das beruhigt. Wenn Du neugierig bist, kannst Du im Log nach Logeinträgen aus der Funktion "storeForUserByUriId" achten. Da habe ich einiges umgebaut.
@Michael Vogel
okay ich taile dann mal mit nebenbei.
Hi @Michael Vogel hier mal die Ausbeute nach einer Stunde. Mir sagt das alles nichts aber vielleicht dir. --> https://paste.metaversum.wtf/?67129b23db07cb5c#BXJTA2FU4kWyVfNur7kyXyb7xshy7wxhTDUHbTBTJRD3
Sieht gut aus - schön kurz 😀
@Michael Vogel
Woran würde ich denn erkennen, dass es ein Fehler/Problem ist?
Wenn da auf einmal Massen von Einträgen wären und der Callstack sehr lang wird.
Bei mir sieht es auch besser aus. Die maximale Anzahl parallel laufender Worker habe ich auch wieder etwas hoch setzen können und die Konfigurationswerte max_processes_backend und max_processes_frontend habe ich auch wieder auf die Standartwerte gesetzt. Bis jetzt läuft es ohne Probleme.
So, nachdem die Nachrichten-Warteschlange vor einer Woche noch etwa 130.000 Einträge hatte, ist heute alles abgearbeitet. Im Zuge der Last-Probleme habe hatte ich einige Config-Werte massiv verringert, in der Hoffnung das Problem damit einigermaßen in den Griff zu bekommen. Diese Werte habe ich wieder zu den Urprungswerten geändert und es scheint alles problemlos zu funktionieren. 😀