Moin,
von vergangener Woche Donnerstag bis heute hat sich unsere Datenbank im SW6 auf 10GB aufgebläht. Keine Ahnung wo das herkommt. Hat jemand eine Idee??
Grüße,
Stephan
Welche Tabellen sind denn betroffen? Was für Einträge stehen dort drin?
Etwas mehr Informationen wären hilfreich.
Moin Stephan,
schau doch mal rein und sag uns, welche Tabellen ungewöhnlich groß sind. Dann kann man sicher etwas dazu sagen.
VG Benjamin
Hallo @markus.klees , @Benjamin_Hummel
Sieht so aus, als ob alleine die Tabelle mit den Warenkörben knapp 5,5GB groß ist.
Dann nutzt du sehr wahrscheinlich ein Tool, was das Warenkorb Teilen erlaubt. Das erzeugt unendlich viele neue Warenkörbe durch Bots.
Du kannst das Löschintervall für die Warenkörbe per shopware.yaml heruntersetzen, so dass diese nicht mehr so lange, ich glaube 180 Tage, gespeichert werden.
Danke, ich habe die Datei einmal angelegt. Mal schauen was passiert.
Ich dachte die Warenkörbe werden automatisch nach 120 Tagen von SW6 selbst gelöscht.
Außerdem ist noch die Tabelle „product“ mit 1,7GB und die Tabelle „Cleverreach-entity“ mit 1,3GB in der Verlosung. Cleverreach Plugin ist nicht mehr installiert.
Da tut sich nichts. Muss ich das Script noch irgendie ausführen??
Wenn ich mich recht erinnere, dann wird das per Messages abgearbeitet. Das kann Ewigkeiten dauern. Wenn ich weiter nachdenke… unter Umständen war da eine Funktion, die Daten aggregiert hat, so dass es zu einem Memory Limit Engpass kam und die Löschfunktion überhaupt nicht ausgeführt wurde. Die Tabelle haben wir manuell gelöscht.
Schau mal in deinem Error Log, ob du Memory Limit Fehler findest.
Prüfe mal die Tabellen nach Fragmentierung:
select ENGINE,
TABLE_NAME,
Round( DATA_LENGTH/1024/1024) as data_length ,
round(INDEX_LENGTH/1024/1024) as index_length,
round(DATA_FREE/ 1024/1024) as data_free
from information_schema.tables
where DATA_FREE > 0
and TABLE_SCHEMA = hier den DB-Name eintragen
ORDER BY data_free DESC
Die Tabelle Cart wird ggf. ganz oben stehen, du kannst sie Optimieren (dauert je nach Größe etwas) mit:
OPTIMIZE TABLE cart;
Ich habe ein Addon drüber laufen lassen. Die Tabell eist nun lange nicht mehr so groß. Dann noch Cleverreach deinstalliert und schon ist alles „nur“ noch 2,5GB groß. Nur noch die Produkttabelle mit 1,7GB recht groß. Sind aber auch ~37000 Artikel in der DB.
1 „Gefällt mir“
Was für ein Addon hast du genutzt?
Also ich muss sagen hat mich auch gewundert weshalb nach der Migration von 5.4 auf 6.5 die Datenbank von 1.05 GB nach der Migration in SW6.5 2.9 GB und das kurz nach der Migration und das bei nur 2700 Artikel mit Varianten.
Warum gibt es eigentlich auch so viele 32 stellige Ids für jeden Artikel,Kategoien, Hersteller etc. in SW5 war das alles nicht so aufgebläht.
Ich hab auch festegestellt das die einfache Suche im Backend nach Artikelnummern eine Ewigkeit dauert im Vergleich zu SW5
Hi,
Shopware hat sich bei SW6 für die Umstellung auf UUID´s entschieden:
Viele Grüße
naja das find ich ja nicht so klasse, so werden z.B auch Produkturls mit der UUID angezeigt, https://www…com/detail/018bbf2d9810714096db890f36211088
Dasslebe ist mit den Import Export, aber das fing ja schon ab SW5.2 an als das Import/Export Modul
entfernt wurde, und es danach nicht mehr möglich war Produkte zusammen mit der Kategorie anzulegen im Klartext und nicht mit einer Katagorie ID wo ich zuerst die Kategorie anlegen muss und dann die ID dem Produkt matchen muss völlig umständlich, was bei einigen hunterten Kategorien nicht mehr möglich ist.
Auch der Export hier aus dem SW6.5 von den 2700 Artikel dautert ca 5 h und die Datei war dann 64Mb gross, im SW dauerte das 4 min und bei einer Grösse von 25Mb .VDS Server hat die gleiche Performance wobei der SW5 noch mit MySQL via Docker lief.
UUID haben Vor-, und Nachteile.
Man kann halt in der API die UUID eines Objekts erzeugen ohne vorher zu prüfen ob es sie schon gibt (weil eh"immer" eindeutig). Für uns Menschen sind die Dinger aber halt kompliziert und unhandlich. Und Datenbanken mögen sie auch nicht so sonderlich weil die „aktuellsten“ Einträge in Tabellen halt nicht nah beieinander sind sondern überall verteilt - was das cachen schwerer macht.
Ist halt ne Designentscheidung.
Ich persönlich finde ja dass man UUIDs einfach nicht überall hätte nutzen müssen. Für viele Objekte gibt es natürliche Unique IDs die sprechend sind, für Länder z.B. den eindeutigen ISO-Code. Auch für sowas wie Versionierung wäre halt ein simpler aufsteigender Integer doch viel einfacher gewesen.
Aber so isses halt nun, das kann man quasi nicht mehr umstrukturieren jetzt.
@StephanMetav
Das kommt von deinen Daten. 
Um die 5,5 GB Warenkörbe beneide ich dich wirklich… wobei entweder hast du extrem viele Kaufabbrüche oder halt einfach extrem viele Kunden.
(37.000 Artikel sind nicht so viel … habe hier 1,7 Mio, Tendenz steigend.)
Worauf ich hinaus will… selten sind hier wirklich „sinnlose“ Daten gespeichert, die einfach gelöscht werden können.
Viele (alte) Warenkörbe sehe ich ein… kannst du selbst, brauchst du kein Plugin kaufen:
DELETE FROM cart WHERE created_at <= "2022-01-01 00:00:00";
aber
Log-Einträge sollten nach der Korrektur gelöscht werden - nicht einfach so, gibt schließlich einen Grund für den Eintrag.
Version-Commit? Das sind vielleicht 10 MB, wenn es daran mangelt, sollte man den Server schnell umziehen.
@g73201113
Es kommt darauf an wie du suchst und wo bzw. welche Felder alle durchsucht werden - diese kannst du einstellen.
Muss in vielen Feldern gesucht werden, dann dauert das natürlich länger - suchst du nur in der Artikelnummer, dann geht das sehr schnell. (SW5 hat auch nicht alles durchsucht…)
Davon abgesehen kann ElasticSearch eine Bereicherung für den Admin-Bereich sein. 
Produkt-URLs sollten nicht mit UUID sichtbar sein, da läuft bei dir wohl etwas nicht ganz rund.
MySQL oder MariaDB? SW5 lief bestimmt nicht auf MySQL 8. 
@Teddie also ich meinte Artikelsuche Backend oben Artikelübersicht im Backend SW5 nur mit der Artikelnummer geht super schnell. Und die 2700 Artikel sind mit Varianten 24900
Und SW 5.4 läuft mit MySql 5.7 via Docker, funktionierte auch mit MariaDB aber dann funktioniert der Import mit dem alten Importmodul nicht mehr.
das mit den Produkt-URLs als UUID ist auch sehr komisch, scheinbar ist die Migration nicht ganz sauber gelaufen. Habe auch alles neu erstellen lassen via bin/console dal:refresh:index hat aber auch nichts geändert.
Muss ich alles wahrscheinlich nochmal machen.
Bezüglich Produkt-URLS schaue dir mal die SEO-Templates an. Eventuell ist hier ein Fehler, so dass diese nicht generiert werden können.
Bei der Migration brauchen auch die migrationsspezifische Tabellen einen nicht unerheblichen Speicherbedarf. Wird dann aber nach Abschluss gelöscht, sollte also das eine oder andere MB wegfallen.