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
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
Raroun
•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).
jakob 🇦🇹 ✅
•Admin
•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.
Roland Häder
•"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-corruptionRaroun
•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 😉
Admin
•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?
Raroun
•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.
Tuxi ⁂
•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
•Ich habe ungefähr 300 User wovon ca. 170 aktiv sind - manche mehr, manche weniger.
Auf meinem System (128gb RAM, 24 Cores @ 3,1 GHz / 4,1 GHz Turbo, NVME) dauert ein optimize der gesamten Datenbank ca. 25 Minuten bei einer Datenbankgrösse von derzeit 65 GByte.
Die Datenbankgrösse bekommst mit diesem Statement raus:
SELECT table_schema AS "Database", SUM(data_length + index_length) / 1024 / 1024 / 1024 AS "Size (GB)" FROM information_schema.TABLES GROUP BY table_schema;
Wenn man ein optimize der Datenbank regelmässig macht, geht es etwas schneller, da die Tabellen kleiner sind.
Hintergrund:
Wenn Beiträge, Photos oder was auch immer gelöscht wird, entstehen - vereinfacht ausgedrückt Lücken in der Datenbank. Das passiert relativ häufig bei Friendica, da Beiträge nur eine gewisse Zeit vorgehalten werden.
Ein optimize nimmt die Daten aus der... show more
Ich habe ungefähr 300 User wovon ca. 170 aktiv sind - manche mehr, manche weniger.
Auf meinem System (128gb RAM, 24 Cores @ 3,1 GHz / 4,1 GHz Turbo, NVME) dauert ein optimize der gesamten Datenbank ca. 25 Minuten bei einer Datenbankgrösse von derzeit 65 GByte.
Die Datenbankgrösse bekommst mit diesem Statement raus:
SELECT table_schema AS "Database", SUM(data_length + index_length) / 1024 / 1024 / 1024 AS "Size (GB)" FROM information_schema.TABLES GROUP BY table_schema;
Wenn man ein optimize der Datenbank regelmässig macht, geht es etwas schneller, da die Tabellen kleiner sind.
Hintergrund:
Wenn Beiträge, Photos oder was auch immer gelöscht wird, entstehen - vereinfacht ausgedrückt Lücken in der Datenbank. Das passiert relativ häufig bei Friendica, da Beiträge nur eine gewisse Zeit vorgehalten werden.
Ein optimize nimmt die Daten aus der Tabelle und kopiert diese in eine neue Tabelle. Die Lücken werden nicht mitkopiert, also wird Speicherplatz auf der Platte / SSD / Storage frei und die Datenbank wird kleiner.
Je nach Datenbankgrösse und Maschine kann aber aber auch gerne mal 1-3 Stunden dauern.
Was erwähnenswert wäre (optional):
Schau vorher mal in die „gserver“-tabelle.
SELECT * FROM `gserver` WHERE `nurl` LIKE '%activitypub-troll.cf‘;
Sollten da Millionen von Einträgen mit „activitypub-troll.cf“ drin sein, lösche die bitte raus. Es gibt ein bisher ungelöstes Problem, so dass viele Instanzen mit diesen Einträgen zugemüllt sind.
Löschen kannst Du die Einträge mit:
DELETE FROM `gserver` WHERE `nurl` LIKE '%.activitypub-troll.cf‘;
Tuxi ⁂
•Danke. 👍
Werde ich vielleicht bei mir mal ausführen.
jakob 🇦🇹 ✅
•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: 🐧 ✅
jakob 🇦🇹 ✅
•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
Raroun
•Der belegte Festplattenplatz sollte nach erfolgreichem optimize abnehmen 😀
Tuxi ⁂
•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?
Raroun
•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 😀
Tuxi ⁂
•Oh, ich sehe gerade, dass meine DB 100 GB hat. Da wird das wohl etwas dauern. fg
jakob 🇦🇹 ✅
•Einzig diesen Hinweis hab ich bekommen.
läuft aber noch.
Roland Häder
•jakob 🇦🇹 ✅
•vorher
... show more
vorher
nachher:
Raroun
•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“.
jakob 🇦🇹 ✅
•Achso... ich hab ein Filesystem Storage-Backend...
Raroun
•Ok, das in Verbindung mit Einzel-User-Instanz erklärt es 😀
jakob 🇦🇹 ✅
•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
Raroun
•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 😀
jakob 🇦🇹 ✅
•Ja da kommen in der Tat einige Bilder...
Aber die sind doch im File-Backend, nicht in der Datenbank...
tom s
•aus https://wiki.friendi.ca/de/docs/settings
#### Datenspeicher Backend
Legt das Datenspeicher Backend fest, mit dem Friendica hoch geladene Daten speichert. Zwei Speicher Backends sind standardmäßig bei Friendica verfügbar:
- Database : Die Daten werden in einer speziellen Tabelle in der Datenba... show more
aus https://wiki.friendi.ca/de/docs/settings
#### Datenspeicher Backend
Legt das Datenspeicher Backend fest, mit dem Friendica hoch geladene Daten speichert. Zwei Speicher Backends sind standardmäßig bei Friendica verfügbar:
- Database : Die Daten werden in einer speziellen Tabelle in der Datenbank (`storage`) gespeichert. - Filesystem : Die Daten werden als Dateien im Dateisystem gespeichert.
Weitere Speicher Backends können als Addons von Drittanbietern verfügbar sein. Falls ein solches verwendet wird, sei an dieser Stelle nur auf deren Dokumentation für weitere Informationen verwiesen.
Die Grundeinstellung ist 'Datenbank (legacy)': Dies ist die alte Methode von Friendica Daten direkt in der Datenbank abzulegen.
$ ./console storage list
Sel | Name
-----------------------
* | Filesystem
| Database
Tuxi ⁂
•Lief bei mir heute erfolgreich durch. Erstaunlicherweise hat das nur eine halbe Stunde gedauert. Die Datenbank ist um 55 GB kleiner geworden. 👍
Raroun
•Gute Ausbeute 👍🏼
Tuxi ⁂
•Ja, bin auch überrascht.
tom s
•Raroun
•Er hat das Database Storage, sonst wäre nicht so viel Speicher freigegeben worden 😀
@Tuxi :Friendica: 🐧 ✅
Tuxi ⁂
•Richtig. 😊
tom s
•