Het probleem ligt niet aan de provider/snelheid van je verbinding
. Het is bij ons een intern probleem met het netwerk in de server. Het is als volgt opgebouwd kortgezegt:
Wij hebben 2 grote servers, met hierop kleinere servers:
Op server één zitten 4 kleinere servers:
- De webserver (Waarop de code van photodrome staat), deze heeft een IP, in dit geval 10.0.0.25
- De mysql server (Waarop de database staat, deze staat dus wel op dezelfde computer, maar is voor de webserver een aparte server), met als IP 10.0.0.35
- en 2 interne servers, die geheel los hiervan staan (Met als IP 10.0.0.45 en 10.0.0.55), maar wel met de mysql server verbinding maken.
De "grote" server heeft als IP hier 10.0.0.5. Alle servers zitten intern in de server met een virtueele switch, welke ervoor zorgt dat alle servers intern met elkaar kunnen verbinden.
Daarnaast is nog een tweede server, welke met een draadje direct aan de eerste zit, op hetzelfde netwerk.
Op deze server staat hetvolgende, welke geen van alle iets met photodrome te maken hebben, maar wel met de gevolgen van het totale probleem
- Een webserver, welke intern als IP 10.0.1.25 heeft, een aantal sites gebruiken hier weer de mysql server op de andere server
- Een monitorings server, welke alle servers monitoort. Deze heeft een eigen prive mysql server, om ervoor te zorgen dat bij problemen met de grote server de monitoring blijft werken. Hij zal dus ook enkel verbinding maken met de mysql server om te controleren of deze nog werkt. Zodra er een probleem is met één van de servers/services ontvangen wij een email/sms/melding direct op telefoon dat er iets offline is.
- Een backup server, met als IP 10.0.1.65, waarop backups staan van alle bestanden op de servers en van de database. Deze backups worden elke nacht tussen 0.00 en 2.00 gemaakt.
Daarnaast heeft deze hoofdserver een IP van 10.0.1.5, en heeft ook deze interne switch welke het verkeer regelt.
Hiernaast zit tussen deze twee switches nog een virtuele router (Met IP 10.0.0.15 en 10.0.1.15) om te zorgen dat beide netwerk segmenten met elkaar kunnen praten.
Dit ziet er ongeveer zo uit, schematische gezien (Afbeelding komt uit de monitoring service):
Het probleem zit er nu als volgt. 2 weken geleden was er een security update voor de software welke gebruikt wordt voor de virtuele switches. Hier onstond het huidige probleem eigenlijk, maar het is tevens ook een combinatie van problemen. De foutmelding welke jullie krijgen is wanneer er meer als (In dit geval
, dit is afhankelijk van de instellingen van de mysql server) 100 verbindingen tegelijk zijn op de mysql server (100 verbindingen is een vrij groot aantal. een mysql verbinding duurt vaak maar een aantal milliseconden). Het probleem ontstaat nu wanneer er een verbinding van de 10.0.1.0/24 range (Ofwel de tweede "grote" server) komt. Normaal, wanneer er een verbinding geopend wordt, wordt er een query uitgevoerd, en de verbinding direct gesloten. Echter gebeurd dit op het moment niet correct. Wanneer de webserver, of backup server, te lang moet wachten tot hij antwoord terug krijgt van de mysql server, geeft hij een foutmelding (In dat geval, Connection time out). Echter, de mysql server weet niet dat die foutmelding gegeven is, en houd daarom de connectie open voor een maximum van 15 seconden (Wat een zeer lange tijd is.), de web/backup server opent echter op dat moment ook weer een nieuwe connectie om zijn werk te blijven doen. Dit blijft zich zo even herhalen, totdat het maximum van 100 connecties er is. Zodra dit gebeurd is, gaat hij beginnen met een foutmeldingen te geven (De bekende too many connections fout). Zodra er weer een connectie is stopgezet door de mysql server, is er weer even een plaats, en kan dus bv photodrome weer heel even werken. Echter is het dan wel traag, want de server is tegelijkertijd nog steeds bezig met 99 (Mogelijke) andere connecties.
De oorzaak van deze "gedropte" fout verbindingen zitten in de twee virtueele switches. Normaal gesproken wordt een mysql verbindingen binnen een milliseconden opgebouwd. Hierop is de configuratie van deze 2 servers ook gebaseerd. Zodra de verbinding niet correct binnen 10ms is opgebouwd, stopt hij en probeert hij het opnieuw. De latency (Vertraging) tussen de tweede webserver en de mysql server hiervoor was voor de security update van de switch ongeveer 0.02ms. Op dit moment (een rustig moment) is dit ongeveer 7ms, er is dus nog 3ms over om een goede verbinding op te zetten met de server. Echter, zodra bijvoorbeeld de backup gaat draaien of de tweede webserver het druk krijgt, wordt deze latency hoger, tot boven de 10ms. Op die momenten onstaan dus problemen.
Het echte probleem zit dus erin dat de virtueele switch trager zijn werk is gaan doen. De echte oplossing is dus dit probleem te oplossen, ik heb hiervoor al een bugreport gedaan bij de maker, maar dit heeft nog niets uitgehaald. Nu kunnen we wel downgraden naar een lagere versie van de software, echter betekend dit dat we een vrij gevaarlijk security issue in de server openen. Dit is uiteraard dus geen oplossing
. Om toch tot iets van een oplossing te komen hebben we de maximale tijd van connecties verlaagd van 15 seconden tot 5 seconden. Op deze manier wordt een verbinding dus sneller automatische gesloten, de kans op 100 tegelijke verbindingen is dus hierdoor lager. Hiernaast hebben we de maximale tijd dat een verbinding nodig heeft om te starten op de tweede server verhoogt naar 30ms, hierdoor is er dus minder kans dat de verbinding voortijdig gesloten wordt automatische. Helaas treden, ondanks deze veranderingen en voornamelijk tijdens het maken van de backups, nog steeds foutmeldingen op. Wij zijn nu aan het kijken of we de instellingen nog verder gaan aanpassen, of bijvoorbeeld de backups tijdelijk gaan verplaatsen naar een andere server.
Hopelijk wordt het iets duidelijker hierdoor (Ondanks de, soms wat technische begrippen
)
het is gewoon heel prettig dat er naar gekeken word 
dus bedankt paul 
