Temporärer Verlust der Datenbankverbindung ?

[SickStar]

Hallo liebe Community,

 

ich melde mich mal wieder mit einem Problem.

Seit heute morgen hat mein Shop (Version 1.6.1.2) scheinbar ein immer wiederkehrendes, aber temporäres, Problem mit der Datenbankverbindung.

 

Sowohl im BackOffice als auch im FrontEnd bekomme ich immer wieder mal leere, weiße Seiten angezeigt.
Wenn ich dann ein paar mal die weiße Seite aktualisiere, kommt irgendwann auch der Shop wieder zurück.

 

Nach dem aktivieren des Debug Modes bekomme ich nun auch die folgende Fehlermeldung auf den weißen Seiten zu Gesicht:

Fatal error: Call to undefined function mysql_connect() in /pages/2a/95/d0XXXXX5/home/htdocs/classes/db/MySQL.php on line 51

So sieht das in der /classes/db/MySQL.php (ab Zeile 45) aus:

public function connect()
    {
        if (!defined('_PS_MYSQL_REAL_ESCAPE_STRING_')) {
            define('_PS_MYSQL_REAL_ESCAPE_STRING_', function_exists('mysql_real_escape_string'));
        }

        if (!$this->link = mysql_connect($this->server, $this->user, $this->password)) {
            throw new PrestaShopDatabaseException(Tools::displayError('Link to database cannot be established.'));
        }

        if (!$this->set_db($this->database)) {
            throw new PrestaShopDatabaseException(Tools::displayError('The database selection cannot be made.'));
        }

        // UTF-8 support
        if (!mysql_query('SET NAMES \'utf8\'', $this->link)) {
            throw new PrestaShopDatabaseException(Tools::displayError('PrestaShop Fatal error: no utf-8 support. Please check your server configuration.'));
        }

        return $this->link;
    }

Hat einer 'ne Idee, woran das ganze liegen kann ? Ich habe seit längerem nichts an dem Shop geändert und bin nun echt verwundert, warum seit heute dieser Fehler auftritt. Zudem habe ich auf dem selben Managed Server (Strato) einen weiteren Shop (Version 1.6.1.10) laufen welcher keine Probleme hat.

 

Freue mich über jegliche Anregungen eurerseits.

 

Danke und Gruß,

Silvio

[TimmeHosting]

Haben Du oder Dein Hoster evtl. die PHP-Version von 5.x auf 7.x umgestellt? in PHP 7 werden die alten mysql-Funktionen nicht mehr unterstützt, stattdessen sollten jetzt die mysqli-Funktionen genutzt werden.

[SickStar]

Hallo TimmeHosting,

 

die verwendete PHP Version ist 5.6.30. Daran kann es also leider nicht liegen.

 

Gruß

[Scully]

Läuft XCACHE oder APC auf dem Server?

Und sonst einfach mal den Output von

<?php phpinfo(); ?>

hier einstellen. PHP nutzt extensions (wie eine Art Module), da kann man Funktionen ein- oder ausgeschaltet haben. Obiger Fehler kann auch dann aufscheinen, wenn die alte MySQL-Extension für PHP abgeschaltet ist.

Edited August 4, 2017 by Scully (see edit history)

[rictools]

Eigentlich sieht das doch eher nach einem Erreichbarkeits- / TimeOut-Problem aus, vielleicht zu viele Zugriffe auf die Datenbank?

[Scully]

Dann müsste eigentlich aber too many connections im Fehler erscheinen. Trotzdem halte ich den Hinweis von Dir nicht abwegig.
Einfach mal die zwei Befehle in einer Datenbank Session absetzen. Der erste zeigt, wieviele Connections erlaubt wären, der zweite, wiviele maximal genutzt waren seit dem letzten Datenbank-Start. Sind die Zahlen identisch, dann muss man die Connections erhöhen.

 

show variables like "max_connections";

show global status like "%Max_used%";

Edited August 4, 2017 by Scully (see edit history)

[Scully]

Wenn ich doch nochmal darüber nachdenke, glaube ich NICHT, dass es an max connectins liegt.

Ich vermute, dass die PHP-Laufzeit-Umgebung verändert wurde - wer oder was auch immer dafür verantwortlich ist.

Die Meldung besagt ja, dass die Funktion mysql_connect nicht verfügbar ist.

 

Es wäre spannend, vom Themenstarter nochmal etwas zu hören.

[SickStar]

Hallo,

 

entschuldigt bitte die späte Antwort. Leider war es mir in den letzten Tagen nicht möglich, mich hier zu melden.

Die PHPInfo zeigt folgendes: https://nopaste.xyz/?4c5626d8e0ba6650#jVYqRKNXli+89YSGeCy3BYd+a6xcUxH/4o/A1r4SB9Y=

Ich hoffe man erkennt dort noch das benötigte.

 

SHOW VARIABLES LIKE "max_connections" liefert

  Variable_name Value   max_connections 2550

 

SHOW GLOBAL STATUS LIKE "%Max_used%" liefert

 

Variable_name Value   Max_used_connections 91

 

Scheint also dann nicht an zu vielen Zugriffen auf die Datenbank liegen.

Ich muss auch sagen, dass seit gestern der Fehler (scheinbar) nicht mehr aufgetreten ist bzw. zumindest für mich nicht mehr ersichtlich war.
Das ich eventuell bis jetzt nur Glück hatte kann ich natürlich nicht ausschließen.

 

Vielleicht mag ja trotzdem mal einer über die PHP Info Ausgabe schauen. Vielleicht kann der ein oder andere Experte dort den Fehler immer noch erkennen

 

Gruß und Danke vielmals,

Silvio

[Scully]

Leider kann man den Grund für die initial gemeldete Problematik daraus nicht ersehen. Zumindest sind auf dem Server die notendigen Libraries konfiguriert. Was mich aber irritiert sind diese Zahlen:

 

max_connections 2550

max_used_connections 91

 

Deine Datenbank ist also so konfiguriert, dass max. 2550 Verbindungen gleichzeitig möglich wären. Das ist ein extrem hoher Wert und kaum sinnvoll. Als Vergleich - so setzen wir bei Installationen die Werte:

 

- Neuinstallation auf neuer Domain: max_connections = 30

- Bei einer etablierten Domain: max_connections = 50

- Bei Domains mit high Traffic: max_connections = 100

 

100 hat also bei uns bisher immer gereicht. Warum den Wert nicht proaktiv einfach noch höher setzen?

 

Entsprechend max_connections werden file descriptors und damit auch Hauptspeicher reserviert. Ressourcen, die man besser nutzen könnte anstatt max_connections einfach auf einen extrem hohen Wert zu setzen.

 

Im konkreten Fall würde ich max_connections auf 150 setzen und ggf. auch mal prüfen, was denn die 91 concurrent connections tatsächlich im System so anstellen. Mir scheint auch 91 relativ hoch, aber wenn es ein stark frequentierter Shop ist, dann kann der Wert schon passen.

Edited August 8, 2017 by Scully (see edit history)

[SickStar]

Nochmal vielen Dank für die rasche Antwort.

Die max_connections habe ich selbst nicht so hoch eingestellt sondern wenn überhaupt ein Mitarbeiter von Strato da ich einen Managed Server benutze.

 

Über mein Kontrollzentrum kann ich dies leider selbst nicht einstellen. Lässt sich das ganze denn ohne MySQL root Account überhaupt von mir selbst verändern?

 

Wie ist das eigentlich.. bezieht sich der max_connections Wert eigentlich auf jeweils eine Datenbank oder das komplette DBMS ? Habe nämlich zwei PrestaShops auf diesem Server am laufen (mit jeweils einer sep. Datenbank) und wenn sich die 91 Verbindungen auf beide Shops/Datenbanken verteilen dann scheint es ja sogar in Ordnung zu sein. Wirklich stark frequentiert ist aber trotzdem leider keiner der beiden Shops

 

ggf. auch mal prüfen, was denn die 91 concurrent connections tatsächlich im System so anstellen.

Wie stelle ich das denn an ?

 

Gruß

[Scully]

max_connections hat einen globalen scope. Hier findest Du dazu mehr (auch für andere Settings):

 

https://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html

 

Wenn Du das Setting nichts selbst permanent setzen kannst, evtl. man den Admin der Hosting Company fragen. Das sollten die in 2 Minuten erledigt haben. Temporär kann man es auch in einer aktiven MySQL-Session setzen, wenn der Datenbank-Account dafür die Privilegien hat:

SET GLOBAL max_connections = 250;

Der Wert gilt dann solange, bis die Datenbank neu gestartet wird.

Edited August 8, 2017 by Scully (see edit history)

[Scully]

Und zur Frage, was die 91 gleichzeitige Connections denn alle machen:

 

Generell kann man für PrestaShop sagen, alles was irgend eine Seite des Shops aufruft, stellt eine Verbindung zur Datenbank her. Wenn Du nun zwei Shops auf demselben Server laufen hast und wird der einfachheit annehmen würden, dass beide Shops gleich frequentiert werden, dann hätten wir je 45 Connections, was die Sache halbwegs relativiert aber immer noch recht hoch ist. Herausfinden, woher die kommen kann man z.B. so:

SELECT inet_ntoa(ip_address) as IP, count(id_connections) as hits
FROM `pre_connections`
GROUP BY IP
HAVING hits > 3
ORDER BY hits DESC

Der Select wertet die tabelle connections von PrestaShop aus, übersetzt die IP-Adresse in ein lesbares Format, sortiert absteigend nach Anzahl der Zugriffe und berücksichtigt nur jene IP-Adressen, welche mindestens 3 Treffer haben.

 

Dann schaut man sich z.B. über irgend einen Whois-Dienst an, was das für IP-Adressen sind. Unserer Erfahrung nach häufig sind natürlich die grossen Suchmaschinen wie zB Google, Bing.

Edited August 8, 2017 by Scully (see edit history)

[Scully]

Gleichzeitig sehen wir aber auch häufig, dass es eine grosse Anzahl von Crawlern gibt, die für den Betreiber keinerlei Vorteile haben, jedoch Ressourcen beanspruchen und teilweise recht aggressiv Zugriffe machen. Oder auch Bots, die einfach nach Schwachstellen in einem System suchen zwecks SQL-Injection, Malware-Verbreitung und anderem.

 

Wir begegnen der Problematik so, dass wir in der robots.txt gewisse Crawler ausschliessen. Einfach mal nach robots.txt deny crawler oder so suchen.

 

https://www.google.ch/search?q=robots+txt+deny+crawler

 

Die robots.txt wird indes von Crawlern mit wirklich unerwünschten Zugriffen in der Regel ignoriert, weshalb man damit nicht allen unerwünschten Traffic wegbekommt. Darum greifen wir hier zu härteren Massnahmen, die da heissen .htaccess deny. Über diese Datei, welche PrestaShop ohnehin schon anlegt fügen wir weitere Regeln hinzu und blocken teilweise "grossräumig" Zugriffe aus Ländern, welche für unsere Kunden keine Relevanz haben.

 

Wenn wir also zB einen Shop aufstellen, der in CH, D und AT tätig sein soll, dann brauchen wir keinen Traffice aus China, Südamerika oder Südostasien. Darum blocken wir häufig ganze Top-Level-Domains via .htaccess. Vorteil: Weniger unnützer Traffic, ein nicht perfekter aber durchaus willkommener Schutz gegen Angriffsversuche, mehr Ressourcen auf Server und DB für erwünschten Traffic. So sieht das dann in .htaccess aus:

<Limit GET HEAD POST>
order deny,allow
Deny from .ro
Deny from .ru
Deny from .cn
Deny from .gn
Deny from .hu
Deny from .lv
Deny from .pe
Deny from .kp
</Limit>

Damit werden die oben eingefügten Top-Level Domains komplett vom Zugriff ausgesperrt. Diese Liste kann man natürlich beliebig erweitern. Wir haben oft zwischen 20 bis 50 Einträge drinn stehen. Wichtig: Diese Ergänzung muss ausserhalb der von PrestaShop in der .htaccess erzeugten Bereichs liegen. Die entsprechenden Kommentarzeilen beachten. Man kann hier auch einzelne Domains bzw. Robots sperren, genau so auch IP-Adressen, sowohl einzeln als auch ganze Adressbereiche.

 

Fazit des Exkurses:

Shopbetreiber sollten sich von dem Gedanken verabschieden, dass jeglicher Traffic auf dem Shop auch wirklich nutzvoll ist bzw. Mehrumsatz oder mehr Kunden generiert. Es gilt abzuwägen, in welchen Märkten man aktiv sein will und unerwünschten Traffic je nach Bedarf zu sperren.

Edited August 8, 2017 by Scully (see edit history)