Ik had me er beter niet in kunnen mengen. PD is nu bij mij ook vreselijk t r a a a a a g g g g g g g g
Misschien is het handig om de provider en lokatie te vermelden zodat je een beetje iets kunt gaan herleiden.
Traagheid met gevolgen?
Nergens last van
Misschien is het handig om de provider en lokatie te vermelden zodat je een beetje iets kunt gaan herleiden.
Misschien is het handig om de provider en lokatie te vermelden zodat je een beetje iets kunt gaan herleiden.
-
Henry
- Lid
- Berichten: 53230
- Lid geworden op: 25 mar 2008 19:21
- Bezwaar bewerken: Nee
- Geslacht: Man
- Locatie: Almere
Traagheid is hier weer weg
Ik zit trouwens bij UPC en heb een 60Mb verbinding, dus daar zal het niet aan liggen...
Andere sites werken wel goed.
Mogelijk heeft het iets te maken met de database (server). Daar waren enige tijd geleden ook problemen mee.
Ach, we mogen niet klagen. Om de zoveel tijd een klein "hikje" vind ik niet zo erg.
Ik zit trouwens bij UPC en heb een 60Mb verbinding, dus daar zal het niet aan liggen...
Andere sites werken wel goed.
Mogelijk heeft het iets te maken met de database (server). Daar waren enige tijd geleden ook problemen mee.
Ach, we mogen niet klagen. Om de zoveel tijd een klein "hikje" vind ik niet zo erg.
-
Mendel
- Lid
- Berichten: 31595
- Lid geworden op: 09 mar 2008 15:31
- Bezwaar bewerken: Nee
- Geslacht: Man
- Locatie: Schagen
- Contacteer:
Ik ondervond zelf donderdagavond wat last, wou toen net de hoster aanschrijven, maar toen liep de site opeens weer goed.
Heb een mail verzonden naar de hoster, met vermelding van dit topic zodat men de tijden van de storingen kan zien.
Heb een mail verzonden naar de hoster, met vermelding van dit topic zodat men de tijden van de storingen kan zien.
Bandbreedte zegt niets over snelheid. Kabel is gedeelde transmissie en als de verzendende partij problemen heeft dan kun je darkfibre nemen maar als aan de andere kant een 28k8modem hangtHenry schreef:Ik zit trouwens bij UPC en heb een 60Mb verbinding, dus daar zal het niet aan liggen...
Andere sites werken wel goed.
Daarbij worden abonnementen met overboeking verkocht wat inhoud dat de snelheid vaak theoretisch is. En is een goede browser met een modem net zo snel als jou abo met IE
Maar ja waar kun je nog met een analoog modem inloggen.Ach was het Internet nog maar grijs, met zwarte letters en blauwe linken en als je er geweest was paarse linken en her en der een plaatje en gebruikte iedereen nog maar Navigator of Mosaic. Maar ja toen schreef je poep nog met een lange oe.
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:
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
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 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.
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.
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
)
Laatst gewijzigd door paul999 op 27 sep 2010 15:18, 1 keer totaal gewijzigd.
het is gewoon heel prettig dat er naar gekeken word 
dus bedankt paul 
Kijk dat zijn antwoorden. Maar downgraden, wat voor enorme beveiligings fouten worden er dan 'vrijgegeven'?
Meestal weten een paar debielen dit maar is de vraag of PD nu daadwerkelijk misbruikt kan worden ed. Ergo is de update dodelijk belangrijk. Aan de andere kant zijn er een paar kabelaars met glas Almere die er last van hebben. Tja ga dan gewoon naar buiten, wel buiten de gemeente grenzen, en geniet
Meestal weten een paar debielen dit maar is de vraag of PD nu daadwerkelijk misbruikt kan worden ed. Ergo is de update dodelijk belangrijk. Aan de andere kant zijn er een paar kabelaars met glas Almere die er last van hebben. Tja ga dan gewoon naar buiten, wel buiten de gemeente grenzen, en geniet
Dit gaat om een veiligheids probleem waarop root (Een soort administrator of god) toegang verkregen kan worden op de gehele hoofd server, en hiermee alles kan doen wat hij/zei wilt. Niet iets wat je dus echt wilt als hoster . Het gaat dus niet specifiek om photodrome, maar meer over de gehele server.
. Het gaat dus niet specifiek om photodrome, maar meer over de gehele server.Ja dat is begrijpelijk maar dat geldt voor legio beveiligings updates, misschien wel de meerderheid, maar zie jij in je log files dergelijke aanvallen van robots of scriptkiddies of echte hackers op PD? Soms moet je ook afwegen hoe groot de kans is op een bepaalde foutkans en dan een keuze maken. Ik denk dat ik met jou en soortgelijke vaker dergelijke overleggen heb of heb gehad als IT manager van beursgenoteerde ondernemingen. Maar soms is techniek leuk en soms nodig maar soms is klant tevredenheid belangrijker dan afhakers Niet dat dit hier gebeurd want itt andere fora is er erg open beleid, en zijn de problemen op een halve hand na te tellen Waarvoor hulde, alsook deze verwerking van het probleem.
En terug melden van status, zoals jullie doen dan kunnen 90% van de servicedesks van bedrijven nog een voorbeeld aan nemen. Hulde, hulde.
Jeroen
van beursgenoteerde ondernemingen. Maar soms is techniek leuk en soms nodig maar soms is klant tevredenheid belangrijker dan afhakers Niet dat dit hier gebeurd want itt andere fora is er erg open beleid, en zijn de problemen op een halve hand na te tellen Waarvoor hulde, alsook deze verwerking van het probleem.En terug melden van status, zoals jullie doen dan kunnen 90% van de servicedesks van bedrijven nog een voorbeeld aan nemen. Hulde, hulde.
Jeroen
Het is geen web gebaseerd security probleem, dit probleem zit direct in de kernel van het besturingssysteem (Zie het als hart van het OS), en enkel in de hoofdserver, en niet in de kleinere servers welke op die hoofdserver draaien . Niet updaten in dit geval is gewoonweg geen update, voor de veiligheid van alle bestaande gegevens en klanten .
. Niet updaten in dit geval is gewoonweg geen update, voor de veiligheid van alle bestaande gegevens en klanten .Ok Henry jammer dan Ik heb het geprobeerd
Ik heb het geprobeerd 
Nog iemand uit Almere
Sorry
Sorry
niet alleen datMendel schreef:Ik heb dus een slechte aura...
hij is bij mij ook op mijn werk niet vooruit te branden af en toe (vandaag)