[php/mysql] verbinding mislukt op willekeurige momenten

[semicolon]

Over de omgeving
Het betreft een RHEL 5 omgeving, en het probleem heeft invloed op zowel de standaard RHEL PHP versie (5.1.x) als PHP 5.3.2 uit een andere repo. MySQL is versie 5.1.43, en bestaat uit een master en 2 slaves elk op een eigen server op het eigen netwerk. Ik gebruik MySQLi om de verbinding my MySQL te hanteren. De servers zijn verbonden via een Cisco ASA Firewall die al het interne verkeer met rust laat.

Het probleem
Het is me opgevallen dat op sommige momenten de verbinding met MySQL mislukt, tot nu toe heb ik het alleen gezien met de verbinding naar de Master MySQL server. Dit lijkt echter heel willekeurig te gebeuren, en na een refresh van de pagina werkt de verbinding weer probleemloos.

Ik vraag me af of iemand toevallig dit probleem ook eens is tegen gekomen, want ik kom er niet meer uit. Op Mysql.com vond ik dit topic, echter gaat het daar over direct gebruik van libmysql en ik ben afhankelijk van de PHP module. Afgezien daarvan las ik niet echt een bruikbare oplossing behalve "schrijf een re-connect als hij faalt", wat ik eigenlijk niet echt netjes zou vinden.

En het is ook vrij lastig om te zeggen wat wel/niet werkt als ik dingen probeer aan te passen, omdat ik het probleem niet goed kan reproducen. Veel de web applicatie gebruiken en in het error log wachten tot het probleem zich weer voordoet is de enige manier.

Het enige wat ik qua melding krijg is deze, niet veel zeggende, fout:

code:

mysqli::real_connect(): (HY000/2003): Can't connect to MySQL server on '[ip-van-mysql-master]' (4) in /***/Database.php on line 67

[Twan V]

Heb je PHPMyAdmin geinstalleerd toevallig? Kun je op dat moment daarmee wel connecten?

Vind je iets terug in het Mysql log? Of in de proceslijst van PHPMyAdmin?

[semicolon]

Twan V schreef op zondag 30 mei 2010 @ 18:46:
Heb je PHPMyAdmin geinstalleerd toevallig? Kun je op dat moment daarmee wel connecten?

Vind je iets terug in het Mysql log? Of in de proceslijst van PHPMyAdmin?

Ik gebruik geen PHPMyAdmin, echter gebeurd het 1 keer en daarna werkt het direct weer, dus op het moment dat ik probeer te kijken of ik iets vind is er niets meer aan de hand.

In het error log van MySQL vond ik niets terug.

[B-Man]

Zit je toevallig aan je max_connections op zo'n moment? Als je langlopende processen hebt kan dit namelijk redelijk snel voorkomen.

[semicolon]

B-Man schreef op maandag 31 mei 2010 @ 08:59:
Zit je toevallig aan je max_connections op zo'n moment? Als je langlopende processen hebt kan dit namelijk redelijk snel voorkomen.

Ik heb even getest door 100 processen naast elkaar te laten lopen. Gezien de applicatie op een gesloten netwerk draait zijn er namelijk hooguit 4 gebruikers tegelijkertijd bezig, maar meestal alleen ik. Maar met Apache Benchmark heb ik voor 30 seconden 100 requests naast elkaar laten lopen, en ondertussen zelf ook gekeken, maar toen kwam de fout nergens voor.

Het zou kunnen dat het inmiddels opgelost is doordat ik de timeout van de MySQL verbinding op 0 gezet heb. Dit schijnt een ander gedrag te veroorzaken bij de verbinding. Ik zal echter niet 100% zeker weten of het zo opgelost is tot ik een lange tijd de melding niet meer zie.. De reden waarom ik denk dat daar toch het probleem is kun je hier ook lezen.

I looks like client is really closing TCP connection prematurely. I looked up at code of mysql_real_connect. I am using libmysqlclient_r (thread-safe) library, version 5.1.31. I found one thing which can cause it. Because I set options.connect_timeout, socket is being created as O_NONBLOCK and connect() function in client.c:my_connect will always returning E_INPROGRESS. Afterwards process continues (and ends) by calling wait_for_data with specified timeout:

**code**

So when poll() returns -1, function returns -1 and mysql_real_connect returns -1 too. But poll() can return -1 not only as "hard error" but also when system is catching signal on which process or thread have to call appropriate signal handler. In this case poll() should return -1 and errno=EINTR and process should call poll() again, not returning error.