con_stat_archive ist riesig -> 185 MB!!!!

[llaron]

Hallo,

meine Tabelle con_stat_archive hat ne Größe von 185 MB! Die Seite ist 3 sprachig und erst seit ca. 2 Monaten online. Wie kann das passieren?

Kann ich diese Tabelle einfach leeren, ohne das Probleme auftreten...außer das dann die Statistiken weg sind?

Merci + Gruß
Nico

[maveric2001]

is ne tbl fuer statistik. hast also viel traffic?

[llaron]

ne, so viel traffic ist das nicht. also kan ich die ohne bedenken leeren?

[maveric2001]

laut contenido db-model sind con_stat_archive und con_stat fuer statistik reserviert, eigentlich ergo -> LEEREN kein prob.

zu bedenken waere da aber das dies model Version 4.4.x vom 15.06.2004 ist!!!!! soviel wieder zum thema doku

[wosch]

Im Archiv sind die Statistiken der vergangenen Monate.
Wenn sie seit 2 Monaten Online ist können da max. 2 Monate archviert sein.
Ein Gedankenspiel:
Wenn jeder Seitenaufruf 10Kb Speicherplatz in der Tabelle kosten würde:
wären das bei 185 MB = 18.500 Aufrufe in sehr knapp 2 Monaten

Ich trau mich ja fast nicht zu fragen: nicht doch 1,8 MB?

[Dodger77]

Ich trau mich ja fast nicht zu fragen: nicht doch 1,8 MB?

Doch, das kann schon sein:

http://www.contenido.org/forum/viewtopi ... tatarchive

@llaron: Schau dir den Thread mal an.

[wosch]

Doch, das kann schon sein:

Hoppla.

Aber was ich nicht verstehe, was haben cronjobs mit den Einträgen zu tun?
Monatlich werden die Statitik-Einträge verschoben, o.k.
Aber warum wird in das Statistik-Archiv geschrieben wenn die cronjobs nicht die richtigen Rechte haben?

[Dodger77]

Aber was ich nicht verstehe, was haben cronjobs mit den Einträgen zu tun?
Monatlich werden die Statitik-Einträge verschoben, o.k.
Aber warum wird in das Statistik-Archiv geschrieben wenn die cronjobs nicht die richtigen Rechte haben?

Ganz einfach. Der Contenido-Pseudocron merkt sich den Zeitpunkt des Ausführens eines einzelnen Cronjobs dadurch, dass er in eine jeweilige ".job"-Datei den Timestamp schreibt. Ist keine Datei vorhanden, legt er eine an. Kann keine angelegt werden (keine Schreibrechte für den Ordner), versucht er das immer wieder und führt das Script auch immer aus. Wurden die ".job"-Dateien bereits in der Vergangenheit erzeugt, lassen sich aber seit einiger Zeit nicht mehr schreiben, passiert das gleiche.

[emergence]

hmm...
ich mach da jetzt mal nen bug draus...

zwei sachen...

erstens:
functions.stat.php - function statsArchive
sollte nur ausgeführt werden falls $yearmonth noch nicht in $cfg["tab"]["stat_archive"] existiert...

könnte man zu beginn der funktion ergänzen...

zweitens:
eine fehlermeldung in pseudo-cron.inc.php auslösen falls keine schreibberechtigungen gegeben sind...

verschoben...