Probleme mysql connections

[chr.flader]

Hallo!

habe folgende Mail vom Provider bekommen:

Die Domain xxx öffnet unendlich viele mysql connections(zuletzt
394! benötigt wird in der Regel nur 1-3 pro Präsenz) und schließt diese
mit Sicherheit nicht so das es zum absturz alle mysql abhängigen Dienste
kommt. Wir haben die Site jetzt deaktiviert, teilen Sie uns mit wenn Sie
alle Fehler behoben haben damit wir die Site wieder aktivieren können.

Verwende den Newsletter Avisota. Denke es könnte auch hieran liegen.

Jemand vielleicht einen Tipp?

Danke
Christian

[andreasisaak]

Welche Extensions hast du noch installiert? Liste bitte mal alle auf.

[chr.flader]

Hi Andreas,

danke für die Antwort/Frage.
Kommt gleich ...

Ich muss erstmal ne Übersicht machen.
Der Support teilte mir mit, dass die DB auf gute 10 GB angewachsen sei und alle Seiten auf den Server lahmgelegt hat.

[chr.flader]

Anbei die Übersicht.

Hoffe jemand kann mir helfen ....

[andreasisaak]

Da könnten mehrere Extensions schuld sein.
Wieso ist die DB 10GB groß? Schau bitte mal rein und such die schuldige Tabelle.

[MacKP]

Du solltest auch mal in der localconfig.php gucken, ob du persistente DB Verbindungen eingeschaltet hast. Wenn das auf false ist, macht Contao immer wieder neue auf.

Viele Grüße

[chr.flader]

Komischerweise ist mein letztes Backup nicht so groß (19,9 MB).
Der Provider kann mir die übertrieben große dump-Datei auch nicht zur Verfügung stellen.

[andreasisaak]

Du wirst doch wohl Zugriff auf die DB haben? phpMyAdmin etc?

[chr.flader]

Hier meine localconfig.php:

### INSTALL SCRIPT START ###
$GLOBALS['TL_CONFIG']['websitePath'] = '';
$GLOBALS['TL_CONFIG']['licenseAccepted'] = true;
$GLOBALS['TL_CONFIG']['installPassword'] = '***';
$GLOBALS['TL_CONFIG']['installCount'] = 0;
$GLOBALS['TL_CONFIG']['encryptionKey'] = '***';
$GLOBALS['TL_CONFIG']['dbDriver'] = 'MySQL';
$GLOBALS['TL_CONFIG']['dbHost'] = 'mysql5.pop-i.de';
$GLOBALS['TL_CONFIG']['dbUser'] = '***';
$GLOBALS['TL_CONFIG']['dbPass'] = '***';
$GLOBALS['TL_CONFIG']['dbDatabase'] = '***';
$GLOBALS['TL_CONFIG']['dbPconnect'] = false;
$GLOBALS['TL_CONFIG']['dbCharset'] = 'UTF8';
$GLOBALS['TL_CONFIG']['dbPort'] = 3306;
$GLOBALS['TL_CONFIG']['adminEmail'] = '***';
$GLOBALS['TL_CONFIG']['rewriteURL'] = true;
$GLOBALS['TL_CONFIG']['allowedTags'] = '<a><abbr><acronym><address><area><b><big><blockqu ote><br><base><bdo><button><caption><cite><code><c ol><colgroup><dd><del><div><dfn><dl><dt><em><form> <fieldset><hr><h1><h2><h3><h4><h5><h6><i><img><inp ut><ins><label><legend><li><link><map><object><ol> <optgroup><option><p><pre><param><q><select><small ><span><strong><sub><sup><style><table><tbody><td> <textarea><tfoot><th><thead><tr><tt><u><ul>';
$GLOBALS['TL_CONFIG']['defaultChmod'] = 'a:9:{i:0;s:2:"u1";i:1;s:2:"u2";i:2;s:2:"u3";i:3;s :2:"u4";i:4;s:2:"u5";i:5;s:2:"u6";i:6;s:2:"g4";i:7 ;s:2:"g5";i:8;s:2:"g6";}';
$GLOBALS['TL_CONFIG']['latestVersion'] = '2.11.9';
$GLOBALS['TL_CONFIG']['dateFormat'] = 'd.m.Y';
$GLOBALS['TL_CONFIG']['datimFormat'] = 'd.m.Y';
$GLOBALS['TL_CONFIG']['displayErrors'] = false;
$GLOBALS['TL_CONFIG']['minPasswordLength'] = '3';
$GLOBALS['TL_CONFIG']['disableRefererCheck'] = true;
$GLOBALS['TL_CONFIG']['cron_monthly'] = 201303;
$GLOBALS['TL_CONFIG']['cron_weekly'] = 201311;
$GLOBALS['TL_CONFIG']['cron_daily'] = 20130311;
$GLOBALS['TL_CONFIG']['cron_hourly'] = 2013031111;
$GLOBALS['TL_CONFIG']['maxFileSize'] = 99999999;
$GLOBALS['TL_CONFIG']['secureDNS'] = 'auto';
$GLOBALS['TL_CONFIG']['avisota_chart_highstock'] = true;
$GLOBALS['TL_CONFIG']['websiteTitle'] = 'Installateur SH';
$GLOBALS['TL_CONFIG']['avisota_chart_highstock_confirmed'] = true;
$GLOBALS['TL_CONFIG']['uploadTypes'] = 'jpg,jpeg,gif,png,ico,csv,doc,docx,xls,xlsx,ppt,pp tx,odt,ods,odp,pdf,mp3,mp4,m4a,m4v,webm,ogg,wma,wm v,ram,rm,mov,fla,flv,swf,css,html,htm,txt,zip,cto, imt';
$GLOBALS['TL_CONFIG']['repository_unsafe_catalog'] = true;
### INSTALL SCRIPT STOP ###

[chr.flader]

Du wirst doch wohl Zugriff auf die DB haben? phpMyAdmin etc?

Die haben sie auf meinen Wunsch hin ersteinmal zurückgesetzt.
Ich habe jetzt ein komplettes Backup und werde es mal Local versuchen.

[MacKP]

Ah, das hier ist der Eintrag den ich meinte:

$GLOBALS['TL_CONFIG']['dbPconnect'] = false;

Scheint soweit erst mal ok...

Viele Grüße

[lindesbs]

Wenn Du einen phpmyadmin zur Hand hast, kannst Du schnell sehen, welche Tabellen da so gross sind.
Das waere erstmal der bessere Anfang gewesen.

[chr.flader]

Ersteinmal Danke an Euch!

ich muss mal testen was passiert wenn ich einfach das Backup local bei mir zuhause installiere.

Christian

[chr.flader]

Habe gerade noch einmal mit dem Proiver telefoniert.

Er sagt, dass die 'tl_search' extrem groß gewesen ist.

Hilft es vielleicht?

[chr.flader]

Anbei nur die tl_search als Anhang. Ist wirklich etwas viel drin. das Backup stammt vom 11.02.
Wenn man das hochrechnet und er nie löscht ...

[lindesbs]

Entferne bitte mal den Download. Das geht keinen was an.
Und 2 MB ist nu wirklich nicht gross.

[chr.flader]

Entferne bitte mal den Download. Das geht keinen was an.
Und 2 MB ist nu wirklich nicht gross.

Dort stand doch nix schlimmes drin oder?

[lindesbs]

NU ja, im eigentlichen Sinne schon. Es koennen zum Beispiel auch Texte enthalten sein, die nur fuer andere Benutzergruppen ersichtlich sein solten.

[chr.flader]

ok, zurück zum Thema, immerhin ist die Seite offline solange bis ich den Fehler gefunden habe!

Wie sieht es mit Fullbackup aus? Ich habe das Script vor ca. 3 Wochen installiert. Dieses macht ein automaisches Backup und legt dieses auf den Server ab.
Speichert das auch in der DB?

[lindesbs]

Nein, das erstellt nur ein Backup. Aber wieso ist die Seite offline ?

Du schriebtest

Die haben sie auf meinen Wunsch hin ersteinmal zurückgesetzt.

Also sollte sie doch erstmal wieder da sein.

Und dann musst du quasi nur noch im Backend kontrollieren (Wartungscenter) wie sich die Groessen verhalten.
Evt. mal nicht alle Seiten indizieren lassen. Bzw. die Suche ausschalten, wenn du sie nicht explizit benoetigst.

[chr.flader]

Die DB ist leer.
Ich muss das Backup jetzt einspielen ...

[chr.flader]

Hi zusammen!

Die Seite läuft wieder, aber sehr, sehr langsam!

in der log Error habe ich folgende Zeile über mehrere Wochen als Fehler festgestellt:
[19-Jul-2012 21:13:28] PHP Warning: Division by zero in /web4Data/var/www/installateur-sh/html/system/modules/listing/ModuleListing.php on line 167


was genau passiert das und könnte das der Fehler sein?

Danke

Christian

[andreasisaak]

Verwendest du denn irgendwo das Modul "Auflistung"? Wenn nicht, dann deaktiviere es erstmal.

[chr.flader]

Doch fast überall.

Die Mitglieder (Betriebe) werden entsprechend an Hand einer ID, welche ich ins Feld Vorname geschrieben habe ausgelesen.
Allerdings werden die problemlos geöffnet:
http://www.installateur-sh.de/innungsbetriebe-333.html
Hat jemand Lust mal ins BE zu schauen?

[chr.flader]

Hi, angeblich soll dieses Problem auch bei einigen anderen Seite bestehen.
Kann es sein, dass vielleicht im Update 2.11.9. irgendwie ein mysql_connet nicht geschlossen wurde?

Die haben die Anzahl jetzt auf 6 begrenzt und nun tritt das Problem nicht mehr auf.
Die Datenbank war übrigends 1,6 TB groß!

[KlausGrenoble]

Ganz nebenbei: Ich würde den Wert irgendwann wieder auf "3" setzen: $GLOBALS['TL_CONFIG']['installCount'] = 0;

[Flex]

Hi, angeblich soll dieses Problem auch bei einigen anderen Seite bestehen.
Kann es sein, dass vielleicht im Update 2.11.9. irgendwie ein mysql_connet nicht geschlossen wurde?

Die haben die Anzahl jetzt auf 6 begrenzt und nun tritt das Problem nicht mehr auf.
Die Datenbank war übrigends 1,6 TB groß!

Eine ordentlich konfigurierte Webumgebung schließt die MySQL Verbindung am Ende des Skripts automatisch.

Die Verwendung von mysql_close() ist für gewöhnlich nicht notwendig, weil offene, nicht persistente Verbindungen automatisch mit Beendigung des PHP-Skripts geschlossen werden.

Ganz nebenbei: Ich würde den Wert irgendwann wieder auf "3" setzen: $GLOBALS['TL_CONFIG']['installCount'] = 0;

Warum?

[xchs]

Könnte es vielleicht sein, dass - durch irgendwelche Filter-/Sortieroptionen - in der URL jeweils unterschiedliche URL-Parameter generiert werden, die dann zur Folge haben, dass Contao die (gleichen) Seiteninhalte immer wieder neu indiziert und in der Datenbank speichert? Und wenn es hinreichend viele Filter- oder Sortiermöglichkeiten gibt, kann die Anzahl der möglichen Permutationen der URL-Parameter u.U. recht groß werden.

Im Zusammenhang mit den Filterfunktionen der Catalog-Erweiterung ist mir das vor langer Zeit schon mal untergekommen.

[KlausGrenoble]

In Deiner Kreditkarte steht auch eine "3" drin für den PIN-Code. Und für das Backend-Login sollte das Gleiche gelten. Übrigens ist "3" hier auch das "Factory Setting". Irgendjemand hat das auf Null gesetzt, weil er "BE-gesperrt" war. Vielleicht wurde inzwischen Dein Passwort schon gefunden, da "0" nämlich für unendliche Anzahl von Versuchen steht. Aber solange die Website nicht funktionniert, geht da sowieso keiner rein (kleiner Scherz um Mitternacht).

[xchs]

Die Vorgabe $GLOBALS['TL_CONFIG']['installCount'] = 0; ist vollkommen korrekt. Jeder ungültige Anmeldeversuch im Contao Installtool erhöht diesen Wert um Eins und bei mehr als drei hintereinanderfolgenden ungültigen Authentifizierungsversuchen, wird das Installtool gesperrt.

[KlausGrenoble]

Ich glaub' ich werd' nicht mehr. Da muss ich in der Schule nicht richtig aufgepasst haben. Ich dachte immer, der Wert steht auf 3 und wird in der DB runtergezählt und dann wird der Timestamp gesetzt. Au mei.

[xchs]

Ich glaube Du verwechselst einfach $GLOBALS['TL_CONFIG']['installCount'] und $GLOBALS['TL_CONFIG']['loginCount']. Letzteres steht standardmäßig auf "3" und wird bei jedem ungültigen Anmeldeversuch runtergezählt.