• Wenn du hier im Forum ein neues Thema erstellst, sind schon Punkte aufgeführt die du ausfüllen musst. Das dient im Allgemeinen dazu die notwendigen Informationen direkt mit der Frage bereitzustellen.
    Da in letzter Zeit immer wieder gerne das Formular gelöscht wurde und erst nach 3 Seiten Nachfragen die benötigten Infos für eine Hilfe kommen, werde ich nun jede Fragestellung die nicht einmal annähernd das Formular benutzt, sofort in den Sondermüll schicken.
    Füllt einfach die abgefragte Daten aus und alle können euch viel schneller helfen.

XF2.2 1&1/Ionos sperrt einfach meine Datenbank

Silmarillion schrieb:
Es handelt sich also um keinen Fehler, wie ich bislang angenommen und gehofft hatte. @Kirby selbst hat sich die DB angeschaut. Auch er konnte diese zusätzlichen GB nicht finden. Was meint Ihr, wie ich jetzt am besten vorgehen sollte?
Ich komme ja wohl nicht umhin, diese Files hier zu löschen/minimieren:
Zum Vergrößern anklicken....
Ich hatte mit die DB angesehen, ja - xf_search_index im speziellen aber nicht gesondert angesehen.

Diese Tabelle ist, wie Chris ja schon geschrieben hat, standardmäßig MyISAM - Volltext-Indexe gibt es bei InnoDB noch nicht soo lange (sei MySQL 5.5, XenForo setzt aber min. nur MySQL 5.5 voraus).
InnoDB und MyISAM zu mischen ist im allgemeinen nicht sinnvoll und verursacht Probleme - wenn man denn wirklich "mischt".

Das ist bei dieser tabelle aber gerade nicht der Fall, der Suchindex wird ausschließlich für die Suche genutzt.
InnoDB Volltext Indexe belegen deutlich mehr Speicher als bei MyISAM - und werden obendrein bei der Berechnung der Index-Größe über information_schema nicht berücksichtigt.
Es sind zwar Indexe, aber eben ... anders.

Wenn Du die Tablle nicht selbst umgestellt hast (sei es nun bewusst oder unbewusst) und das Problem bei mehreren Kunden auftritt würde ich mal vermuten dass IONOS grundsätzlich alls MyISAM-Tabellen auf InnoDB umgestellt hat.
Falls das möglich ist kannst Du die Tablle wieder auf MyISAM umstellen, einen Weg dazu hat Chris ja bereits aufgezeigt.

Andere Ansätze:
1) TRUNCATE xf_searrch_index und ALTER TABLE xf_search_index Engine=InnoDB
oder
2)
Code: 
CREATE TABLE `xf_search_index_new` (
  `content_type` varchar(25) COLLATE utf8mb4_general_ci NOT NULL,
  `content_id` int unsigned NOT NULL,
  `title` varchar(250) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
  `message` mediumtext COLLATE utf8mb4_general_ci NOT NULL,
  `metadata` mediumtext COLLATE utf8mb4_general_ci NOT NULL,
  `user_id` int unsigned NOT NULL DEFAULT '0',
  `item_date` int unsigned NOT NULL,
  `discussion_id` int unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`content_type`,`content_id`),
  KEY `user_id_item_date` (`user_id`,`item_date`),
  FULLTEXT KEY `title_message_metadata` (`title`,`message`,`metadata`),
  FULLTEXT KEY `title_metadata` (`title`,`metadata`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
gefolgt von
Code: 
RENAME TABLE xf_search_index to xf_search_index_old, xf_search_index_new to xf_search_index
und
Code: 
DROP TABLE xf_search_index_old

Und danach (sowohl bei als als auch 2 und dem Ansatz von Chris) den Suchindex neu erstellen.
Das würde ich aber per SSH machen, geht Zillionen mal schneller als per Browser.

Aber wie Chris schon geschrieben hat, das wäre nur ein vorübergehener Workaround - 3+ Millonen Beiträge ist eigentlich zuviel für Volltext; in der Größenordnung möchte man ES nutzen.
 
Kirby schrieb:
Ich hatte mit die DB angesehen, ja - xf_search_index im speziellen aber nicht gesondert angesehen.

Diese Tabelle ist, wie Chris ja schon geschrieben hat, standardmäßig MyISAM - Volltext-Indexe gibt es bei InnoDB noch nicht soo lange (sei MySQL 5.5, XenForo setzt aber min. nur MySQL 5.5 voraus).
InnoDB und MyISAM zu mischen ist im allgemeinen nicht sinnvoll und verursacht Probleme - wenn man denn wirklich "mischt".

Das ist bei dieser tabelle aber gerade nicht der Fall, der Suchindex wird ausschließlich für die Suche genutzt.
InnoDB Volltext Indexe belegen deutlich mehr Speicher als bei MyISAM - und werden obendrein bei der Berechnung der Index-Größe über information_schema nicht berücksichtigt.
Es sind zwar Indexe, aber eben ... anders.

Wenn Du die Tablle nicht selbst umgestellt hast (sei es nun bewusst oder unbewusst) und das Problem bei mehreren Kunden auftritt würde ich mal vermuten dass IONOS grundsätzlich alls MyISAM-Tabellen auf InnoDB umgestellt hat.
Falls das möglich ist kannst Du die Tablle wieder auf MyISAM umstellen, einen Weg dazu hat Chris ja bereits aufgezeigt.

Andere Ansätze:
1) TRUNCATE xf_searrch_index und ALTER TABLE xf_search_index Engine=InnoDB
oder
2)
Code: 
CREATE TABLE `xf_search_index_new` (
  `content_type` varchar(25) COLLATE utf8mb4_general_ci NOT NULL,
  `content_id` int unsigned NOT NULL,
  `title` varchar(250) COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',
  `message` mediumtext COLLATE utf8mb4_general_ci NOT NULL,
  `metadata` mediumtext COLLATE utf8mb4_general_ci NOT NULL,
  `user_id` int unsigned NOT NULL DEFAULT '0',
  `item_date` int unsigned NOT NULL,
  `discussion_id` int unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`content_type`,`content_id`),
  KEY `user_id_item_date` (`user_id`,`item_date`),
  FULLTEXT KEY `title_message_metadata` (`title`,`message`,`metadata`),
  FULLTEXT KEY `title_metadata` (`title`,`metadata`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
gefolgt von
Code: 
RENAME TABLE xf_search_index to xf_search_index_old, xf_search_index_new to xf_search_index
und
Code: 
DROP TABLE xf_search_index_old

Und danach (sowohl bei als als auch 2 und dem Ansatz von Chris) den Suchindex neu erstellen.
Das würde ich aber per SSH machen, geht Zillionen mal schneller als per Browser.

Aber wie Chris schon geschrieben hat, das wäre nur ein vorübergehener Workaround - 3+ Millonen Beiträge ist eigentlich zuviel für Volltext; in der Größenordnung möchte man ES nutzen.
Zum Vergrößern anklicken....
Vielen Dank für den Vorschlag/Workaround. Das sollte ja dann wohl, eigentlich, mein Hoster vornehmen und hinbekommen!? ^^

Zu ES...das wird ja leider nicht angeboten bei Ionos Managed Servern. Eventuell wäre das aber ein plausibles Argument, so dass sie mir Elastic Search doch zur Verfügung stellen.

Was genau bewirkt ES denn da zum Positiven? Und hätte ich damit erst eimal für eine Weile Ruhe?

Was mich aber total verwundert: das @mph hier, mit dem identischen Server, beim gleichen Anbieter, offenbar keinerlei Probleme hat. Wie sieht denn bei Dir die Speicherbelegung aktuell aus, @mph?
 
Darf ich fragen, was du für dein Hosting pro Monat zahlst?

Silmarillion schrieb:
Was genau bewirkt ES denn da zum Positiven? Und hätte ich damit erst eimal für eine Weile Ruhe?
Zum Vergrößern anklicken....
ElasticSearch wird via dem EnhancedSearch Addon unterstützt. Basically wird dann für den Suchindex ElasticSearch alleine verwendet und nicht die (langsamere) MySQL Datenbank. Du benötigst dafür eben ElasticSearch, das auf Java basiert und z.B. direkt am Webserver laufen kann. Ich weiß nicht, ob man viel Speicherplatz spart, aber man spart auf jeden Fall Rechenzeit, da MySQL für eine Textsuche maximal eine Krücke darstellt, während ElasticSearch genau dafür programmiert wurde.

Auf jeden Fall dürftest du bei deinem Setup den (externen) DB-Server bei der Suche umgehen können und kannst dann auch die Tabellen für die Suche komplett leeren.
 
Zuletzt bearbeitet:
Es gäbe da auch noch einen anderen Ansatz, gerade wenn für die DB für externe DB-Server genutzt werden.
Das reduziert die Transport- und Dateisystemgrößen dramatisch.

Um eventuelle und mir bisher nicht bekannte Auswirkungen zu eruieren habe ich dazu eine leider bisher unbeantwortete Anfrage bei XF gestellt.
XF 2.2 - Compress some tables?

Ich habe das auch in unserem Testforum probiert und bei der Tabelle xf_post die Komprimierung aktiviert.
Das Ergebnis war, bei einer Größe des Originals von 2.6 GB, wurde diese auf 1.2 GB Dateisystemgröße komprimiert.
In etwa dasselbe Ergebnis gab es bei div. anderen großen Tabellen.
Nun muss ich das noch mal im Livebetrieb testen, um Einbrüche der Performance zu erkennen, oder ausschließen zu können.
Bitte testet das mit der gebotenen Vorsicht!
Bei Datenbanken, die im Netz liegen, sollte das allerdings schon wegen der drastisch kleineren Transportgrößen viel bringen.

Nachtrag:
Ich konnte das Datenvolumen einer im Original 10GB großen Datenbank, auf der "Platte", auf 3,5 GB reduzieren... :).
Aber erstmal nur in der Testumgebung.
Die Tabelle xf_post ist allerdings auch im Livebetrieb nun komprimiert... Bisher ohne "Nebenwirkungen", Fehler oder Performanceeinbruch.
 
Zuletzt bearbeitet:
Kirby schrieb:
3+ Millonen Beiträge ist eigentlich zuviel für Volltext; in der Größenordnung möchte man ES nutzen.
Zum Vergrößern anklicken....
Absolut!
Silmarillion schrieb:
Zu ES...das wird ja leider nicht angeboten bei Ionos Managed Servern.
Zum Vergrößern anklicken....
Vielleicht ist man mit +3 Mio Beiträgen auch einfach auf einem zu kleinen, zu eingeschränkten Paket unterwegs. Sprich mal über ein Upgrade nachdenken oder am besten gleich dedicated root server, wobei ich bei deinen Skills (@Silmarillion ) davon Abstand halten würde und nach einem Managed Server mit u.a. ES ausschau halten würde. Diese gibt es, sind oftmals als Server für Shops beworben und sind natürlich... teurer. ;)
 
Mein Forum ist deutlich kleiner. Demnächst sind es 50000 Beiträge und ca. 60000 Bilder einschließlich derer, die vom Image Proxy vorgehalten werden. Die Datenbank zeigt ca. 390 MB an. Das ist weit weg von 3 Mio. Beiträgen, von denen ich hier gestern gelesen habe.
 
mph schrieb:
Mein Forum ist deutlich kleiner. Demnächst sind es 50000 Beiträge und ca. 60000 Bilder einschließlich derer, die vom Image Proxy vorgehalten werden. Die Datenbank zeigt ca. 390 MB an. Das ist weit weg von 3 Mio. Beiträgen, von denen ich hier gestern gelesen habe.
Zum Vergrößern anklicken....
Moinsen, Markus. Hmmm...ich ging bislang immer davon aus, dass Dein Forum das hier ist: Chiliforum - Hot-Pain.de

Ist das nicht der Fall?

Gruß,
Christian
 
otto schrieb:
Absolut!

Vielleicht ist man mit +3 Mio Beiträgen auch einfach auf einem zu kleinen, zu eingeschränkten Paket unterwegs. Sprich mal über ein Upgrade nachdenken oder am besten gleich dedicated root server, wobei ich bei deinen Skills (@Silmarillion ) davon Abstand halten würde und nach einem Managed Server mit u.a. ES ausschau halten würde. Diese gibt es, sind oftmals als Server für Shops beworben und sind natürlich... teurer. ;)
Zum Vergrößern anklicken....
Das Paket passt dicke, @otto. Zumal nur das eine Forum darüber läuft. Das Problem scheint vielmehr die Obergrenze von nur 5,5 GB bei den Datenbanken zu sein.

Gruß,
Christian
 
Masetrix schrieb:
Es gäbe da auch noch einen anderen Ansatz, gerade wenn für die DB für externe DB-Server genutzt werden.
Das reduziert die Transport- und Dateisystemgrößen dramatisch.

Um eventuelle und mir bisher nicht bekannte Auswirkungen zu eruieren habe ich dazu eine leider bisher unbeantwortete Anfrage bei XF gestellt.
XF 2.2 - Compress some tables?

Ich habe das auch in unserem Testforum probiert und bei der Tabelle xf_post die Komprimierung aktiviert.
Das Ergebnis war, bei einer Größe des Originals von 2.6 GB, wurde diese auf 1.2 GB Dateisystemgröße komprimiert.
In etwa dasselbe Ergebnis gab es bei div. anderen großen Tabellen.
Nun muss ich das noch mal im Livebetrieb testen, um Einbrüche der Performance zu erkennen, oder ausschließen zu können.
Bitte testet das mit der gebotenen Vorsicht!
Bei Datenbanken, die im Netz liegen, sollte das allerdings schon wegen der drastisch kleineren Transportgrößen viel bringen.

Nachtrag:
Ich konnte das Datenvolumen einer im Original 10GB großen Datenbank, auf der "Platte", auf 3,5 GB reduzieren... :).
Aber erstmal nur in der Testumgebung.
Die Tabelle xf_post ist allerdings auch im Livebetrieb nun komprimiert... Bisher ohne "Nebenwirkungen", Fehler oder Performanceeinbruch.
Zum Vergrößern anklicken....
Danke, @Masetrix . Das ist ein weiterer und durchaus interessanter Ansatz. Ich werde diesen mal in meinem Thread im XF-Supportforum anschreiben. Was mich etwas irritiert ist die Tatsache, dass ein Chris D in besagtem Thread, mehr oder weniger, empfiehlt MyISAM anstelle von InnoDB zu verwenden.

Gruß,
Christian
 
Silmarillion schrieb:
Was genau bewirkt ES denn da zum Positiven? Und hätte ich damit erst eimal für eine Weile Ruhe?
Zum Vergrößern anklicken....
Ruhe weiss ich nicht, aber dieser Index wäre weg:
2.2G xf_search_index.ibd
und die Tabelle selber wäre auch leer.
Welche sonst noch verschwinden weiss ich nicht aus dem Kopf.
 
Silmarillion schrieb:
Danke, @Masetrix . Das ist ein weiterer und durchaus interessanter Ansatz. Ich werde diesen mal in meinem Thread im XF-Supportforum anschreiben. Was mich etwas irritiert ist die Tatsache, dass ein Chris D in besagtem Thread, mehr oder weniger, empfiehlt MyISAM anstelle von InnoDB zu verwenden.

Gruß,
Christian
Zum Vergrößern anklicken....

Alles andere wurde mich wundern.
Bei XF muss man von bestimmten Grundsätzlichkeiten/Minimalanforderungen ausgehen und da ist MyIsam für diesen Zweck noch immer am besten geeignet.
Wir Admins sollten dann in der Lage sein das Setup an unsere Bedürfnisse anzupassen.
In meinem Fall ist nun InnoDB die bessere Wahl, weil hier ausreichend RAM vorhanden ist und InnoDB Daten mehr im RAM vorhält als das MyIsam per Default macht. Was ist besser als Daten bereits im RAM zu haben um mit ihnen zu arbeiten, ohne dabei zusätzliche Tools wie Redis nutzen zu müssen. Abgesehen davon, dass Elasticsearch beim Suchen - in Verbindung mit dem Zusatz von XF - mehr Funktionalität bietet als die Standardsuche von XF verzichten wir auch darauf, denn der Vorteil von Elasticsearch, die Daten ebenso wie InnoDB hauptsächlich im RAM vorzuhalten, ist mit der Nutzung von InnoDB obsolet.

Fazit:
Wäre ich administrativ in deiner Situation, würde ich als Erstes zu einem Hoster wechseln, der mir im Fall von Überbeanspruchung nicht einfach den Saft abdreht.
Dann, wenn die DB auch dort noch nicht lokal vorliegt und Platz auf der Platte gespart werden muss, würde ich InnoDB mit Komprimierung anstelle von MyIsam nutzen. Das natürlich unter Hinblick darauf, dass InnoDB sauber konfiguriert ist und MySQL dahingehend nicht mit den Standardeinstellungen zurechtkommen muss. Auch wenn die DB nicht im Netz liegt würde ich InnoDB nutzen, nur dann eben ohne Komprimierung, da die Komprimierung nur in Sachen Plattenspeicher bzw. Verkleinerung des Transportvolumens nützlich ist.
 
An anderer Stelle haben/hatten sie 1GB als Grenze für die DBs auf den Datenbankservern. Rein vom Plattenplatz reicht das System bestimmt. Wenn die Datenbank lokal laufen würde, gäbe es die Größenbeschränkung wahrscheinlich nicht, ist mir zumindest bei mir nicht aufgefallen. Eine große und viel beanspruchte DB braucht auch mehr RAM und das ist bei dem Paket recht knapp bemessen. Für mein Forum reicht das dicke, aber für eins was geschätzt 50-mal so groß ist wird das irgendwann eng. Entweder stößt man mit einer nicht auf dem gleichen Server laufenden DB an die Grenzen, was Ionos auf den DB-Servern erlaubt, und wenn die DB lokal läuft sind die (meine ich) 12GB RAM bei einer großen DB plus Webserver plus PHP plus Linux plus Caches irgendwann auch voll. Wenn man es hin bekommt, dass die DB nicht die Grenzen reißt, kann man das Forum da weiter laufen lassen. Ansonsten befürchte ich, dass früher oder später ein Umzug nötig ist.
 
Nochmal zum XF MyIsam-Mix mit InnoDB...

Inzwischen habe ich herausgefunden warum von XF MyIsam für die Suchindextabelle "empfohlen" und im Standard auch genutzt wird.

Mit normalem MySQL 5.7 kann man alle Tabellen ohne Probleme mit InnDB nutzen, das geht damit dann sogar performanter.
Nun kommt die Crux.
Nutzt man anstelle von MySQL 5.7.x, MariaDB 10.4.21 sollten die XF Tabellen tunlichst so wie in der XF-Voreinstellung gelassen werden denn damit kommt es nicht zu ungeahnten "Seiteneffekten" und Fehlern wie z:.B.
[ERROR] InnoDB: (Duplicate key) writing word node to FTS auxiliary index table `xenforodb`.`xf_search_index`
Zum Vergrößern anklicken....
und immer wieder unvermittelt wiederkehrenden Neustarts von MariaDB.

Imho macht mir MariaDB 10.4.x unter Ubuntu 18.4.xLTS einen sehr "zickigen" Eindruck. MySQL 5.7 himself ist da viel stabiler und performanter. Müsste ich nicht demnächst ein Upgrade auf Ubuntu 20.4 starten, wozu MariaDB (in Plesk) Vorraussetzung ist, ich würde wieder MySQL 5.7 verwenden...

Nur so zur Info... ;)
 
Ich bin noch auf MariaDB 10.3.x - habe damit noch keine solche Auswirkungen gehabt. Aber gut zu wissen, so kann man vorbereitet sein. Danke. :)

Ansonsten kann ich das negativ zu MariaDB gesagt nicht ganz nachvollziehen, Performanceprobleme hatte ich damit nie, die auf die Software zurück zu führen wären. Wenn dann war ich zu deppert MariaDB gescheit zu konfigurieren. :D ;)
 
Masetrix schrieb:
Inzwischen habe ich herausgefunden warum von XF MyIsam für die Suchindextabelle "empfohlen" und im Standard auch genutzt wird.
Zum Vergrößern anklicken....
Nicht ganz ;)

XenForo hat als Mindesvoraussetzung MySQL 5.5 - mit MySQL 5.5 gibt es kein InnoDB Volltext (gibt es erst seit MySQL 5.6), ergo muss das MyISAM sein.

Mit normalem MySQL 5.7 kann man alle Tabellen ohne Probleme mit InnoDB nutzen, das geht damit dann sogar performanter.
Zum Vergrößern anklicken....
Wäre interessant das mal zu testen, bisher habe ich nur Benchmarks gesehen bei denen InnoDB FT langsamer ist als MyISAM FT.
Darüber hinaus gebe ich dir Recht - InnoDB FT ist bei MariaDB zickig.
Aber wie es auch sei: FT in MySQL,/MariaDB egal ob MyISAM oder InnoDB, war und ist eine Krücke.

und immer wieder unvermittelt wiederkehrenden Neustarts von MariaDB.
Zum Vergrößern anklicken....
Kann ich nicht bestätigen, haben wir nicht.

MySQL 5.7 himself ist da viel stabiler und performanter.
Zum Vergrößern anklicken....
Auch da würden mich Benchmarks interessieren :)
 
otto schrieb:
Ansonsten kann ich das negativ zu MariaDB gesagt nicht ganz nachvollziehen, Performanceprobleme hatte ich damit nie, die auf die Software zurück zu führen wären. Wenn dann war ich zu deppert MariaDB gescheit zu konfigurieren. :D ;)
Zum Vergrößern anklicken....

Ich denke hier hakt es - im Großen ganzen - auch bei mir. Ich habe die MDB-Standardkonfiguration und die, die ich vorher bei MySQL7 hatte zusammengepackt oder entfernt - wo inkompatibel.
Von wegen "Kompatibilität"... Da wird sich mit steigender Versionsnummer noch so mancher Wechsler wundern. :)

Ich erwarte aber von MySQL/MariaDB mehr als du, nämlich dass sich die DB so konfigurieren lässt, dass Boliden wie ES, von der Performance her, obsolet werden. Mit MySQL 7.5.x gelang das, mit MariaDB aufgrund der geschilderten Fehler (Searchindex MyISAM/InnoDB)) nicht. Das heißt nun für mich 20 Jahre Erfahrung
mit der Konfiguration von MySQL in die Tonne treten und (dahingehend) mit MariaDB neu starten :(
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben