Apache kann immer wieder mal MySQL nicht erreichen

[actionman007]

Hallo zusammen,

ich kämpfe momentan mit einem sehr seltsamen Problem. Täglich taucht die folgenden Fehlermeldung tausende Male (für ein paar Sekunden bis Minuten am Stück) in meiner error.log auf:

[Thu Oct 22 19:53:07 2009] [error] [client IPDESJEWEILIGENCLIENTS] PHP Warning: mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: Can't connect to MySQL server on 'IPDESDBSERVERS' (10048) in PFADZUMFUNKTIONSSCRIPT on line 47, referer: http://DOMAIN/SCRIPTNAME

Ich versuche euch so viele Infos wie möglich zu liefern. Erstmal kann ich sagen, dass wir schon seit Jahren ein Browsergame betreiben und die beiden Server beim Provider im Rechenzentrum stehen (Provider hat schon ausführliche Netzwerktests gemacht und ausgeschlossen, dass das Problem durch einen Netzwerkfehler verursacht werden kann - hoffe, es stimmt).

Infos zu den beiden Servern
Webserver
ApacheFriends XAMPP (Basispaket) version 1.7.1
Windows Server 2003 Standard Edition Service Pack 2 (alle aktuellen Win-Updates installiert)
Prozessor Athlon 64 X2 Dual Core 5200+
4 GB RAM

DB-Server
MySQL 5.0.67-community-nt
Windows Server 2003 R2 Standard x64 Edition Service Pack 2
Core2Quad 2,5 GHZ
8 GB RAM

Beide Server laufen schon recht lange für uns und wir haben weder an den MySQL- noch an den Webservereinstellungen in den letzten Monaten etwas geändert. Doch der Fehler taucht seit einiger Zeit* ohne ersichtlichen Grund mehrmals täglich in der error.log auf. Grundsätzlich funktioniert die Kommunikation zwischen Web- und DB-Server wunderbar, aber laut error.log scheinbar nicht mehr durchgehend. Die Zeiten in denen der Fehler auftritt sind i.d.R. auch keine Stoßzeiten bei uns. Sprich es sind meist nicht mehr als 200 Spieler online, wenn der Fehler auftritt. Es laufen auch keinerlei Jobs o.ä. auf einem der Server, wenn es zum Fehler kommt. Beide Server laufen da nicht unter besonderer Last und haben seitens RAM und CPU-Leistung noch viele freie Ressourcen.

Ich bin wirklich für jeden Tipp, der mir helfen könnte, der Fehlerquelle auf die Spur zu kommen sehr dankbar. Falls noch weitere Infos nötig sind, dann fragt einfach. Hoffe auch, dass solch ein Problem hier bislang nicht gemeldet wurde, denn leider scheint die Suche im Forum aktuell deaktiviert zu sein.

*Ich muss leider gestehen, dass wir die error.log nicht so regelmäßig geprüft haben, wie wir wohl sollten. Wir haben nur vor etwas über 1 Woche festgestellt, nachdem es seitens der User immer wieder mal Meldungen gab, dass manche Vorgänge nicht richtig verarbeitet wurden, dass die error.log innerhalb 1 Monats (seit Anfang September) auf über 10 GB angewachsen ist. Hab es nicht geschafft diese mit irgendeinem Editor erfolgreich zu öffnen. Hab also eine neue error.log angelegt und in dieser, die auch aufgrund der o.g. Fehlermeldung rasant an Größe zunimmt, den Fehler entdeckt. Meine 1. Vermutung war ein Netzwerkproblem im Rechenzentrum unseres Providers, aber wie schon oben geschrieben, schließt dieser solch ein Problem aus.

[Nobbie]

Meine 1. Vermutung war ein Netzwerkproblem im Rechenzentrum unseres Providers, aber wie schon oben geschrieben, schließt dieser solch ein Problem aus.

Das täte ich an des Providers Stelle auch - dennoch wird es zu 99,99% die Fehlerursache sein. Das muss ja nicht direkt ein fehlerhaftes Netzwerk sein, aber es fehlen ganz offensichtlich Ressourcen. Auf solchen Servern laufen tonnenweise Datenbanken (nicht nur Eure) und wenn beispielsweise die max. Anzahl TCP-Sockets (= Anzahl gleichzeitiger Verbindungen) erreicht wird (weil eben viele Programme bzw. Anwender gerade zugreifen), dann werden die folgenden Requests abgelehnt.

Da braucht man überhaupt nirgends woanders zu suchen und Du hast sicherilch auch gar nicht die Möglichkeit, an der Infrastruktur der Server irgendetwas zu ändern. Das Problem würde mit SIcherheit sofort verschwinden, wenn Ihr Euch (was natürlich Geld kostet) einen Root-Server leistet. Vielleicht als erste Übergangslösung nur einen vServer, der könnte aber auch unterdimensioniert sein.

Ich gehe definitiv davon aus, dass Problem beim Provider liegt, wobei der nicht zwingend etwas falsch machen muss - nur die sind die Kisten natürlich ausgelastet bis zum geht nicht mehr - sonst rechnen sich die Billigangebote nicht.

[actionman007]

Auf solchen Servern laufen tonnenweise Datenbanken (nicht nur Eure) und wenn beispielsweise die max. Anzahl TCP-Sockets (= Anzahl gleichzeitiger Verbindungen) erreicht wird (weil eben viele Programme bzw. Anwender gerade zugreifen), dann werden die folgenden Requests abgelehnt.

Hey, danke für deine Antwort. Aber ich habe mich wohl in meiner Beschreibung nicht gut genug ausgedrückt. Die beiden o.g. Server sind Root-Server, die nur von uns verwendet werden. D.h. wir haben einen Server für Apache (da läuft das XAMPP Paket) und einen nur für die MySQL Datenbank.

[Nobbie]

Hey, danke für deine Antwort. Aber ich habe mich wohl in meiner Beschreibung nicht gut genug ausgedrückt. Die beiden o.g. Server sind Root-Server, die nur von uns verwendet werden. D.h. wir haben einen Server für Apache (da läuft das XAMPP Paket) und einen nur für die MySQL Datenbank.

Dann scheidet die Ursache "Überlastung" (vielleicht) aus. Ich weiß natürlich nicht, wieviele Spieler gleichzeitig spielen. Wieso habt Ihr einen eigenen Server für MySQL? Das würde ich lokal auf dem Webserver laufen lassen, das hat den Vorteil, dass man direkt über die Socks-Datei auf die Daten zugreifen kann (resp. das macht MySQL intern), das ist performanter und möglicherweise auch für Euch die bessere Lösung.

Jetzt ist natürlich noch die Frage, wie ist der MySQL Server konfiguriert - da er den Rechner für sich alleine beansprucht, würde ich als my.cnf die Vorlage "huge" wählen (die sind alle im MySQL Verzeichnis). Und möglicherweise macht Eure Anwendung persistente Connections (mysql_pconnect o.ä.) auf den Server, was vielleicht zur Verknappung von Ressourcen führt. Das sind die beiden Dinge, die ich mal nachschauen würde. Und schaut Euch die Logdateien von MySQL an, ggf. sieht man da auch irgendetwas.

Sind die beiden Rechner direkt miteindander verbunden oder via Switches oder Hubs? Vielleicht ist ja auch das Netzwerk an sich überlastet?

Ich denke wirklich, die beste (und preiswertere) Lösung ist die, die MySQL Daten auch auf den Webserver zu ziehen. Einen Vorteil der Trennung sehe ich da nicht, da Ihr die einzigen Nutzer der Server seid.

P.S.: Habe hier eine sehr interessante Doku gefunden: http://dev.mysql.com/doc/refman/5.1/de/ ... ndows.html

[actionman007]

Wieso habt Ihr einen eigenen Server für MySQL?

Weil wir so mehr Power rausholen. Die meiste Zeit sind nicht mehr als 200 Spieler gleichzeitig online. Aber wir haben gewisse Stoßzeiten (in denen aber der Fehler fast nie auftritt) - da sind dann schon mal so 600-700 Spieler gleichzeitig online (aktuell haben wir eine Gesamtzahl von 5400+ aktiven Spielern).

Jetzt ist natürlich noch die Frage, wie ist der MySQL Server konfiguriert - da er den Rechner für sich alleine beansprucht, würde ich als my.cnf die Vorlage "huge" wählen (die sind alle im MySQL Verzeichnis).

Unsere my.cnf wurde mit direkter Hilfe des SUN MySQL Supports an die Power des Server und unsere Anforderungen angepasst.

Und möglicherweise macht Eure Anwendung persistente Connections (mysql_pconnect o.ä.) auf den Server, was vielleicht zur Verknappung von Ressourcen führt.

Nein, mysql_pconnect nutzten wir nie - nur das "normale" mysql_connect

Und schaut Euch die Logdateien von MySQL an, ggf. sieht man da auch irgendetwas.

Das Log ist absolut sauber und beinhaltet keinerlei Fehler/Warnungen.

Sind die beiden Rechner direkt miteindander verbunden oder via Switches oder Hubs? Vielleicht ist ja auch das Netzwerk an sich überlastet?

Sie sind nicht direkt, aber über ein leistungsfähiges, internes Netzwerk (beide Server mit Gigabit-Karten), miteinander verbunden.

Ich denke wirklich, die beste (und preiswertere) Lösung ist die, die MySQL Daten auch auf den Webserver zu ziehen. Einen Vorteil der Trennung sehe ich da nicht, da Ihr die einzigen Nutzer der Server seid.

Wir hatten früher alles auf dem Webserver, aber zu Stoßzeiten war die Auslastung des Servers schon grenzwertig, deshalb haben wir uns für die Auslagerung der DB (ist schon über 1 Jahr her) auf einen eigenen Server entschieden, was uns viel zusätzliche Power gebracht hat.

[actionman007]

Ich werde echt wahnsinnig. Hab schon alles ganz kleinlich überprüft und finde keinerlei mögliche Ursache für das Problem.

[Nobbie]

und finde keinerlei mögliche Ursache für das Problem.

Vielleicht löst das dein Problem:

http://www.vbulletin.com/forum/showthre ... 87699cb9ff

(letzter Beitrag)

Das ist exakt mein "post scriptum" vom 23.10.09 (inhaltlich).

[actionman007]

Hey, vielen Dank für deine Antwort. Das klingt wirklich schlüssig. Ich muss mal schauen, wie weit wir prüfen können, ob ggf. die Zahl der TCP/IP Verbindungen "aufgebraucht" ist.

[actionman007]

So, der Vollständigkeit halber (für Leute, die ggf. in Zukunft noch das Problem haben sollten) - der Tipp aus diesem Beitrag: http://www.vbulletin.com/forum/showthre ... 87699cb9ff war Gold wert.

Da in dem o.g. Beitrag leider der Teil, wie man die Reg. genau anpassen muss, fehlt, hier auch noch diese Infos.
Alles findet man direkt unter diesem Link (ganz unten): http://dev.mysql.com/doc/refman/5.1/ja/ ... erver.html

Das sind die relevanten Schritte:

1.

Start Registry Editor (Regedt32.exe).
2.

Locate the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3.

On the Edit menu, click Add Value, and then add the following registry value:

Value Name: MaxUserPort
Data Type: REG_DWORD
Value: 65534

This sets the number of ephemeral ports available to any user. The valid range is between 5000 and 65534 (decimal). The default value is 0x1388 (5000 decimal).
4.

On the Edit menu, click Add Value, and then add the following registry value:

Value Name: TcpTimedWaitDelay
Data Type: REG_DWORD
Value: 30

This sets the number of seconds to hold a TCP port connection in TIME_WAIT state before closing. The valid range is between 0 (zero) and 300 (decimal). The default value is 0x78 (120 decimal).
5.

Quit Registry Editor.
6.

Reboot the machine.

Und nochmals ein großes Dankeschön an alle, die mir geholfen haben, auf die richtige Spur zu kommen

[Nobbie]

Da in dem o.g. Beitrag leider der Teil, wie man die Reg. genau anpassen muss, fehlt, hier auch noch diese Infos.
Alles findet man direkt unter diesem Link (ganz unten): http://dev.mysql.com/doc/refman/5.1/ja/ ... erver.html

Genau das hatte ich Dir vor fast einer Woche schon gepostet (s.o.). Das hättest Du alles schon deutlich früher haben können...

[actionman007]

Da in dem o.g. Beitrag leider der Teil, wie man die Reg. genau anpassen muss, fehlt, hier auch noch diese Infos.
Alles findet man direkt unter diesem Link (ganz unten): http://dev.mysql.com/doc/refman/5.1/ja/ ... erver.html

Genau das hatte ich Dir vor fast einer Woche schon gepostet (s.o.). Das hättest Du alles schon deutlich früher haben können...

Du hast zwar die Vermutung aufgestellt. Aber ohne den im dem Posting aufgezeigten Lösungsansatz und dem Hinweis, dass Windows die offenen Verbindungen fälschlicherweise nicht wiederverwendet war dein Tipp für mich leider nicht hilfreich. Trotzdem Danke für den Versuch, aber wie gesagt, manchmal braucht man schon etwas mehr als eine allgemeine Vermutung um einen Fehler zu beheben.