[PHP/MySQL] Site knalt er vaker uit

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • armageddon_2k1
  • Registratie: September 2001
  • Laatst online: 27-07 10:18
Heb al enige tijd een site draaien bij XS4All, waar ik gebruik maak van de MySQL van XS4All. Allemaal leuk en aardig en dat draaide ook lang goed, maar afgelopen jaar is er wat vreemds aan de hand.

Zo nu en dan knalt de site eruit. Er komt een 'Onderhoudspagina' die ik zelf heb gemaakt, en die verschijnt alleen als ie geen verbinding kan krijgen met de XS4All server. Dat is vreemd, want die moet makkelijk wel tegen onze data-stroom kunnen.

Wat echter het geval is is dat wij ook een MySQL server op het kantoor hebben draaien voor enkele, minder belastende, dingen. Geen content oid. In de toekomst willen we een andere hoster, of in ieder geval een andere MySQL hoster, want XS4All ondersteund blijkbaar geen meerdere MySQL databases als dienst. De helpdesk en de zakelijke helpdesk (we zijn zakelijk klant) wist van niks in ieder geval. Aangezien wij meerdere db's hebben ben ik anders genoodzaakt met prefixes te gaan werken etc.

Wat dus het geval is is dat wij een site hebben die content laadt van een XS4All MySQL server en af en toe wat data van een MySQL server bij ons. Dit gaat voornamelijk om enquetevragen etc. uit ons enquete-systeem. Vanuit ons kantoor gebruiken we veel onze MySQL server voor interne apps etc.

Ik heb nu wat logging ingesteld op de site en zie dat het voornamelijk voorkomt als er veel pagina's opgeroepen worden waar ONZE MySQl server benaderd wordt.
Maar dat is raar, want dan zou ik geen foutmelding moeten krijgen dat ik niet kan verbinden met de XS4All server en dat krijg ik wel.

Ter info, ik heb een aparte MySQL class in mijn PHP-code die ik, al het nodig is, 2 keer aanroep. Namelijk altijd 1x voor de XS4All server, en mocht het nodig zijn, 1x voor onze eigen server.

Heeft iemand een richting waar ik in kan kijken? Ik heb al geprobeerd om alle verbindingen goed af te sluiten, wat ik standaard doe met mysql_close($linkid), maar dan dus in de klasse. Maar op het PHP forum geeft men de suggestie dat juist NIET te doen, zodat niet elke keer nieuwe verbindingen geopend worden, daar ben ik nu mee bezig.
Ook de downtime is niet consistent. Vaak een minuut, maar soms ook meerdere minuten.

Ik heb geprobeerd MySQL logs te checken op onze server, maar daar staat dus niks nuttigs in. Althans, geen informatie die enigsinds relevant is mbt de crashes. Maar het kan zijn dat ik misschien verkeerd zit te zoeken.

Kan iemand mij een duwtje in de goede richting geven?

Engineering is like Tetris. Succes disappears and errors accumulate.


Acties:
  • 0 Henk 'm!

  • unclero
  • Registratie: Juni 2001
  • Laatst online: 08:50

unclero

MB EQA ftw \o/

Klinkt alsof er nog ergens een socket openstaat.

En Linux killt sockets pas na een paar minuten ja.

Quelle chimère est-ce donc que l'homme? Quelle nouveauté, quel monstre, quel chaos, quel sujet de contradiction, quel prodige!


Acties:
  • 0 Henk 'm!

  • armageddon_2k1
  • Registratie: September 2001
  • Laatst online: 27-07 10:18
Okee, heb je een idee hoe ik kan checken of er een socket openstaat bij XS4All oid?

Engineering is like Tetris. Succes disappears and errors accumulate.


Acties:
  • 0 Henk 'm!

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 06-09 00:37

curry684

left part of the evil twins

Uh je connect op een zakelijkse site vanaf een consumerlevel hostingplaatsje bij een internetprovider via internet aan de MySQL server van kantoor? Heb je enig idee hoeveel securityrisico's je aan het nemen bent? :X

De beste manier om deze problemen op te lossen is om je infrastructuur op orde te brengen, je bent nu het verkeerde probleem aan het tacklen.

Overigens is het onzin dat het niet slim zou zijn om mysql_close aan te roepen - PHP poolt intern openstaande connecties naar databases dus mysql_close is juist in dit soort situaties gewenst om aan te geven dat de verbinding uit de pool geflusht mag worden.

Professionele website nodig?


Acties:
  • 0 Henk 'm!

  • armageddon_2k1
  • Registratie: September 2001
  • Laatst online: 27-07 10:18
curry684 schreef op woensdag 25 februari 2009 @ 19:52:
Uh je connect op een zakelijkse site vanaf een consumerlevel hostingplaatsje bij een internetprovider via internet aan de MySQL server van kantoor? Heb je enig idee hoeveel securityrisico's je aan het nemen bent? :X
Ja, ik heb het ook niet verzonnen. Zo was de situatie zoals ik daar aankwam. We betalen ons blauw aan hosting-bedragen maar de service van XS4All is ongelooflijk slecht. Snap ook niet dat ze tot beste provider uitgeroepen zijn. De zakelijke tak is belachelijk slecht te bereiken. We hebben een eigen contactpersoon, maar die neemt nooit op. En zo zijn er nog wel meer dingen.

Ik snap dat die infrastructuur op orde moet, en daar zijn we ook hard mee bezig. Er wordt nu gekeken naar een andere inrichting. Punt blijft dat ik het probleem nu nog heb en in principe zou het niet moeten gebeuren.

Toch maar alle connecties nalopen dan.

Engineering is like Tetris. Succes disappears and errors accumulate.


  • Woef
  • Registratie: Juni 2000
  • Niet online
In 2007 heb ik eens een website ontwikkeld voor een basisschool. Die school maakt gebruik van een gratis pakket voor scholen van XS4ALL. Dat valt als ik het me goed herinner ook onder de zakelijke tak van XS4ALL.

Bij die site heb ik een errormailer ingesteld. Elke maand krijg ik zo'n 2 tot 10 mailtjes met de fout:
code:
1
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

Het aantal foutmeldingen is natuurlijk afhankelijk van de bezoekersaantallen. Met zo'n 15 bezoekers per dag is het natuurlijk aannemelijk dat het probleem zich nog veel vaker voor doet.

Een collega van mij heeft begin 2008 contact gehad met XS4ALL en ze waren het toen aan het oplossen, maar tot op heden krijg ik nog steeds deze melding. De laatste twee zijn van 14-02-2009 om 17:14 en 23-02-2009 om 13:06. Maar omdat de basisschool alles gratis krijgt valt er natuurlijk niet veel te eisen.

[ Voor 1% gewijzigd door Woef op 26-02-2009 01:02 . Reden: typefoutje ]


  • kmf
  • Registratie: November 2000
  • Niet online

kmf

OK, even proberen de problemen van de gebruikte configuraties te negeren...

Concreet gesproken wordt het meerendeel van de publieke dingen door je xs4all web/db-server gedaan right?
En alleen voor enqueteprut wordt eens in de zoveel tijd data vanuit je kantoor gehaald?

Krijg je dan een foutmelding op de externe server (xs4all) of de interne server? En wat voor foutmelding zie je dan in de logs?

Kan het zijn dat er een timeout zit op de PHP-instellingen omdat de externe server je lokale niet snel genoeg kan benaderen? of komt het doordat je lokale server traag is op dat moment?

Even een suggestie: als het lokale verkeer alleen nodig is voor enquete, kan je niet gewoon de benodigde data repliceren naar/van de lokale naar de externe server?
Of anders simpelweg het enquetegedeelte intern te hosten?

One thing's certain: the iPad seriously increases toilet time.. tibber uitnodigingscode: bqufpqmp


  • armageddon_2k1
  • Registratie: September 2001
  • Laatst online: 27-07 10:18
Bedankt voor de hulp. Ik ben van plan de lokale (bij ons draaiende db) naar XS4All te kopieren en dan mijn code door te spitten en overal prefixes voor te zetten :) Gelukkig gebruik ik klasses voor MySQL dus dat scheelt een hoop.

Heb wel een potentieel probleem gevonden. Ik gebruik een opensource techniek om grafieken te maken n.a.v. de enquete en die heeft de MySQL gegevens nodig (en gd). Blijkbaar sloot die de connectie niet goed af en voor 15 plaatjes is dat wel een hoop. Even die code aangepast en het lijkt nu beter te gaan. Ik stuur die library gewoon een array met de uiteindelijke waardes die ik zelf bereken met 1 connectie en laat die library niet connecten.

Engineering is like Tetris. Succes disappears and errors accumulate.


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Is qua software ontwerp natuurlijk uberhaupt wel zo leuk, om elke klasse exact 1 taak te geven, ipv een grafieken library welke opeens alles met de db en connecties kan... Dus ook op dit punt is (was) het ontwerp behoorlijk sub-optimaal. ;)

{signature}


  • armageddon_2k1
  • Registratie: September 2001
  • Laatst online: 27-07 10:18
Klopt. Volgende iteratie van de website wordt ook een CodeIgniter-framework-based site. Dan wordt alles tenminste meteen in een beter formaat geforceerd. MVC etc.

Maar eerst maar eens naar andere hosting gaan.

[ Voor 21% gewijzigd door armageddon_2k1 op 26-02-2009 15:30 ]

Engineering is like Tetris. Succes disappears and errors accumulate.

Pagina: 1