friendica (DFRN) - Link zum Originalbeitrag

Hallo zusammen,
es ist wieder soweit - einmal im Monat poste ich den Serverstatus aus Transparenzgründen.

Die Sprünge im Ram sind Neustarts des Servers. Diese werden in der Regel nur Nachts und prophylaktisch vorgenommen. Bei Sicherheitskritischen Updates wie Firmware oder ähnlichem auch mal am Tag - Ein Neustart des Servers und aller Services dauert in der Regel 1-2 Minuten.

Wie Ihr am Ram sehen könnt, lief der Server fast den ganzen Monat stabil ohne Neustarts, außer am 09.07.2023.

Ab dem 31.07.2023 seht Ihr , das der Server ca. 2 mal am Tag neu gestartet wurde.

Dies hat einen Grund: Aktuell kämpfen wir vermutlich mit einem Bug in Friendica.

Es scheint einen Thread im Fediverse zu geben, der dafür sorgt, das sich die PHP-Prozesse in einer Endlosschleife aufhängen, bis der maximale Speicher von 3 Gigabyte pro Prozeess erreicht ist - danach wird dieser abgebrochen.

Das hört sich jetzt nicht dramatisch an, aber da bei uns bis zu 150 Prozesse gleichzeitig laufen dürfen, ist der Ram dann schnell erschöpft.

Also Sofortmaßnahme habe ich das Speicherlimit pro Prozess auf 1 Gigabyte limitiert.

Bisher scheint es keine Abhilfe zu geben und so wie es aussieht ist vorerst nur diese Instanz betroffen.
Das kann sich schnell ändern, wenn der Thread auch andere Friendica-Instanzen erreicht.
Die ist nun das 3. mal, das wir hier "Vorreiter" waren - echte Pionierarbeit 😉

In der Regel dauert es 1-2 Wochen, bis ein Dev über so einen Vorfall auf seiner eigenen Instanz aufmerksam wird und dann ist solch ein Vorfall auch schnell behoben -so zumindest die Erfahrungswerte.

Bis dahin muss ich halt 2-3 am Tag den Server neu starten, damit dieser Stabil weiterläuft.

Ich habe #friendica.opensocial.space heute auch auf die Entwicklungsversion 2023.09-dev angehoben, in der Hoffnung, das sich irgendwo in dem neuen Code ein fix verbirgt, dem war aber leider nicht so.

Für die Nutzer dieser Instanz sollte sich dennoch nichts ändern, außer das das System insgesamt über den Tag verteilt mal 3-6 Minuten nicht erreichbar ist 😀

Der Vorfall wurde meinerseits auch hier gemeldet:

github.com/friendica/friendica…

Das System kann derzeit aufgrund der Endlosschleifen etwas träger sein als sonst (aber auch nicht akut langsamer) - ich bitte dies zu entschuldigen, aber leider liegt dies außerhalb meines Wirkungsbereiches.

Ansonsten gab es keine erwähnenswerten Vorkommnisse, außer das die Moderation und Schlichtungsverfahren leicht zugenommen haben.

Für die Statistik-Fans:
Derzeit haben wir 479 registrierte Nutzer (+60 im letzen Monat), von denen 217 (+4 im letzen Monat) in den letzten 6 Monaten aktiv waren und ca. 122 (+11 im letzen Monat) regelmäßig aktiv sind.

Und wie immer der Zusatz:

Wir speichern weder IP-Adressen, Referer oder User-Agent beim Zugriff auf unseren Dienst.
Es kann allerdings sein, dass das Loggen dieser Metadaten kurzzeitig aktiviert wird - beispielsweise bei einer DOS oder DDOS-Attacke - aber auch nur, um technische Gegenmaßnahmen einzuleiten. Das Loggen wird nach solch einem Vorfall direkt wieder deaktiviert und die entsprechenden Logs gelöscht.

#friendica.opensocial.space

#friendica.opensocial.space
Als Antwort auf OldKid ⁂

friendica (DFRN) - Link zum Originalbeitrag

Raroun

 — (opensocial.space engine room)

@OldKid
Es gibt einen Thread über Wissenschaftler im Fediverse:

toot.cat/@Hashtags/11074204203…

Daran arbeitet sich der Server in einer Endlosschleife ab - wahrscheinlich, weil dort halt viele Kontakte sind, die alle versucht werden aufzulösen oder in die Kontaktdatenbank aufzunehmen.
So zeigt es zumindest die Datenbank - leider wird der Server damit nie fertig und wenn alle Kontakte abgearbeitet sind, fängt er von vorne an 😀

@OldKid ⁂
Dieser Beitrag wurde bearbeitet. (1 Jahr her)
Unbekannter Ursprungsbeitrag

friendica (DFRN) - Link zum Originalbeitrag

Raroun

@Michael Vogel

Meine Instanz wird von Endlosschleifen aufgefressen. 🙁

Grobe Informationen gibt es hier:
github.com/friendica/friendica…

Detaillierte hier in diesem Thread:
friendica.opensocial.space/dis…

Ich weiß echt nicht mehr weiter 😴

Raroun

2023-08-01 17:24:38

friendica - Link to source

Hallo zusammen,
es ist wieder soweit - einmal im Monat poste ich den Serverstatus aus Transparenzgründen.

Die Sprünge im Ram sind Neustarts des Servers. Diese werden in der Regel nur Nachts und prophylaktisch vorgenommen. Bei Sicherheitskritischen Updates wie Firmware oder ähnlichem auch mal am Tag - Ein Neustart des Servers und aller Services dauert in der Regel 1-2 Minuten.

Wie Ihr am Ram sehen könnt, lief der Server fast den ganzen Monat stabil ohne Neustarts, außer am 09.07.2023.

Ab dem 31.07.2023 seht Ihr , das der Server ca. 2 mal am Tag neu gestartet wurde.

Dies hat einen Grund: Aktuell kämpfen wir vermutlich mit einem Bug in Friendica.

Es scheint einen Thread im Fediverse zu geben, der dafür sorgt, das sich die PHP-Prozesse in einer Endlosschleife aufhängen, bis der maximale Speicher von 3 Gigabyte pro Prozeess erreicht ist - danach wird dieser abgebrochen.

Das hört sich jetzt nicht dramatisch an, aber da bei uns bis zu 150 Prozesse gleichzeitig laufen dürfen, ist der Ram dann schnell erschöpft.

Also Sofortmaßnahme habe ich das Speicherlimit pro Prozess auf 1 Gigabyte limitiert.

Bisher scheint es keine Abhilfe zu geben und so wie es aussieht ist vorerst nur diese Instanz betroffen.
Das kann sich schnell ändern, wenn der Thread auch andere Friendica-Instanzen erreicht.
Die ist nun das 3. mal, das wir hier "Vorreiter" waren - echte Pionierarbeit 😉

In der Regel dauert es 1-2 Wochen, bis ein Dev über so einen Vorfall auf seiner eigenen Instanz aufmerksam wird und dann ist solch ein Vorfall auch schnell behoben -so zumindest die Erfahrungswerte.

Bis dahin muss ich halt 2-3 am Tag den Server neu starten, damit dieser Stabil weiterläuft.

Ich habe #friendica.opensocial.space heute auch auf die Entwicklungsversion 2023.09-dev angehoben, in der Hoffnung, das sich irgendwo in dem neuen Code ein fix verbirgt, dem war aber leider nicht so.

Für die Nutzer dieser Instanz sollte sich dennoch nichts ändern, außer das das System insgesamt über den Tag verteilt mal 3-6 Minuten nicht erreichbar ist 😀

Der Vorfall wurde meinerseits auch hier gemeldet:

github.com/friendica/friendica…

Das System kann derzeit aufgrund der Endlosschleifen etwas träger sein als sonst (aber auch nicht akut langsamer) - ich bitte dies zu entschuldigen, aber leider liegt dies außerhalb meines Wirkungsbereiches.

Ansonsten gab es keine erwähnenswerten Vorkommnisse, außer das die Moderation und Schlichtungsverfahren leicht zugenommen haben.

Für die Statistik-Fans:
Derzeit haben wir 479 registrierte Nutzer (+60 im letzen Monat), von denen 217 (+4 im letzen Monat) in den letzten 6 Monaten aktiv waren und ca. 122 (+11 im letzen Monat) regelmäßig aktiv sind.

Und wie immer der Zusatz:

Wir speichern weder IP-Adressen, Referer oder User-Agent beim Zugriff auf unseren Dienst.
Es kann allerdings sein, dass das Loggen dieser Metadaten kurzzeitig aktiviert wird - beispielsweise bei einer DOS oder DDOS-Attacke - aber auch nur, um technische Gegenmaßnahmen einzuleiten. Das Loggen wird nach solch einem Vorfall direkt wieder deaktiviert und die entsprechenden Logs gelöscht.

#friendica.opensocial.space


@Michael 🇺🇦
Als Antwort auf Raroun

friendica (DFRN) - Link zum Originalbeitrag

Raroun

@Michael Vogel
emoji_activities ist false
Selbst wenn noch kein Nutzer verbunen ist - direkt nach einem Neustart - hacken die php_fpm Prozesse auf der Datenbank rum.

Maximale Anzahl von Kommentaren pro Beitrag sind nun 20
Maximale Anzahl von Kommentaren in der Einzelansicht sind nun auch 20

Immer noch selbes Verhalten. PHP-FPM frisst sich fest, Datenbank liegt bei 500% CPU..

Das ist erst seit 2 Tagen so - seit dem der Beitrag dort gepostet wurde. in mytop sehe ich halt die selects auf die user in diesem Beitrag.

@Michael 🇺🇦
Als Antwort auf Raroun

friendica (DFRN) - Link zum Originalbeitrag

Raroun

 — (opensocial.space engine room)

@Michael Vogel
emoji_activities = true - gleiche Situation.

Das einzige was ich einsehen kann, ist auf der Datenbank alle User aus diesem Wissenschafts-Thread abgearbeitet werden. mit selects und update statistics
Wenn alle durch sind - scheinbar , das sieht man ja nicht so in Echtzeit -, fängt das System von vorne an.

Es sind immer die selben zwei thread-uri, die unendlich abgearbeitet werden 🙁

@Michael 🇺🇦
Dieser Beitrag wurde bearbeitet. (1 Jahr her)
Unbekannter Ursprungsbeitrag

friendica (DFRN) - Link zum Originalbeitrag

Raroun

@Michael Vogel
SELECT `uri`, `thr-parent`, `parent-uri` FROM `post-view` WHERE `uri-id` = 21941455\G                           *************************** 1. row ***************************
       uri: https://toot.cat/users/Hashtags/statuses/110413239368701976
thr-parent: https://toot.cat/users/Hashtags/statuses/110413239368701976
parent-uri: https://toot.cat/users/Hashtags/statuses/110413239368701976

Bei allen Posts die diese uri als thr-parent verwenden bräuchte ich vielleicht einen tip in form eines sql-staements 😅
@Michael 🇺🇦
Als Antwort auf Raroun

friendica (DFRN) - Link zum Originalbeitrag

Raroun

das ist die zweite uro die immer wieder auftaucht:
SELECT `uri`, `thr-parent`, `parent-uri` FROM `post-view` WHERE `uri-id` = 21941457\G
*************************** 1. row ***************************
       uri: https://toot.cat/users/Hashtags/statuses/110742042033681800
thr-parent: https://toot.cat/users/Hashtags/statuses/110742042033681800
parent-uri: https://toot.cat/users/Hashtags/statuses/110742042033681800
Als Antwort auf Raroun

friendica (DFRN) - Link zum Originalbeitrag

Raroun

 — (opensocial.space engine room)

@Michael Vogel
Danke! 😉

SELECT `uri`, `thr-parent`, `parent-uri` FROM `post-view` WHERE `thr-parent` = 'https://toot.cat/users/Hashtags/statuses/110742042033681800'\G
*************************** 1. row ***************************
       uri: https://toot.cat/users/Hashtags/statuses/110742042033681800
thr-parent: https://toot.cat/users/Hashtags/statuses/110742042033681800
parent-uri: https://toot.cat/users/Hashtags/statuses/110742042033681800

Da kommt exakt das gleiche Ergebnis 😀

@Michael 🇺🇦
Dieser Beitrag wurde bearbeitet. (1 Jahr her)
Als Antwort auf Raroun

friendica (DFRN) - Link zum Originalbeitrag

Raroun

@Michael Vogel
Es ist die normale mysql-Konsole.
Die Access-Log ist heute Morgen ruhig, also kann ich einen externen Prozess Zugriff ausschließen.
Meine Vermutung fiel auf eine Endlosschleife, weil sich die Prozesse in der Smilies.php festfressen - also so wie ich es verstehe in der Text-Aufbereitung des Posts.
Ich studiere mal die Friendica-Logs, vielleicht steht da ja was auffälliges drin 😀
@Michael 🇺🇦
⇧