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

[Silmarillion]

Nachtrag: gerade mal das letzte Backup (22.09) entpackt. Größe der SQL-Datei: 3,37 GB.

 

[Kirby]

User Activiy

Ohne Redis ist das +- tödlich da extrem viel geschrieben wird.

Hast Du mal versucht das Query auszuführen?

 

[Silmarillion]

User Activiy

Ohne Redis ist das +- tödlich da extrem viel geschrieben wird.

Hast Du mal versucht das Query auszuführen?

Super! DA haben wir doch schon einmal einen Ansatzpunkt!

Was meinste? Direkt deaktivieren?

Zum Query: gebe mir Noob doch mal bitte eine kurze Anleitung, wo und wie ich das ausführen soll. Danke.

PS: ich kann da nichts zerschießen oder verschlimmbessern?

 

[Kirby]

Wo ausführen -> MySQL Shell, phpMyAdmin oder was auch immer Du als DB Admin Tool nutzen kannst.
Zerschießen kann das nichts, ist ein reines Info-Query

 

[Silmarillion]

Ok, super. Melde mich gleich zurück.

 

[Silmarillion]

Hmmm...kurze, weitere Noob-Frage: ist es normal, dass ich einen kopierten SQL-Befehl nicht einfügen kann? Eher nicht!? Müsste den dann wohl händisch eintippen.

 

[Kirby]

Nein, ist nicht normal - zumindest nicht bei PMA (ist das PMA)?
Von wo kopierst Du, aus dem Browser?

Das kann gff. schief gehen (HTML vs. Plaintext), kopier das Query in Notepad und von da dann nochmal in die Zwischenablage.

 

[Silmarillion]

kopier das Query in Notepad und von da dann nochmal in die Zwischenablage.

In Notepad ist es. Aber wie kopiere ich es jetzt in die Zwischenablage?

 

[Kirby]

Wie immer?
Strg-A, Strg-C und wieder einfügen mit Strg-V

Oder auch per Maus markieren, Rechtsklick, Kopieren, Rechtsklick, Einfügen

 

[Silmarillion]

Wie immer?
Strg-A, Strg-C und wieder einfügen mit Strg-V

Oder auch per Maus markieren, Rechtsklick, Kopieren, Rechtsklick, Einfügen

Habe ich gemacht. Funktioniert leider auch nicht. Mist.

 

[Kirby]

Was hast Du da für nen Krampf? Kann doch nicht sein dass kein Copy & Paste geht ...

Okay, alternativ das Script (nicht schön, nicht gut, tut was es soll) ins XF Stammverzeichnis hochladen und ausführen.

Oder noch Alternativer um den ganzen Krampf abzukürzen:
Schick mit Zugangsdaten per Unterhaltung

 

[Silmarillion]

Oder noch Alternativer um den ganzen Krampf abzukürzen:
Schick mit Zugangsdaten per Unterhaltung

Mache ich!

 

[mph]

Wie sehen denn Deine Einstellungen unter "Protokollierungsoptionen" aus, Markus?

Ich habe fast alle Logs auf 3 Tage stehen. Das für Benutzernamenänderungen steht auf 30 Tage und die Bearbeitungshistorie auf 7.

User Activiy

Ohne Redis ist das +- tödlich da extrem viel geschrieben wird.

Redis ist auf dem Managed Server nicht drauf. Vielleicht das Addon mal deaktivieren.

 

[Silmarillion]

Ok, Männers...nächste Runde...

Sehr geehrter Hr. K.,

ich darf mich vorstellen als Ihr neuer persönlicher Ansprechpartner.

Bezüglich Ihrer Problematik mit der Datenbankbelegung habe ich noch folgende technischen Informationen für Sie.

Ein wesentlicher Teil des belegten Speichers lässt sich auf Indizes zurückführen. Indizes dienen zur schnelleren Suche in der Datenbank. In ihrem Fall sind es insbesondere die "Full Text Search" Indizes, die sehr viel Speicher belegen (beginnend mit FTS):

141M FTS_00000000006b9591_000000000086fcd6_INDEX_6.ibd
156M import_log_vbulletin_1.ibd
217M FTS_00000000006b9591_000000000086fccf_INDEX_1.ibd
525M FTS_00000000006b9591_000000000086fccf_INDEX_4.ibd
557M FTS_00000000006b9591_000000000086fccf_INDEX_3.ibd
573M FTS_00000000006b9591_000000000086fccf_INDEX_6.ibd
637M FTS_00000000006b9591_000000000086fccf_INDEX_5.ibd
801M FTS_00000000006b9591_000000000086fccf_INDEX_2.ibd
2.2G xf_search_index.ibd
2.4G xf_post.ibd

Hier könnten Sie sich mit Ihrem Techniker absprechen, ob er denn an der Stelle zwecks Reduktion des Speicherbedarfs ansetzen kann.

Übrigens...mir wurde mitgeteilt, dass ich mit diesem Problem nicht alleine datstehe, sprich mehrere/viele Kunden davon betroffen sind. Also wird/muss Ionos ja etwas geändert haben.

 

[otto]

Was für ein Käse... die kalkulieren mit viel zu kleinen DBs, das ist der springende Punkt.

Aber sag mal l sagtest du nicht, außer einer Tabelle seien alle anderen nur Kleinvieh? Allein die Liste sagt das da mal eben 8,8 GB sind.

Hatte mich gestern auch vertan - mein DB von Hobby-Gartenteich.de ist nur 938 MB groß!

Hier mal die darin enthaltenen größten Tabellen:


Die Werte sind Meilenweit von deinen entfernt... Es sei denn dein Forum ist erheblich größer wie mein Beispiel.


Knapp 4 GB war meine Vbulletin DB des gleichen Forums früher mal groß - wegen der in der DB gespeicherten Bilder (3,3 GB alleine):

 

[Masetrix]

Ich bin schon etwas überrascht, dass XF hier einen Mix aus MyIsam und InnoDB empfiehlt.
Das kann böse ins Auge gehen. Ich habe unsere DB daher komplett auf InnoDB umgestellt.
Klar, dann darf es gerne auch "etwas mehr" RAM sein. Je nach den Einstellungen von MySQL zu InnoDB kann so eine 6 GB Datenbank sich schon mal auf 64 GB Arbeitsspeichernutzung aufblähen, weil mit InnoDB weit mehr Daten im RAM bleiben als bei MyIsam. Meine Faustregel: Mit MyIsam mehr und schnellen Plattenspeicher vorhalten, bei InnoDB mehr RAM. InnoDB hat auch den Vorteil sicherer zu sein. (Imho)

 

[Hoffi]

Kann es sein das IONOS hier die Dateien auf Filesystem basis rechnet, und nicht den Tabellen-Inhalt? Normal wird der Index doch in der Tabellengröße nicht inkludiert....

 

[Silmarillion]

Kann es sein das IONOS hier die Dateien auf Filesystem basis rechnet, und nicht den Tabellen-Inhalt? Normal wird der Index doch in der Tabellengröße nicht inkludiert....

Gute Frage, Hoffi...

 

[Silmarillion]

Ich bin schon etwas überrascht, dass XF hier einen Mix aus MyIsam und InnoDB empfiehlt.
Das kann böse ins Auge gehen. Ich habe unsere DB daher komplett auf InnoDB umgestellt.
Klar, dann darf es gerne auch "etwas mehr" RAM sein. Je nach den Einstellungen von MySQL zu InnoDB kann so eine 6 GB Datenbank sich schon mal auf 64 GB Arbeitsspeichernutzung aufblähen, weil mit InnoDB weit mehr Daten im RAM bleiben als bei MyIsam. Meine Faustregel: Mit MyIsam mehr und schnellen Plattenspeicher vorhalten, bei InnoDB mehr RAM. InnoDB hat auch den Vorteil sicherer zu sein. (Imho)

Chris D selbst hat es ja sogar empfohlen: Xenforo database suddenly grows very quickly

Ich bin verwirrt...

 

[Silmarillion]

Es gibt übrigens Neuigkeiten:

Sehr geehrter Hr. K.,

bei der von mir gesendeten Liste handelt es sich ausschließlich um Indexdateien, die tatsächlichen Nutzdaten der Datenbank kommen dann noch obendrauf und daraus ergeben sich die 9,4 GB Gesamtverbrauch. Nicht benötigte Indizes könnten Sie in Ihrer Datenbank löschen, um den Speicherverbrauch zu reduzieren.

Beim aktuellen Ist-Zustand handelt es sich nicht um einen Fehler, ganz im Gegenteil war die vorherige Berechnung fehlerhaft und deswegen wurde zu ein zu geringer Speicherverbrauch angezeigt und nicht der reelle Verbrauch. Die 9,4 GB sind der tatsächlich benötigte Speicherbedarf der gesamten Datenbank.

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:

141M FTS_00000000006b9591_000000000086fcd6_INDEX_6.ibd
156M import_log_vbulletin_1.ibd
217M FTS_00000000006b9591_000000000086fccf_INDEX_1.ibd
525M FTS_00000000006b9591_000000000086fccf_INDEX_4.ibd
557M FTS_00000000006b9591_000000000086fccf_INDEX_3.ibd
573M FTS_00000000006b9591_000000000086fccf_INDEX_6.ibd
637M FTS_00000000006b9591_000000000086fccf_INDEX_5.ibd
801M FTS_00000000006b9591_000000000086fccf_INDEX_2.ibd
2.2G xf_search_index.ibd
2.4G xf_post.ibd

?