Skip to main content


Hallo, ich habe auf dieser Instanz (aktuelle RC) ein Problem mit der Suchfunktion. Wenn ich nach Hashtags suche, werden mir generell keine Treffer angezeigt. Suche ich nach dem gleichen Begriff, nur ohne "#" werden mir Treffer angezeigt, die auch den jeweiligen Hashtag besitzen.
Beispiel: Eine Suche nach "#Fediverse" liefert null Ergebnisse. Suche ich hingegen nach "Fediverse" werden zig Treffer angezeigt.
Irgendwie scheint die Suche nach Hashtags kaputt zu sein?
Ist das sonst noch jemanden aufgefallen?
!Friendica Support
@Admin
Guten Morgen.
Unsere Instanz läuft auch auf der 2023.03-rc und die Suche nach Hashtags funktioniert einwandfrei - also bis auf die üblichen Macken bei der Suche (mehrere Suchbegriffe funktionieren nicht oder nur bedingt).
@Admin bei mir klappt das auch...
Danke. Habe mal das Logfile aktiviert. Scheinbar gibt es ein Problem mit der Datenbank: https://bin.disroot.org/?65741715ed73e74e#HSfWpALzeDmdpY5LPtUg5imanWTvB5N7n6wCp3CYHXC6

Kann mir jemand sagen, wie ich dieses Problem lösen kann?

Seltsam ist aber, dass gespeicherte Hashtags funktionieren. D.h. diese werden mir im Stream angezeigt. Also scheint die gespeicherte Suche zu funktionieren, aber die "Livesuche" nicht.
@Admin Erstmal ist das Logbuch unguenstig formatiert, somit steht die wichtige Meldung "error":"Index post-tag is corrupted" mitten drin. Wenn du nach der Meldung suchst - so mache ich es bei mir unbekannten Meldungen immer, da vielleicht wo jemand das gleiche Problem bereits geschildert hat - kommst du dann schnell zur Loesung. Z.B. habe ich gefunden: https://dba.stackexchange.com/questions/31701/finding-and-fixing-innodb-index-corruption
Hallo @Admin,
dir hat es den Index der Tabelle post-tag zerschossen - passiert selten, aber passiert.
Du solltest ein optimize table auf die Tabelle "post-tag" machen.
Oder - wenn Deine Datenbank noch nicht allzu gross ist, gerne auch ein optimize über die gesamte Datenbank via "mysqloptimize -p DBNAME".
Ich mache so einmal ein Monat ein optimize über die gesamte Datenbank als "Wartung".
Wenn Deine Datenbank etwas grösser ist, oder Du viele User hast - empfehle ich den Optimize nur über die Tabelle "post-tag".

Danach sollte die Suche wieder funktionieren 😉
@Raroun
Danke Dir. Ist nur eine Ein-User-Instanz.
Nach einem "sudo mysqloptimize db-name" funktioniert auch die Suche nach Hashtags.
Frage: Gibt es auch eine Möglichkeit, die DB zu überprüfen, ob eine Optimierung notwendig ist?
@Admin
Bitte, gerne.
So eine Richtige "Anzeige" gibt es nicht. Wenn es eine Ein-User-Instanz ist, reicht aus Erfahrung ein Optimize alle 3-4 Monate.
@Raroun
Darf ich mich hier einklinken?
Wie viel User hast Du auf Deinem System und wie lange dauert so ein komplettes mysqloptimize -p DBNAME.
Bin am überlegen, ob es nicht mal sinnvoll wäre, das hier auf anonsys.net auszuführen. 🤔
@Raroun
Danke. 👍
Werde ich vielleicht bei mir mal ausführen.
@Raroun
1. ist das ein Problem, im laufenden Betrieb auszuführen?
2. wäre es "klug", per cron gesteuert, 1x pro Woche zu starten?
@Tuxi :Friendica: 🐧 ✅
@Tuxi :Friendica: 🐧 ✅
Nix geht über testen in der Prod 😁

Ich lass es grad bei meiner 24GB großen DB laufen... läuft schon 40 Minuten. Spüre im Betrieb keine Einschränkungen.

Auch der Speicherplatz auf der Festplatte scheint nicht zuzunehmen.

@Raroun
@𝗝𝗮𝗸𝗼𝗯 :𝗳𝗿𝗶𝗲𝗻𝗱𝗶𝗰𝗮: 🇦🇹 ✅
Der belegte Festplattenplatz sollte nach erfolgreichem optimize abnehmen 😀
@𝗝𝗮𝗸𝗼𝗯 :𝗳𝗿𝗶𝗲𝗻𝗱𝗶𝗰𝗮: 🇦🇹 ✅ @Raroun
Also ich würde die Maintenance ja schon aktivieren... 😉
Berichte mal gerne, wie es bei Dir gelaufen ist. 😆
Wie viel User hast Du denn und welche HW ist im Einsatz?
@𝗝𝗮𝗸𝗼𝗯 :𝗳𝗿𝗶𝗲𝗻𝗱𝗶𝗰𝗮: 🇦🇹 ✅
1.) ich schalte meistens vorher den Wartungsmodus ein, damit keine Prozesse auf die Datenbank zugreifen und meine Benutzer auch ein "Datenbankwartung - voraussichtliche Dauer ca. 30 Minuten) angezeigt bekommen. Wohlmöglich funktioniert es auch im laufenden Betrieb, habe ich aber noch nie ausprobiert. Mysqldump macht meines Wissens nach Probleme ohne den Wartungsmodus (table-locks).
2.) Durchaus denkbar - via cron ein "friendica maintenance on" - dann optimize - und dann "friendica maintenance off"
Auf einer Mehrnutzer-Instanz mache ich das aber lieber manuell 😀
@Admin
Oh, ich sehe gerade, dass meine DB 100 GB hat. Da wird das wohl etwas dauern. fg
@Admin
Einzig diesen Hinweis hab ich bekommen.
friendica.fetched-activity
note     : The storage engine for the table doesn't support optimize


läuft aber noch.
@𝗝𝗮𝗸𝗼𝗯 :𝗳𝗿𝗶𝗲𝗻𝗱𝗶𝗰𝗮: 🇦🇹 ✅
Kurios, auf meiner Instanz hole ich immer so um 10-20 GByte raus.
Hältst Du unangeforderte Beiträge lange vor?
Den meisten Speicherplatz bekomme ich aus der Tabelle „storage“.
@Raroun @Admin

Achso... ich hab ein Filesystem Storage-Backend...
@Raroun

Trotzdem finde ich 24GB für eine Einzeluserinstanz heftig... gut, 1 Gruppe mit rund 1000 Mitgliedern, und 2 oder 3 RSS-Feeds als Mirror, wo auch 1000 Follower sind...

@Admin
@𝗝𝗮𝗸𝗼𝗯 :𝗳𝗿𝗶𝗲𝗻𝗱𝗶𝗰𝗮: 🇦🇹 ✅
Gruppe mit 1000 Followern und wahrscheinlich postet jeder ab und zu mal ein Bild - deine Instanz ist nicht die jüngste (im positiven Sinne) - ich denke da kommt schon einiges zusammen 😀
@Raroun @Admin

Ja da kommen in der Tat einige Bilder...

Aber die sind doch im File-Backend, nicht in der Datenbank...
@Raroun @𝗝𝗮𝗸𝗼𝗯 :𝗳𝗿𝗶𝗲𝗻𝗱𝗶𝗰𝗮: 🇦🇹 ✅ @Admin
Lief bei mir heute erfolgreich durch. Erstaunlicherweise hat das nur eine halbe Stunde gedauert. Die Datenbank ist um 55 GB kleiner geworden. 👍
@Raroun
Ja, bin auch überrascht.
@Tuxi :Friendica: 🐧 ✅ @Raroun $ Was ergibt bei Dir die Ausgabe von "$ bin/console storage list" ?
@tom s
Er hat das Database Storage, sonst wäre nicht so viel Speicher freigegeben worden 😀
@Tuxi :Friendica: 🐧 ✅
@Raroun @Tuxi :Friendica: 🐧 ✅ Ich mache einmal im Monat ein optimize, vor dem monatlichen Full-backup. Und dort kommt auch schon eine Reduzierung von mind. 1/3 vor, bei einer beschaulichen Datenbank von ca. 10GB. Mich hatte eher interessiert, ob eine solch angewachsene ältere Datenkbank, die zuvor nie ein optimize hatte, da soviel Speicherplatz freigibt.