Shop Offline: EXCEPTION_CONNECTION_NODB

Deutsches Forum
1

Hallo,

komme aktuell weder ins Frontend noch ins Backend. Bei beiden werde ich auf Offline.html umgeleitet.

Mit PhpMyAdmin komme ich in die Datenbank rein.

In der Exception_Log steht (Auszug)


oxConnectionException---!--NOT CAUGHT--!--oxException (time: 2015-01-25 18:51:05): [0]: EXCEPTION_CONNECTION_NODB 
 Stack Trace: #0 /home/xxxxx/html/oxid/core/oxdb.php(238): oxDb->_notifyConnectionErrors(Object(object_ADOConnection))
#1 /home/xxxxx/html/oxid/core/oxdb.php(264): oxDb->_onConnectionError(Object(object_ADOConnection))
#2 /home/xxxxx/html/oxid/core/oxdb.php(327): oxDb->_getDbInstance()
#3 /home/xxxxx/html/oxid/core/oxconfig.php(1927): oxDb::getDb()
#4 /home/xxxxx/html/oxid/views/oxshopcontrol.php(521): oxConfig->isProductiveMode()
#5 /home/xxxxx/html/oxid/views/oxshopcontrol.php(81): oxShopControl->_runOnce()
#6 /home/xxxxx/html/oxid/index.php(103): oxShopControl->start()
#7 {main}

 Connection Adress --> 
Connection Error --> oxid_db_users/home/xxxxx/html/oxid/User 'xxxxx' has exceeded the 'max_user_connections' resource (current value: 35)v

Hatte zuvor Änderungen an htaccess gemacht aber wieder zurückgespielt.
Hatte schon TMP geleert, SEO URLs neu berechnet, VIEWS neu generiert.

Bis vor kurzem lief der Shop noch, aber extrem langsam. Latenzzeit nur für die Index.php betrug 7 Minuten!

Ach ja, ich habe einen OXID CE 4.6.5 Shop.

Hoffe es kann mir jemand helfen.

Vielen Dank.

2

max_user_connections könnte bedeuten, dass die db-verbindungen nicht korrekt geschlossen wurden. Starte mal den mysql-server neu, dann sollte die alle gekillt sein.

3

Danke MeisterYoda (toller Name),

die Log-Datei ist voll von diesen Einträgen. Werde meinen Provider bitten MySQL neu zu starten. Ich kann das nicht machen. Ist ein gehosteter Server.

Zum Glück habe ich den Shop als Kopie auf dem gleichen Server in einem anderen Verzeichnis und mit einer anderen Datenbank. Die Kopie ist zwar ein paar Wochen alt, ist aber nicht dramatisch.

Danke nochmal für die schnelle Antwort.

Werde berichten, wenn´s wieder läuft.

4

ich gehe mal davon aus, dass dies kein shop ist der aufgrund der besucher “überlastet” ist. von dem her solltest du evtl. mal mit deinem hoster reden, das hört sich eher nach technischen problemen an, wenn “auf einmal” dies auftritt.

natürlich jat aber meisteryoda prinzipiell recht, das wollte ich damit nicht in frage stellen …

5

Danke @ProudCommerce,

meinem Hoster ist aufgefallen daß die Tabelle oxseohistory auf 106GB angewachsen ist.
Ja, das ist kein Scherz.

Kann ich die Tabelle oxseohistory bedenkenlos leeren?
Und wie kann das sein, daß die Tabelle so voll wird?

Das ist jedenfalls der Grund für die Probleme, denn durch die langen Ladezeiten beleiben die Datenbankverbindungen offen und werden nicht richtig geschlossen. Daher reichen die 35 max_user_connections nicht mehr aus, was sonst kein Problem wäre.

Was meint Ihr?

6

Hi,

106G ist schon mal eine Ansage. Das ist halt die Tabelle, in die alte URLs geschrieben werden, damit diese beim Aufruf über HTTP 301 auf die neue URL zugreifen. Das ist dann sinnvoll, wenn z.B. Titel von Artikeln geändert werden.
Wenn die Tabelle so gross wird, liegt die Vermutung nahe, dass Du ständig URLs änderst. Ist das so und wenn ja warum?

Gruß

7

Ja, 106GB ist nicht zu glauben. Es sind 638.018.860 Datensätze.

Ich ändere die URLs nicht ständig, und ich glaube mein Kunde auch nicht. (Ich frag ihn noch)
Ich weiß schon gar nicht mehr wie das Ganze seinen Anfang nahm. Meine Kunde sagte es wäre alles so langsam, daraufhin wollte ich die htaccess optimieren. Daraufhin bekam ich. Internal Server Error 500 und habe daher wieder die alte htaccess Datei genommen. Habe ein paar mal SEO URLs neu berechnet, TMP geleert, Views generiert.

Mein Provider gab mir den Hinweis daß das Wachstum der Tabelle erst am 22.01 um die Mittagszeit begann.
Es muß einen anderen Grund haben wieso die oxseohistory so rasant gewachsen ist.
Vermutlich eine fehlerhafte htaccess Datei?


<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

RewriteCond %{REQUEST_URI} oxseo\.php$
RewriteCond %{QUERY_STRING} mod_rewrite_module_is=off
RewriteRule oxseo\.php$ oxseo.php?mod_rewrite_module_is=on [L]

RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !(\.html|\/|\.jpg|\.css|\.pdf|\.doc|\.gif|\.png|\.js|\.htc)$ %{REQUEST_URI}/ [R=301,L]

RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (\.html|\/)$ oxseo.php


RewriteCond %{REQUEST_URI} (\/out\/pictures\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (\.jpe?g|\.gif|\.png)$ core/utils/getimg.php

</IfModule>

# disabling log file access from outside
<FilesMatch "(EXCEPTION_LOG\.txt|\.log$|\.tpl$|pkg\.rev)">
order allow,deny
deny from all
</FilesMatch>

Options -Indexes
DirectoryIndex index.php index.html

Kann ich die oxseohistory bedenkenlos leeren?
Bauen sich die Datensätze wieder von selbst auf?
Oder muß ch was machen? SEO URLs neu berechnen?

Ich könnte evtl. auch die oxseohistory von meiner Ersatzdatenbank einspielen, oder?
EDIT: Die ist noch recht Aktuell. (07.12.2014)

8

Hi,

nein, die oxseohistory kann man nicht einfach bedenkenlos leeren, s.o. Es sei denn, der Schmerz ist größer als die Liebe zum eigenen Ranking und es gibt keine andere Möglichkeit.

Hört sich fast so an, als würden irgendwelche Aufrufe URLs erzeugen. Aber dann dürfte etwas massiv verbastelt sein.

Gruß

9

also normal ist das nicht …

hat du evtl. ein modul installiert was hier den mist verzapft?

leeren könntest du die tabelle prinzipiell scho, dann werden halt deine ganzen alten seo-links nicht mehr weitergeleitet.

10

OK verstehe. Wenn der Titel eines Artikels geändert wird (zum Beispiel für eine bessere SEO Optimierung mit anderen Keywords) ändert sich logischerwesie auch die URL. Die alte URL würde dann ohne den Eintrag in oxseohistory ins leere laufen. Also Fehler 404 Seite nicht gefunden. Das schadet dem Ranking. Mit dem Eintrag in der Tabelle oxseohistory wird die alte URL mit permanent Redirect auf die neue Umgeleitet. Habe ich das so richtig verstanden?

Demnach würde es nicht schaden wenn z.B. keine URL oder Titel geändert wurden, oder?

Wie auch immer. Ich habe die oxseohistory geleert und eine noch recht aktuelle oxseohistory eingespielt und es sieht gut aus bis jetzt.

Ich kann die Seite aufrufen und der Seitenaufbau ist recht schnell. Die Unterseiten Links zeigen jetzt natürlich auf die Live Domain.

Den wirklichen Grund warum die oxseohistory sich aufgebläht hat, weiß ich immer noch nicht.

Wie auch immer. Ich möchte die htaccess Datei weiter optimieren nach diesem Whitepaper.
http://docu.oxid-esales.com/devdocuments/whitepaper-performance-optimierung.pdf
Den SubDomain Trick für Bilder oder CSS.
Dann vielleicht noch CSS und JS Dateien komprimieren.
Und vielleicht schauen ob ich ein paar Requests einsparen kann.

Es ist auch im Gespräch einen dedizierten Server zu nehmen.
Schnelle Ladezeiten sind heutzutage schon wichtig. Man will ja nicht die Besucher verärgern und für das Ranking sind schnelle Ladezeiten mittlerweile auch schon wichtig.

11

@ProudCommerce
Also ich habe zuletzt nur die PayPal Umstellung gemacht.
Ach ja, kann ich eFire auch abschalten, habe sonst keine Portlets?
Läuft ja jetzt als Standalone.

Das mit Paypal hat eigentlich nach anfänglichen Schwierigkeiten geklappt.
Habe es zwar nicht in der Sandbox getestet aber live. Das heißt ich habe mal ein günstiges Produkt gekauft.