Moin, ab und zu muss man ja mal den Cache leeren, doch wenn ich dies mache, legt mir Shopware den Server lahm und es kommt zu einem 500 Error. Ich gehe davon aus das es daran liegt das der Suchindex neu aufgebaut wird. Folgende Beispiel Query legt den Server lahm: SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚2wege‘ OR s.searchterm LIKE CONCAT(‚2wege‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚2wege‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚2wege‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚manueller‘ OR s.searchterm LIKE CONCAT(‚manueller‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚manueller‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚manueller‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚wilkins‘ OR s.searchterm LIKE CONCAT(‚wilkins‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚wilkins‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚wilkins‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚2wegelautsprecher‘ OR s.searchterm LIKE CONCAT(‚2wegelautsprecher‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚2wegelautsprecher‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚2wegelautsprecher‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚marantz‘ OR s.searchterm LIKE CONCAT(‚marantz‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚marantz‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚marantz‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚max150‘ OR s.searchterm LIKE CONCAT(‚max150‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚max150‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚max150‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚max250‘ OR s.searchterm LIKE CONCAT(‚max250‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚max250‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚max250‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚mattschwarz‘ OR s.searchterm LIKE CONCAT(‚mattschwarz‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚mattschwarz‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚mattschwarz‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) UNION ALL ( SELECT s.searchterm, COUNT(*) as relevance, MAX(s.datum) as date, (SELECT results FROM s_statistics_search WHERE searchterm=s.searchterm AND id=MAX(s.id)) as results FROM s_statistics_search s WHERE s.searchterm NOT LIKE ‚2wege manueller wilkins‘ AND ( s.searchterm LIKE ‚mahagoni‘ OR s.searchterm LIKE CONCAT(‚mahagoni‘, ’ %’) OR s.searchterm LIKE CONCAT(’% ‚, ‚mahagoni‘) OR s.searchterm LIKE CONCAT(‘% ‚, ‚mahagoni‘, ’ %‘) ) AND results > 0 GROUP BY s.searchterm ) ORDER BY relevance DESC, results DESC LIMIT 8: Den Support habe ich bereits letzte Woche dazu angeschrieben, leider aber keine Antwort erhalten. Vielleicht hat ja einer von Euch eine Idee was das Problem ist. wie gesagt, das Problem tritt nur auf, wenn ich auf -> Caches / Performance gehe, auf alle auswählen gehe und dann auf leeren. Danach ist der Server komplett lahm gelegt. Artikelanzahl ca. 3000 Stück
Hi, worüber hast du den Support kontaktiert? Über den Shopware Account? Leere mal deine Datenbanktabelle s_statistics_search (truncate) Dann ist das System wieder flott. Vermutlich ist die Statistik-Tabelle extrem groß bei dir. Dafür gibt es auch einen Cleanup-Cronjob in Shopware, der die Tabelle in Abständen ebenfalls aufräumt (CronRefresh). Sebastian
Cron Refresh gibt es ja mehrere, welcher soll denn dafür zuständig sein? Sonst macht es ja keine Probleme, nur nachdem ich den Cache gelöscht habe, dann wird der komplette Server lahm gelegt, und das teilweise für mehrer Stunden!
Hi, genau gesagt geht es um diesen Job: http://wiki.shopware.com/_detail_698.html Abhilfe schafft aber sofort, wenn du die o.g. Tabelle einmal leerst. Dort wir jede einzelne Suchanfrage protokolliert, was zu großen Tabellen führen kann. Also einmal leeren und dann Cache leeren. Auch die Suchanfragen im Frontend sollte das wieder sehr sehr schnell erfolgen Sebastian
Hallo, Aufräumen: Shopware_CronJob_Clearing würde ich sagen.
[quote=“drakon”]Hallo, Aufräumen: Shopware_CronJob_Clearing würde ich sagen.[/quote] und der ist aktiv und wurde heute um 12:35 auch ausgeführt
Und Tabelle wurde manuell einmal geleert?
ja, habe ich jetzt manuell einmal geleert, aber wie kommt das? Die Cronjobs werden ordnungsgemäß ausgeführt und dann nach dem cache leeren bricht der Server zusammen weil er mit den querys überlastet ist. sooo klein ist der Server auch nicht den wir nutzen
Hallo, ist bei dir das Plugin „CronRefresh“ installiert? Hier reicht nicht nur der Cronjob, das Plugin muss auch installiert sein. Dann müsstest du einmal prüfen, dass die Cronjobs „Aufräumen“, „RefreshSearchIndex“ und „Search“ durchlaufen. Das Plugin sorgt dafür, dass alle Einträge die älter als 30 Tage sind gelöscht werden. Je nach Suchaufkommen, kann es hier aber auch schon vorher zu einer großen Tabelle kommen. Das müsste man einmal genau prüfen, also Tabelle leer machen und dann mal schauen wie die Tabelle in den nächsten Tagen anwächst. Sollte Sie sehr schnell sehr groß werden, dann gibt es die Möglichkeit den Intervall über eine kleine Anpassung des Plugins runter zu setzen. Viele Grüße Moritz
ja, CronRefresh ist aktiv, Cronjobs laufen auch durch, nur scheinbar wächst die Tabelle doch sehr schnell an, würde das gerne auf 14 Tage runtersetzen, damit die Performance wieder etwas besser wird. Was muss ich denn anpassen? Woher kommen denn die Daten aus der s_statistic_search ? die scheinen mir doch sehr wirr zu sein, als Beispiel: “2wegewandlautsprecherboxenpaar da wilkins” und nur solche Sachen, also keine wirklichen logischen Suchbegriffe Wir haben auch die intelligente Suche von Euch installiert, kann es damit zusammenhängen? Ich finde sowieso das die intelligente Suche bei uns sehr langsam läuft. Irgendwo ist bei der ganzen Sache der Wurm drin. Die suggest Vorschläge die gemacht werden, sind auch ziemlich wirr, werden die aus dieser Tabelle gezogen? Sie sehen viele Fragen 
[quote=“Moritz Naczenski”]Hallo, ist bei dir das Plugin “CronRefresh” installiert? Hier reicht nicht nur der Cronjob, das Plugin muss auch installiert sein. Dann müsstest du einmal prüfen, dass die Cronjobs “Aufräumen”, “RefreshSearchIndex” und “Search” durchlaufen. Das Plugin sorgt dafür, dass alle Einträge die älter als 30 Tage sind gelöscht werden. Je nach Suchaufkommen, kann es hier aber auch schon vorher zu einer großen Tabelle kommen. Das müsste man einmal genau prüfen, also Tabelle leer machen und dann mal schauen wie die Tabelle in den nächsten Tagen anwächst. Sollte Sie sehr schnell sehr groß werden, dann gibt es die Möglichkeit den Intervall über eine kleine Anpassung des Plugins runter zu setzen. Viele Grüße Moritz[/quote] Ok, habe es jetzt lange verfolgt, und das problem ist das die Tabelle zu schnell anwächst, ich würde gerne den Intervall auf 10 Tage setzen, das reicht völlig, wie und was muss ich anpassen damit der die Tabelle alle 10 Tage leert?
Hallo, Der CronRefresh liegt im Shopware Verzeichnis unter: engine/Shopware/Plugins/Default/Frontend/CronRefresh/Bootstrap.php dort findest du die Zeile: DELETE FROM s\_statistics\_search WHERE datum \< date\_add(current\_date, interval -30 day) Die kannst du nach deinen wünschen Anpassen und so z.B. die -30 day durch ein -10 day ersetzen. Danach sollten die Einträge schon nach 10 Tagen durch den Cronjob gelöscht werden. Viele Grüße Moritz
genau das habe ich auch gerade entdeckt und bereits angepasst. Ist das update sicher? Nicht das mir das beim nächsten update wieder übergebügelt wird. Danke für den Tipp!
Hallo, updatesicher ist das nicht. Allerdings wurde an diesem Plugin auch seit erscheinen von Shopware 4 nichts mehr angepasst. Die Core-Plugins werden nur in seltenen Fällen angepasst, hier müsstest du höchstens einmal in das Update-Paket rein schauen ob das Plugin dort enthalten ist. Grüße Moritz