Het traag reageren van sat4all

[Michel]

Wij weten zelf ook wel een beetje waar we over praten

 

Dat wil niet zeggen dat wij het per definitie beter weten, maar we weten wel hoe ons systeem is ingericht en hoe het geconfigureerd is en dat is niet op de wijze zoals jij nu schetst.

 

De HTTP server (apache) en de MySQL server zijn twee verschillende machines in hetzelfde netwerk.

 

Er is maar één database!

 

Het ligt niet aan het scheiden van deze processen omdat er daarvoor ook al dezelfde problemen waren.

 

Het probleem zit vrijwel 100% zeker in de google code.

 

De hele dag flitst de site, waar juist op een moment waar de server nauwelijks belast wordt de site plotseling minuten hangt (of beter gezegd niet bereikbaar is), terwijl de server vrijwel niets staat te doen en gewoon 100% responsive is.

 

Mvg,

 

Michel

[Sjattuh]

Ik heb 0,0 problemen, ook nauwelijks gehad de laatste week(weken). Vanuit Zuid Turkije loopt het prima. IE8 Vista H

[Gast Kimble]

(Michel, als je toevallig je log file bekijkt voor de afkomst van bezoekers en alle browsersoorten, >300 landen )

 

 

(ik heb gewerkt met 1 ip via een webadres op een dedicated server, 1 via mijn eigen ip-adres en via een utility die steeds verschillende landen betreft met een gezamenlijke interval van 5 minuten)

 

 

Tussentijds rapport van 10:00 uur tot 14:00 uur;

 

De SLA-Benchmark is voor http : 97.1% < 2500ms 100% < 5000ms

De SLA-Benchmark is voor pop3 : 97.2% < 2500ms 97.2% < 5000ms

 

Met http Interceptor, heb ik een log laten maken als er een waarde boven de 1500ms komt.

 

Hier springen de navolgende erg uit (meerdere malen);

 

195.130.132.86 users.pandora.be 2479ms 481 1 1 Apache

195.130.132.86 users.telenet.be Timeout

 

Deze url request laat een head-banner zien;

 

users.pandora.be/adverteerder/banners/advertentie_s4a.*gif (* om links ed te voorkomen)

 

maar ook,

 

users.telenet.be/adverteerder/banners/advertentie_s4a.*gif

 

beidde op het ip-adres 195.130.132.86

 

Waarom dubbel is mij even een vraag het is dezelfde afbeelding, maar de tweede wilde niet opkomen na 10 seconden.

 

TIP: Ik heb de broncode van sat4all bekeken, en mij lijkt het iig beter om de animated gif lokaal in een mapje te zetten.

 

Komen we op onze grote vriend Google. Deze heeft als ip-adres 74.125.87.167 onder de domeinnaam pagead2.googlesyndication.*com

 

De script die hem aanroept is pagead2.googlesyndication.com/pagead/show_ads.*js

 

Vanuit Amsterdam een traceroute naar de server van Google Ads (gemiddeld over 4 uur) zonder uitschieters in de bijlage.

 

Ik heb inmiddels wat meer cijfermateriaal, maar het lokaal zetten van de animated gif van de adverteerder zal betere waarden aan gaan geven.

 

Een traceroute naar sat4all zelf is gemiddeld een 23ms. De site sat4all op zich heb ik tussen deze tijden niets op vernomen aan vetragingen.

 

Ook heb ik een serverload uitgevoerd om 10:10 vanmorgen, waarvan de resultaten ook in de bijlage. (NOOT: Dit is als gast vanuit Stockholm, en dus niet ingelogd)

 

[Gast Kimble]

Sms-je dat er een error was binnengekregen.

 

http://www.sat4all.com/openx/www/delivery/ck.php etc etc veroorzaakte de melding.

 

 

 

 

 

[Gast Kimble]

Klopt, ik heb een aantal errors (9) gekregen, maar ben net wakker (en nog een beetje aan het worden)

 

Server was 3x niet bereikbaar

Google schopte 1x roet in het eten

Adverteerderlink, zoals eerder gemeld, 5x roet in het eten

 

Heb nog meerdere technische specs, maar wil het nu leesbaar houden.

 

Zie bijlage voor de wanneer, wat en eventuele oorzaak

 

[Michel]

Kimble en anderen:

 

Enorm bedankt voor het meedenken en testen.

 

Zelf hebben we iedere minuut een wget gedraaid vanuit een UPC fiberpower aansluiting en een wget op de localhost en die data opgeslagen, om zo te kunnen kijken of de timeout op de server of alleen extern ontstaat.

 

We moeten die data nog analyseren en vergelijken met de andere gegevens uit dit topic, maar daar is momenteel wegens drukte op de zaak even geen tijd voor.

 

We komen er zo snel mogelijk op terug.

 

Mvg,

 

Michel

[Gast Kimble]

Email & SMS Alert:

 

Citaat:

Volgens monitor 'adverteerder Pandora', werkt de http-service op 'users.pandora.be'

sinds 2010-05-20 15:39:05 niet zoals gespecificeerd.

 

Bericht: Not Found

 

Citaat:

Volgens monitor 'adverteerder Pandora', werkt de http-service op 'users.pandora.be'

sinds 2010-05-20 15:45:32 weer zoals gespecificeerd.

[Gast aart44]

Ja nu had ik er ook één van 11.40 tot 11.45 op deze link, na het lezen terug naar index:

 

http://www.sat4all.com/forums/ubbthreads...D_TV_met#UNREAD

[vGnp]

Het was de laatste 5 minuten he-le-maal naatje pet.

 

vGnp

[Gast Kimble]

Heb alerts gehad zie grafische bijlage.

 

Voor de Uptime de laatste 6 uur van sat4all zelf ook een grafiekje.

 

Op dit ogenblik is alles weer 100% (21-05-2010 @ 13:05)

 

 

[Gast Kimble]

Email & SMS Alert:

 

Citaat:

Volgens monitor 'adverteerder Pandora', werkt de http-service op 'users.pandora.be'

sinds 2010-05-21 15:56:41 niet zoals gespecificeerd.

 

Bericht: File Not Found

[Gast Kimble]

Meldingen tussen mijn laatste posting en nu zat 22-05-2010 @ 11:50

 

[Gast Kimble]

Meldingen tussen mijn laatste posting en nu zon 23-10-2010 @ 19:30

 

[Ronaldd]

Even een tussentijdse update. Ik haal sinds een paar dagen iedere minuut de index pagina op (via een php script). De tijd meet ik en sla ik vervolgens op in een MySQL database. Zo kan ik achteraf zien wanneer er time-outs waren. Via sar kan ik dan de load (en veel andere data) van zowel de web server als de database server bekijken.

 

Bij time-outs gaat de load van de webserver naar een zeer laag nivo. De database server heeft het op zo'n moment erg moeilijk. Deze heeft erg veel last van iowaits.

In de MySQL slow query log zie ik op dat moment queries van de zoek machine die tot wel 350 seconden duren. Nadere analyse van deze queries geeft aan dat er een bug zit in de zoek machine van sat4all. De query die zo extreem lang duurt heeft geen tijd restrictie (max 2 jaar). Daardoor wordt de hele database afgezocht, dat is nu ruim 10 jaar.

 

Het is nu een kwestie om deze bug te vinden en te fixen.

 

P.S. Niet proberen, via de zoekmachine, deze bug te reproduceren.

 

Ronald

[Ronaldd]

Ik heb de zoek bug al gevonden. Het was het zoek gedeelte in de rechter kolom. Die zorgde voor zoeken over de hele database. Die zoekt nu, geforceerd, tot 1 maand terug.

 

Ik hoop nu dat de time-outs over zijn. Tussen 3:30 en 4:30 zal sat4all nog wel traag zijn, want dan draait de backup.

 

Ronald