"Unable to connect to database server" Fehlermeldung.
Eingetragen von wflorian (251)
am 10.12.2008 - 09:28 Uhr in
am 10.12.2008 - 09:28 Uhr in
Ich erhalte in letzter Zeit immer mal folgende Fehlermeldung:
If you still have to install Drupal, proceed to the installation page.
If you have already finished installing Drupal, this either means that the username and password information in your settings.php file is incorrect or that we can't connect to the MySQL database server. This could mean your hosting provider's database server is down.
The MySQL error was: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111).
Currently, the username is XXXXXXX and the database server is localhost.
* Are you sure you have the correct username and password?
* Are you sure that you have typed the correct hostname?
* Are you sure that the database server is running?
For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider.
Gibt es einen genauen Grund für die Fehlermeldung? Ist es durch gewisse Einstellungen behebbar?
Dann würde ich gerne die Meldung anpassen, muss ja nicht jeder meinen DB username erfahren und das Drupal genutzt wird. Habe die Fehlermeldung in 3 Dateien finden können. In includes/database.mysql.inc, includes/database.mysqli.inc sowie includes/database.pgsql.inc
Welcher der dreit Dateien sollte hierfür bearbeitet werden?
Danke Euch.
Grüße
Florian
- Anmelden oder Registrieren um Kommentare zu schreiben
Moeglicherweiser
am 10.12.2008 - 10:12 Uhr
immer mal folgende Fehlermeldung
Moeglicherweiser
This could mean your hosting provider's database server is down.
-------------
quiptime
Nur tote Fische schwimmen mit dem Strom.
Da geht noch was.
Ich müsste es dafür mal
am 10.12.2008 - 10:16 Uhr
Ich müsste es dafür mal weiter beobachten, oder beim Hoster anfragen ob es zu dieser Zeit eine Downtime gab.
Welche der Dateien sollte ich editieren?
So. Ich habe nun vom
am 10.12.2008 - 23:35 Uhr
So. Ich habe nun vom Betreiber die Nachricht erhalten, dass der Server zum besagten Zeitpunkt "Out of memory" lief.
Gibt es Optionen in Drupal die dies verhindern können? Sollte es etwas ändern? Konnte zur besagten Fehlermeldung, im Netz nur wenig fundierte Informationen hierzu finden.
Grüße
Florian
Das sind eine Menge Fragen von deren Antwort eine Antwort ...
am 11.12.2008 - 01:07 Uhr
dass der Server zum besagten Zeitpunkt "Out of memory" lief.
Gibt es Optionen in Drupal die dies verhindern können?
Was laeuft denn alles auf dem Server?
Wie ist der Server ausgestattet?
Wie umfangreich ist die Drupalinstallation, aktive Module etc.?
Gibt es eigenen PHP/DB-Code?
Was ging ab mit der Drupal-Website "zum besagten Zeitpunkt"? Besucher, Anzahl Anteil Gast Anteil eingeloggte User?
Das sind eine Menge Fragen von deren Antwort eine Antwort auf Deine eigentliche Frage abhaengt.
-------------
quiptime
Nur tote Fische schwimmen mit dem Strom.
Da geht noch was.
Folgendes Paket haben wir:
am 11.12.2008 - 17:47 Uhr
Folgendes Paket haben wir: http://www.hosteurope.de/produkt/WebPack-Pro-L
Auf unserem Webpack läuft noch eine andere Seite, allerdings sollte diese nicht allzuviel Last verursachen, wie Drupal.
Die Drupalinstallation ist recht umfangreich. Ca. 15-20 Module sind aktiv. Darunter viele Kleine aber auch Große wie Panels und Views.
Eigenen PHP Code gibt es nur in begrenzter Form.
Zum besagten Zeitpunkt ging nicht wirklich viel ab. Ich schätze es waren ca. 10 Leute auf der Seite. Der Fehler "Unable to connect to DB" scheint sehr sporadisch aufzutreten.
Ich hatte schon vor einigen Wochen in der settings.php von Drupal folgende Zeile hinzugefügt:
ini_set('memory_limit', '96M');
Ich bin mir nicht bewusst, ob diese wirklich wirksam ist. Ich habe jetzt zusätzlich in die .htaccess noch folgende Zeile eingefügt:
php_value memory_limit 96M
und mit php info() kurz getestet. Nach dem hinzufügen der .htaccess Zeile wird das erhöhte Limit von 96MB angezeigt. Ich nehme an die Einstellung in der settings.php funktioniert entweder nicht oder bezieht sich nur auf Drupal Dateien. Die .htaccess hingegen scheint sich ja auf alles Dateien in dem jeweiligen Verzeichnis zu beziehen. Sprich auch eine test.php mit php info().
Ich habe jetzt vorsorglich nochmal beim Hoster nachgefragt, umwieviel der Speicher höher als der Limit war...
Was würdest Du uns empfehlen?
Grüße
Florian
Referenzschleifen ins Nirwana
am 11.12.2008 - 18:02 Uhr
96M ist schon ordentlich kann aber unter Umstaenden zu wenig sein.
Aber mit dem Frage-Antwortspiel hier ist nur eine sehr ungenaue Analyse moeglich.
Verwendet man beispielsweise intensiv CKK (viele Nodetypes mit insgesamt vielen Fields) kann 96M schnell zu knapp werden. Aber in diesem Fall bekommt man nicht Deine Eingangs zitierte Fehlermeldung.
Ebenso kann durch unglueckliche Modulkonfiguration jedes Memeorylimit an die Grenzen geraten egal wie hoch es ist. Typischer Kandidat fuer so etwas sind Referenzen die sich selbst referenzieren.
Es gibt da ein CCK Modul bei dem vom Modul her fuer solch eine Fehlkonfiguration kein Schutzmechanismus existiert. Soll heissen das Modul erlaubt Konfigurationen mit "Referenzschleifen ins Nirwana".
-------------
quiptime
Nur tote Fische schwimmen mit dem Strom.
Da geht noch was.
quiptime schrieb 96M ist
am 11.12.2008 - 18:12 Uhr
96M ist schon ordentlich kann aber unter Umstaenden zu wenig sein.
Aber mit dem Frage-Antwortspiel hier ist nur eine sehr ungenaue Analyse moeglich.
Verwendet man beispielsweise intensiv CKK (viele Nodetypes mit insgesamt vielen Fields) kann 96M schnell zu knapp werden. Aber in diesem Fall bekommt man nicht Deine Eingangs zitierte Fehlermeldung.
Ebenso kann durch unglueckliche Modulkonfiguration jedes Memeorylimit an die Grenzen geraten egal wie hoch es ist. Typischer Kandidat fuer so etwas sind Referenzen die sich selbst referenzieren.
Es gibt da ein CCK Modul bei dem vom Modul her fuer solch eine Fehlkonfiguration kein Schutzmechanismus existiert. Soll heissen das Modul erlaubt Konfigurationen mit "Referenzschleifen ins Nirwana".
Funktioniert denn rein theoretisch die Anweisung in der settings.php? Ist es problematisch nun noch den zweiten Eintrag in der .htaccess zu hinterlassen? Das würde mich erstmal primär interessieren.
Um welches CCK Modul handelt es sich denn dabei, welches ohne den besagten Schutzmechanismus arbeitet? Ev. verwenden wir ja dieses...
Das ist der "Verräter":
am 11.12.2008 - 18:57 Uhr
Nach meinen Erfahrungen funktioniert und reicht die Konfiguration des Memorylimit in der "settings.php". Ob ein Doppel-Eintrag problematisch ist weiss ich, glaub ich aber nicht.
Das ist der "Verräter": Node Referenz
-------------
quiptime
Nur tote Fische schwimmen mit dem Strom.
Da geht noch was.
Hmm...also Node Referenz
am 11.12.2008 - 19:08 Uhr
Hmm...also Node Referenz nutzen wir nicht. Entweder verursacht ein anderes Modul das Problem, oder eigener PHP Code von uns.
Könnte den die Suche das Problem verursachen. Soweit ich weiß, verursacht die immer viel Last oder? Die Suche wird auf unserer Seite sehr sehr häufig genutzt, wir haben knapp 2800 Nodes bei 8 Inhaltstypen. Wenn nun einige Nutzer fast zeitgleich die Suche bemühen, könnte dies Probleme verursachen?
Also wenn die settings.php eigentlich funktioniert, dann müsste ich die 96MB sogar noch weiter raufsetzen...128MB sind aber schon wirlich heftig zu den Standard 32MB...hmmm...gibt es denn Möglichkeiten das irgendwie zu loggen, wenn der Fehler auftritt? Wir haben wie gesagt keinen "eigenen" Server. Von daher sind die Konfigurationsmöglichkeiten sehr begrenzt.
Danke nochmal und schonmal für Deine Hilfe quiptime. ;)
Grüße
Florian