2026-02-24 21:46:28
2026-02-22 21:49:10
2026-02-22 21:49:10
13690177
!Friendica Support
Hallo lieber Support. Ich betreibe hier eine 1-Mann-Instanz in einer VM auf einem leistungsstarken NAS. Bin noch auf 2024.12. Wollte,eigentlich erst das nun geschilderte Problem lösen bevor ich ein Backup mache und upgrade. Worker sollten bei meiner Konfiguration vom Daemon gestartet werden. Manchmal stirbt der (hab noch nicht analysiert warum) und dann entsteht ein Backlog aus verzögerten Queues und Tasks. Vor drei Tagen war das mal wieder so weit und ich war bei 100 verzögerten Queues und ca. 100000 verzögerten Tasks. Nachdem ich alles wieder gerichtet hatte ging es im Laufe eines Tages auf ca. 50000 verzögerte Tasks runter, aber unter diese Schwelle komm ich nicht, im Laufe eines weiteren Tages ging es mal hoch mal runter aber blieb ungefähr bei dieser Marke, aktuell wächst es eher wieder, wohingegen die Zahl der Queues derweil auf 125 angewachsen ist. Ich hab ungefähr alle Optimierungen ausprobiert, die Handbücher und diverse LLMs so empfehlen, komme aber nicht weiter. Aktuell funktioniert die Interaktion mit neuem Content ganz gut (sonst würdet ihr das hier nicht lesen), aber der Backlog wächst und wächst. Im friendica.log sehe ich alle paar Minuten einen Eintrag der Art 2026-02-22T21:39:51Z worker [ERROR]: DB Error {"code":1406,"error":"Data too long for column 'description' at row 1","params":"INSERT INTO `post-media` (`uri-id`, `url`, `media-uri-id`, `type`, `mimetype`, `description`, `name`, `author-url`, `author-name`, `author-image`, `publisher-url`, `publisher-name`) VALUES und danach ein unheimlich langer Post. Kam noch nicht drauf wo die eigentlich herkommen. In Mariadab ist das Feld "description" aber eh schon "text", wobei es tatsächlich sein kann dass diese Posts länger als 65536 Zeichen sind. Das System ist noch nicht am I/O-Bottleneck (iostat sagt ca. 40 % Auslastung, ca 10 % iowaits), eher ist CPU-Last das Problem. Allerdings kam ich in vergangenen Zeiten wenn so etwas war immer nach einem Tag oder so wieder auf Werte unter 100 im Backlog und frage mich warum diesmal nicht. Wo könnte mir hier noch irgendwas in die Suppe spucken?
Hallo lieber Support. Ich betreibe hier eine 1-Mann-Instanz in einer VM auf einem leistungsstarken NAS. Bin noch auf 2024.12. Wollte,eigentlich erst das nun geschilderte Problem lösen bevor ich ein Backup mache und upgrade. Worker sollten bei meiner Konfiguration vom Daemon gestartet werden. Manchmal stirbt der (hab noch nicht analysiert warum) und dann entsteht ein Backlog aus verzögerten Queues und Tasks. Vor drei Tagen war das mal wieder so weit und ich war bei 100 verzögerten Queues und ca. 100000 verzögerten Tasks. Nachdem ich alles wieder gerichtet hatte ging es im Laufe eines Tages auf ca. 50000 verzögerte Tasks runter, aber unter diese Schwelle komm ich nicht, im Laufe eines weiteren Tages ging es mal hoch mal runter aber blieb ungefähr bei dieser Marke, aktuell wächst es eher wieder, wohingegen die Zahl der Queues derweil auf 125 angewachsen ist. Ich hab ungefähr alle Optimierungen ausprobiert, die Handbücher und diverse LLMs so empfehlen, komme aber nicht weiter. Aktuell funktioniert die Interaktion mit neuem Content ganz gut (sonst würdet ihr das hier nicht lesen), aber der Backlog wächst und wächst. Im friendica.log sehe ich alle paar Minuten einen Eintrag der Art 2026-02-22T21:39:51Z worker [ERROR]: DB Error {"code":1406,"error":"Data too long for column 'description' at row 1","params":"INSERT INTO `post-media` (`uri-id`, `url`, `media-uri-id`, `type`, `mimetype`, `description`, `name`, `author-url`, `author-name`, `author-image`, `publisher-url`, `publisher-name`) VALUES und danach ein unheimlich langer Post. Kam noch nicht drauf wo die eigentlich herkommen. In Mariadab ist das Feld "description" aber eh schon "text", wobei es tatsächlich sein kann dass diese Posts länger als 65536 Zeichen sind. Das System ist noch nicht am I/O-Bottleneck (iostat sagt ca. 40 % Auslastung, ca 10 % iowaits), eher ist CPU-Last das Problem. Allerdings kam ich in vergangenen Zeiten wenn so etwas war immer nach einem Tag oder so wieder auf Werte unter 100 im Backlog und frage mich warum diesmal nicht. Wo könnte mir hier noch irgendwas in die Suppe spucken?
Friendica Support hat dies geteilt.
utzer
Als Antwort auf Tobias Ernst • • •@Tobias Ernst kam auf jeden Fall an.
Ich denke das wäre jetzt kein Grund kein Backup zu machen und das Upgrade anzustoßen. Es sind nur Worker Tasks, die sind nicht so wichtig.
Das Posts zu lang für DB-Felder sind kommt immer mal wieder vor, es gibt da einige Aktoren, die sowas (absichtlich) machen, schon ewig so.
Es gibt auch ein Setting um die Länge zu beschränken, aber ich bin nicht sicher ob das bei 65000 Zeichen hilft, dass ist ja doch recht kurz.
Stehen DB Updates aus? Check via CLI.
Tobias Ernst
Als Antwort auf utzer • •@utzer Danke für die Antwort.
Die Datenbankstruktur ist up to date (bei console dbstructure update passiert nix, in der Admin-Konsole steht die Meldung dass sie aktuell ist). Ich habe gestern abend mal alle Relays bis auf eins raugeschmissen, trotzdem bin ich heute morgen immer noch bei fast derselben Zahl verzögerte Worker Tasks. Da ist irgendwo der Wurm drin, er scheint den Rückstand nicht schneller aufarbeiten zu können als Neues reinkommt. In der Situation möcht ich halt auch nicht noch mehr Downtime durch Backup und Upgrade einbauen.
Hast Du noch Tipps was ich mir da noch genauer ansehen könnte?
Wegen der Länge: "description" in der Datenbank ist derzeit vom Typ "text", da ist in der Datenbank bei 65535 Zeichen schluss. Von daher wäre es durchaus Sinnvoll wenn Freindica hier ein hartes Limit zieht und solche Posts einfach mit einem kurzen Fehler im Log zurückweist.
Friendica Support hat dies geteilt.
Tuxi ⁂
Als Antwort auf Tobias Ernst • • •@Tobias Ernst
Hast du die autom. Optimierung aktiviert? Da scheint es aktuell ein Problem zu geben: forum.friendi.ca/display/373eb…
Vielleicht läufst du hier in das gleiche Problem?
Matthias
2026-02-19 09:09:42
Tobias Ernst
Als Antwort auf Tuxi ⁂ • •Friendica Support hat dies geteilt.
Tobias Ernst
Als Antwort auf Tobias Ernst • — (Stuttgart) •-> | friendica.storage | optimize | error | The table 'storage' is full
-> | friendica.storage | optimize | status | Operation failed
Mein System war zuvor von 100.000 auf 10.000 offene Worker-Tasks runtergekommen und dann in einen Zustand verfallen, in dem MariaDB die ganze Last zieht und deswegen die Worker und der Daemon irgendwann sterben. Ich ziehn jetzt auf Storage Filesystem um und hoffe dass sich meine Probleme damit dann erledigt haben werden. In die beiden SSDs die gerade unterwegs sind habe ich ggf. ganz unnötig investiert ... :)
Ich denke, Friendica sollte davon abkommen, Datenbank als Default-Storage zu wählen, wenn der so schnell volläuft.
Friendica Support hat dies geteilt.