catalog verursacht slow-queries und 100fache Serverlast

[Fryd]

Hallo zusammen,

meine catalog-Instalation verursacht seit heute Nacht "slow queries", bei denen 357 Mio Zeilen verarbeitet und 1-7 Zeilen zurückgegeben werden. Die Anzahl der Zeilen in den catalog-Tabellen (Datenbank) liegt zwischen 0 und 3.700 (tag_rel).

Im cgi-Debugger finde ich solche Queries:

Es werden mit Filter Veranstaltungen angefragt. So etwas wie "v_bundesland18" gibt es eigentllich nicht. Es gibt nur die Variable "v_bundesland".

SELECT SUM(FIND_IN_SET(18,v_bundesland)) AS v_bundesland18, SUM(FIND_IN_SET(19,v_bundesland)) AS v_bundesland19, SUM(FIND_IN_SET(20,v_bundesland)) AS v_bundesland20, SUM(FIND_IN_SET(21,v_bundesland)) AS v_bundesland21, SUM(FIND_IN_SET(22,v_bundesland)) AS v_bundesland22, SUM(FIND_IN_SET(23,v_bundesland)) AS v_bundesland23, SUM(FIND_IN_SET(24,v_bundesland)) AS v_bundesland24, SUM(FIND_IN_SET(25,v_bundesland)) AS v_bundesland25, SUM(FIND_IN_SET(26,v_bundesland)) AS v_bundesland26, SUM(FIND_IN_SET(27,v_bundesland)) AS v_bundesland27, SUM(FIND_IN_SET(28,v_bundesland)) AS v_bundesland28, SUM(FIND_IN_SET(29,v_bundesland)) AS v_bundesland29, SUM(FIND_IN_SET(30,v_bundesland)) AS v_bundesland30, SUM(FIND_IN_SET(31,v_bundesland)) AS v_bundesland31, SUM(FIND_IN_SET(32,v_bundesland)) AS v_bundesland32, SUM(FIND_IN_SET(33,v_bundesland)) AS v_bundesland33, SUM(FIND_IN_SET(61,v_bundesland)) AS v_bundesland61, SUM(FIND_IN_SET(53,v_bundesland)) AS v_bundesland53 FROM cat_veranstaltungen WHERE v_beginn>unix_timestamp() and v_freigabe=1 and v_komplett=1 AND v_burlaub=0 AND v_cme=0 AND id IN (SELECT DISTINCT(itemid) FROM tl_catalog_tag_rel WHERE fieldid=10 AND itemid IN (SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=10 AND valueid=58 AND itemid IN(SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=10 AND valueid=58)) AND valueid IN (58)) AND id IN (SELECT DISTINCT(itemid) FROM tl_catalog_tag_rel WHERE fieldid=20 AND itemid IN (SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=20 AND valueid=11 AND itemid IN(SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=20 AND valueid=11)) AND valueid IN (11))

Es kann sein, dass dies mit Google-Abfragen zusammenhängt. Jedenfalls treibt das die Serverlast zeitweise um den Faktor 100 hoch.
Heute Nacht habe ich die FormAuto-Erweiterung installiert. Dabei wurde auch die DC-DynamicTable von Built17 auf B21 aktualisiert.

Ist es ratsam, IMMER auf die unter "verfügbar" genannten Versionen / Builts zu aktualisieren?
Auch wenn im Erweiterungskatalog eine niedrigere Version angegeben ist (z.B. backend_tabletree: catalog braucht 0.1.1)?

Sieht jemand in seiner Kristallkugel, ob sich das Slow-Query-Problem durch die Aktualisierungen löst?
Oder liegt das Problem woander?
Wie kommen überhaupt so irre Abfragen zustande?

Herzliche Grüße
Fryd


Dies ist zur Zeit drauf:

contao: Version 2.9.5 mit Sicherheitspatch 2

catalog: Version 2.0.0 beta2 Built 20 (verfügbar: Built 74)
backend_filterwiz: 0.1.2 Built 7 (verfügbar: Built 10)
backand_tabletree: 0.1.2 Built 9 (verfügbar: 0.1.3 Built 16)
DC_DynamicTable: 0.1.0 Built 21 (vorher 17)
taxonimy: 0.1.8 Built 6 (verfügbar: Built 10)

Die vom catalog abhängigen Erweiterungen sind:

catalogajaxratingfield: 2.0.0 beta1 Built 20
catalogitemhitsfield: 2.0.0 beta1 Built 19 (verfügbar: Built 20)
catalogitemuseridfield: 2.0.0 beta2 Built 5 (verfügbar: Built 8)
catalomultitextwizardfield: 2.0.0 beta1 Built 17 (verfügbar: Built 19)
catalognotelist: 2.0.0 beta2 Built 7 (verfügbar: Built 9)

[Fryd]

Update hat wohl nicht geholfen

Hallo zusammen,

inzwischen habe ich die Catalogerweiterung aktualisiert (sieh unten). Trotzdem gibt es SlowQuerys, zur Zeit von 12 Sekunden mit 9,4 Mio verarbeiteten Zeilen. Sie betreffen immer die gleiche cat_Tabelle und wiederholen sich mit geringen Abweichungen in einigen Werten.

Was kann ich tun???

Grüße
Fryd

SELECT DISTINCT(v_bundesland) FROM cat_veranstaltungen WHERE v_beginn>unix_timestamp() and v_freigabe=1 and v_komplett=1 AND id IN (SELECT DISTINCT(itemid) FROM tl_catalog_tag_rel WHERE fieldid=10 AND itemid IN (SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=10 AND valueid=38 AND itemid IN(SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=10 AND valueid=38)) AND valueid IN (38))

SELECT SUM(FIND_IN_SET(18,v_bundesland)) AS v_bundesland18, SUM(FIND_IN_SET(19,v_bundesland)) AS v_bundesland19, SUM(FIND_IN_SET(20,v_bundesland)) AS v_bundesland20, SUM(FIND_IN_SET(21,v_bundesland)) AS v_bundesland21, SUM(FIND_IN_SET(22,v_bundesland)) AS v_bundesland22, SUM(FIND_IN_SET(23,v_bundesland)) AS v_bundesland23, SUM(FIND_IN_SET(24,v_bundesland)) AS v_bundesland24, SUM(FIND_IN_SET(25,v_bundesland)) AS v_bundesland25, SUM(FIND_IN_SET(26,v_bundesland)) AS v_bundesland26, SUM(FIND_IN_SET(27,v_bundesland)) AS v_bundesland27, SUM(FIND_IN_SET(28,v_bundesland)) AS v_bundesland28, SUM(FIND_IN_SET(29,v_bundesland)) AS v_bundesland29, SUM(FIND_IN_SET(30,v_bundesland)) AS v_bundesland30, SUM(FIND_IN_SET(31,v_bundesland)) AS v_bundesland31, SUM(FIND_IN_SET(32,v_bundesland)) AS v_bundesland32, SUM(FIND_IN_SET(33,v_bundesland)) AS v_bundesland33, SUM(FIND_IN_SET(61,v_bundesland)) AS v_bundesland61, SUM(FIND_IN_SET(53,v_bundesland)) AS v_bundesland53 FROM cat_veranstaltungen WHERE v_beginn>unix_timestamp() and v_freigabe=1 and v_komplett=1 AND id IN (SELECT DISTINCT(itemid) FROM tl_catalog_tag_rel WHERE fieldid=10 AND itemid IN (SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=10 AND valueid=38 AND itemid IN(SELECT itemid FROM tl_catalog_tag_rel WHERE fieldid=10 AND valueid=38)) AND valueid IN (38))

Dies ist zur Zeit drauf:

contao: Version 2.9.5 mit Sicherheitspatch 2

catalog: Version 2.0.0 beta2 Built 74
backend_filterwiz: 0.1.2 Built 10
backand_tabletree: 0.1.2 Built 9 (verfügbar: 0.1.3 Built 16)
DC_DynamicTable: 0.1.0 Built 21
taxonimy: 0.1.8 Built 10

Die vom catalog abhängigen Erweiterungen sind:

catalogajaxratingfield: 2.0.0 beta1 Built 20
catalogitemhitsfield: 2.0.0 beta1 Built 20
catalogitemuseridfield: 2.0.0 beta2 Built 8
catalomultitextwizardfield: 2.0.0 beta1 Built 19
catalognotelist: 2.0.0 beta2 Built 9

[MacKP]

Hallo Fryd,
ich seh mir immer noch jeden einzelnen Thread hier im Forum an. Von daher brauche ich immer noch keine PM um mir einen Thread anzuschauen ;-)

Hmm in Contao gab es eh mal das Problem, das bei Seiten die nen 404 Ausgeben zum Teil massiv Ressourcen genutzt wurden. Leo Unglaub hatte dazu mal das ein oder andere geschrieben soweit ich weiß. Versuch einfach mal herauszufinden, wie Google auf solche URLs kommt und versuch diese Fehlerquelle auszuschließen.

Mehr Tipps kann ich dir da auch nicht geben.. außer eventuell auf MetaModels zu wechseln ;-)

Viele Grüße

[Fryd]

Sorry für die PM. Wenn der Stresspegel steigt, dann ...


Ich habe jetzt die Weblogs von gestern:

66.249.66.20 - - [17/Feb/2014:14:15:14 +0100] "GET /aktuelles_veranstaltungen_uebersicht/v_zielgruppe/zg_koord/v_bundesland/bl_by/v_burlaub/false/v_land/nl_de/v_kategorie/kat_fortbi.html?page=2 HTTP/1.1" 504 495 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Wenn ich das richtig sehe, ist es eine "normale" Katalogabfrage über das Filtermodul. Es werden immer "Variable/Wert" aufgeführt. Die Suche geht über ca. 100 Einträge.

Einen Wechsel zu MetaModels habe ich auf dem Schirm. Ich verwende aber das Frontend-Editing beim Katalog (Veranstalter geben ihre eigenen Veranstaltungen selbst ein und können diese ändern). Da muss ich wohl noch ein wenig warten ...

Grüße
Fryd

[Fryd]

Das Problem ist gelöst. Die oben aufgeführten Datenbankabfragen sind wohl normal.

Das Problem war durch das Kopieren der Installation verursacht worden. Das Löschen der temporären Dateien brachte keine Änderung im Lastverhalten. Im Nachhinein vermute ich aber, dass die schon abgesetzten Queries mit Antwortzeiten von 40 Minuten dafür verantwortlich waren. Letztendlich war das Löschen der temporären Dateien aber die Lösung.

Grüße
Fryd