CONTENIDO Forum

Das mit dem invalid SQL wegen der Statistik haben wir gerade geklaert. Ich habe aber nun in der errorlog von halchter.com noch mehr derartige Meldungen gefunden, wo ich den Fehler gerade nicht sehe und auch nicht weiss, in welchem Zusammenhang er aufgetreten ist. Die neue MySQL-Version ist laut Provider am 27.9. installiert worden, diese Fehlermeldungen sollten also nicht daher kommen.
Erstmal steht in der errorlog mehrmals eine solche Meldung:

Code: Alles auswählen

[23-Sep-2005 14:12:14] PHP Warning:  mysql_connect(): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) in /***/conlib/db_mysql.inc on line 76
[23-Sep-2005 14:12:14] connect(localhost, www09011, $Password) failed.
[23-Sep-2005 14:12:14] next_record called with no query pending.

Direkt danach kommt dann:

Code: Alles auswählen

[23-Sep-2005 14:12:28] Invalid SQL: SELECT
                            a.external_redirect AS ext
                        FROM
                            con_art_lang AS a,
                            con_cat_art AS b,
                            con_cat AS c
                        WHERE
                            b.idcat     = '32' AND
                            b.is_start  = '1' AND
                            c.idclient  = '1' AND
                            c.idcat     = b.idcat AND
                            a.idart     = b.idart AND
                            a.idlang    = '1'<br><br>
[23-Sep-2005 14:12:28] next_record called with no query pending.

und zwar mehrmals, mit unterschiedlichen b.idcat, allerdings mit derselben Uhrzeit, auf die Sekunde genau. Haengt das vielleicht mit dem vorherigen missglueckten connect zusammen?
emergence kann mir bestimmt sofort sagen, wo dieses SQL-Statement aufgerufen wird.

Ich kann mich nicht erinnern, schon mal einen solchen Eintrag gehabt zu haben.

Dann folgen noch weitere Eintraege mit invalid SQL, wo ich zumindest auf dem ersten Blick nicht sehe, was daran nicht ok ist. Vielleicht sieht jemand anders mehr:

Code: Alles auswählen

[23-Sep-2005 14:12:28] Invalid SQL: SELECT visited 
        FROM 
            con_cat_art AS A, 
            con_stat AS B 
        WHERE 
            A.idcatart = B.idcatart AND 
            A.idcatart = 68 AND 
            B.idlang = 1<br><br>
[23-Sep-2005 14:12:28] next_record called with no query pending.
[23-Sep-2005 14:12:28] Invalid SQL: SELECT C.visited AS archived 
        FROM 
            con_cat_art AS A, 
            con_stat_archive AS C 
        WHERE 
            A.idcatart = C.idcatart AND 
            C.idcatart = 68 AND 
            C.idlang = 1 AND 
            C.archived = 200508<br><br>
[23-Sep-2005 14:12:28] next_record called with no query pending.
[23-Sep-2005 14:12:28] Invalid SQL: SELECT 
            visited 
        FROM 
            con_cat_art AS A, 
            con_stat AS B 
        WHERE 
            A.idcatart = B.idcatart AND 
            A.idcatart = 68 AND 
            B.idlang = 1<br><br>
[23-Sep-2005 14:12:28] next_record called with no query pending.
[23-Sep-2005 14:12:28] Invalid SQL: SELECT sum(C.visited) AS archived 
        FROM 
            con_cat_art AS A, 
            con_stat_archive AS C 
        WHERE 
            A.idcatart = C.idcatart AND 
            C.idcatart = 68 AND 
            C.idlang = 1<br><br>
[23-Sep-2005 14:12:28] next_record called with no query pending.

Das System ist uebrigens ein c4.4.4.

Führe doch mal den Code in phpMyAdmin aus. Was für eine Fehlermeldung kommt da? Denn eigentlich ist das valid SQL, wenn ich nicht Tomaten auf den Augen habe.

Code: Alles auswählen

SELECT sum(C.visited) AS archived 
        FROM 
            con_cat_art AS A, 
            con_stat_archive AS C 
        WHERE 
            A.idcatart = C.idcatart AND 
            C.idcatart = 68 AND 
            C.idlang = 1

Gruß
HerrB

Annahme: Die Datenbank war kurzzeitig nicht erreichbar. Das erklärt die "fehlerhaften" SQL-Statements (technisch gesehen sind sie nicht fehlerhaft).

stimme timo da zu... da wird der mysql server nicht erreichbar gewesen sein...

@HerrB: hmm, da kommt auch nichts 'bei raus. Ich sehe aber auch keine idcatart=68 in con_stat_archive.

Was mir aber bei halchter.com aufgefallen ist, im Gegensatz zur anderen c4.4.4-Installation auf einem anderen Server: hier kommt in phpMyAdmin so eine Meldung:

Code: Alles auswählen

Notice: Undefined index: Type in /Pfad_zu_phpMyAdmin/tbl_properties_table_info.php on line 16

Ich hab's schon ins Forum des Providers gepostet, da hat sich aber noch keiner gemeldet.

Der Provider spielt sowieso mit meinen Nerven.

Jetzt bekomme ich schon

Code: Alles auswählen

Max execution time reached - script cancelled.
Maximale Ausführungszeit erreicht - Script wurde abgebrochen.

wenn ich mir die Statistiken angucken will ... Ich kontaktiere mal den Provider ...

da hat dein provider vermutlich auch gleich ein php upgrade gemacht, das vielleicht nicht perfekt konfiguriert wurde

ICH BRINGE IHN UM. Ich chatte gerade mit dem technischen Support. Die Domain wurde gesperrt, weil angeblich SQL Amok laeuft.

Wir haben die Seite gesperrt da zuviele MySQL Anfragen unseren Server lahm gelegt haben. Bitte beheben Sie das Problem und setzen sie sich dann wieder mit uns in Verbindung.

SELECT SUM(visited) FROM con_cat_art AS A, con_stat_archive AS B WHERE A.idcatart=B.idcatart AND A.i |
oder
SELECT visited FROM con_cat_art AS A, con_stat_archive AS B WHERE A.idcatart=B.idcatart AND A.idcat= |

Er schrieb noch:

Die maximale Auführungszeit liegt bei 90 Sekunden das CPU Limit liegt bei 10 Sekunden. Die Speicherbegrenzung liegt bei 32 MB. Unsere Scriptlimitierung werden nicht in der PHP.ini gespeichert.

Das muesste doch reichen, oder?

Die maximale Auführungszeit liegt bei 90 Sekunden das CPU Limit liegt bei 10 Sekunden. Die Speicherbegrenzung liegt bei 32 MB. Unsere Scriptlimitierung werden nicht in der PHP.ini gespeichert.

Ja, ist üblich.

Gruß
HerrB

Also an den 10 Sekunden CPU-time kann's auch nicht liegen? Woran denn dann? Der hat mir erstmal die Domain freigeschaltet, ich darf mir aber die Statistik (zumindest im Augenblick) nicht mehr angucken, weil die dazugehoerige SQL-Anweisung angeblick Amok laeuft. Das kann's doch nicht sein! Einen Fehler ihrerseits schliessen sie aus, ich soll doch bitte schoen mein CMS ueberpruefen.
Es wurde uebrigens nur MySQL upgedatet, PHP angeblich nicht.

Ich erinnere mich jetzt wieder dunkel, dass ich bei halchter.com ein Problem mit der con_stat_archive hatte, weil da unheimlich viele Eintraege drin waren (keine Ahnung, wodurch das verursacht wurde). Ich habe jetzt nochmal nachgeschaut, die Tabelle hat 331496 gegenueber den 2611 von der anderen Contenido-Installation. Ich versuche mal, die Tabelle etwas aufzuraeumen, das wird lustig bei der Anzahl Datensaetze.

Aber das wirkt sich ja auch auf die DB-Groesse aus, also muss ich da was machen.

Also an den 10 Sekunden CPU-time kann's auch nicht liegen?

Nein, bzw. wenn, dann haben sie Recht. Die 10 Sekunden bedeuten, dass das Skript exklusiv 10 Sekunden CPU-Rechenzeit verbraucht (d.h. bei einem Shared-Server: Auch für alle anderen Nutzer verbrätst Du gerade die CPU-Zeit).

Das passiert aber nur dann, wenn das Skript ohne Pause rechnet - sehr unwarscheinlich. Die 90 Sekunden gelten für die Gesamtausführung des Skripts. D.h. ein PHP-Skript, welches 84 Sekunden auf das Ergebnis der SQL-Abfrage wartet und 5 Sekunden das Ergebnis durchrechnet, wird noch ausgeführt...

Gruß
HerrB

Halchteranerin hat geschrieben:Ich erinnere mich jetzt wieder dunkel, dass ich bei halchter.com ein Problem mit der con_stat_archive hatte, weil da unheimlich viele Eintraege drin waren (keine Ahnung, wodurch das verursacht wurde). Ich habe jetzt nochmal nachgeschaut, die Tabelle hat 331496 gegenueber den 2611 von der anderen Contenido-Installation. Ich versuche mal, die Tabelle etwas aufzuraeumen, das wird lustig bei der Anzahl Datensaetze. Aber das wirkt sich ja auch auf die DB-Groesse aus, also muss ich da was machen.

hmm... da fällt mir nur ein grund ein warum es zu diesen 300.000 einträgen kommen kann...

annahme:
das datum der letzten cronjob ausführung wird ja in cronjobs/move_old_stats.php.job gespeichert... (und beinhaltet das datum vom letzten monat)
und jetzt nehmen wir an die datei hat keine korrekten berechtigungen (sprich php kann das neue ausführungsdatum nicht eintragen)
wird bei jedem! aufruf der front_content.php dieser cronjob ausgeführt...
damit explodiert die anzahl der einträge in der con_stats_archiv

bei dieser anzahl von einträgen kann die cpu zeit locker länger wie 10 sekunden sein...
somit kann ein sql query reichen, genau das problem zu bekommen das du jetzt hast...

ich würd mir einfach mal die datei berechtigungen der *.job dateien ansehen (auch gruppen berechtigungen)

Das Verzeichnis cronjobs hat 777 und die Dateien darin 666. Ist doch "eigentlich" ok, oder?

Ich kam vorhin auf die glorreiche Idee, eine Tabellenreparatur zu probieren.

Da schrumpfte schon mal die Tabelle von 12,7 MB (!) auf 210 KB bei etwas ueber 5000 Eintraegen. Aber es dauert mir immer noch zu lange, wenn ich mir die Statistik im Backend angucken will. Meine Befuerchtung ist einfach, dass es nicht sehr lange dauert und ich wieder die max_execution_time erreiche.

CONTENIDO Forum

noch mehr invalid SQL ...

noch mehr invalid SQL ...