Onderwerp: VPS server ligt geregeld plat - Hoog dataverkeer

Dat soort errors zijn over het algemeen niet gezond en kunnen wijzen op een hardware probleem, maar het kan ook een probleem zijn met de virtualisatiesoftware of een combi van een aantal factoren. Dit is iets wat je zeer waarschijnlijk zelf niet kunt oplossen, maar wat je hoster moet oplossen.

Ik heb trouwens nog nooit meegemaakt dat een virtuele Linux server opnieuw moet worden geinstalleerd als deze constant crasht. Als een virtuele server 'zomaar' crasht en er geen duidelijke problemen in logs of statistieken te vinden zijn, dan kun je proberen te up of downgraden naar andere (stable) kernel. Als dat het niet oplost dan is het voor 95% zeker een probleem op een ander niveau.

Welke virtualisatie software wordt er gebruikt ? Verder kan het een beperking zijn die op de vps ligt en bij het bursten geknepen wordt waarbij de kernel in panic mode kan schieten en vervolgens ligt je systeem plat. Hetzeflde geld voor de aantal iptable rules (virtuozo)

Ik weet niet welke virtualisatiesoftware wordt gebruikt, maar als ik hdparm uitvoer wanneer de server heel traag is krijg ik onderstaande output:


[root@dutch24 ~]# /sbin/hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 26 MB in 3.12 seconds = 8.33 MB/sec
[root@dutch24 ~]# /sbin/hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 12 MB in 3.22 seconds = 3.72 MB/sec
[root@dutch24 ~]# /sbin/hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 4 MB in 5.72 seconds = 716.32 kB/sec
[root@dutch24 ~]# /sbin/hdparm -t /dev/sda1

/dev/sda1:
Timing buffered disk reads: 2 MB in 19.61 seconds = 104.42 kB/sec


Dus de traagheid zit 'm sowieso in de harde schijf, toch?

Dat kan, denk eerder dat het geheugen helemaal vol zit en de node zelf zijn mem op de schijven begint te swappen. Misschien net iets teveel overboeking

Zij beweren dat er geen overboeking plaatsvindt (voor 25 euro in de maand ).

Wat voor een rechten heb ik als klant in dit soort situaties. Het is een goedkope vps, ok. Maar hij hoort wel goed te functioneren als er nog geen 20 bezoekers online zijn...

Het is in ieder geval niet het dataverkeer, 3 Mbit/s is niet veel voor een VPS. 25 euro is ook geen hele goedkope VPS voor 512MB geheugen. Dat geheugen kan wel erg weinig zijn als de VPS het druk heeft en buffer ruimte te kort komt, maar dat volgt dan weer niet uit je plaatjes. Minder dan 10MB/s voor een disk is ook weer erg laag. Tja... moeilijk. Grote kans is inderdaad overboeking, geheugen van de node op bijvoorbeeld.

Oorspronkelijk geplaatst door Mikey

Dat kan, denk eerder dat het geheugen helemaal vol zit en de node zelf zijn mem op de schijven begint te swappen. Misschien net iets teveel overboeking

Precies mijn idee.
Is het niet zo dat wanneer je een piekje bezoekers krijgt, je machine tig Apache processen gaat spawnen (starten), vervolgens openhoud (keepalive-timeout) en dan blijft spawnen wat resulteert in een (te) hoog geheugen gebruik waardoor je machine gaat swappen?

@TS, neem sowiezo contact op met je hoster, de meldingen die je in je logs ziet zijn ook niet lekker.
@TS-2, andere oplossing is te vragen om een andere VPS op een andere host oid.

Dat is wel schandalig trage disk i/o... Zoals hierboven al vermeld hoeft dat niet direct de oorzaak te zijn, maar dit is wel een duidelijk teken dat deze hoster mogelijk zwaar overselled. Ik ben eerlijk gezegd wel benieuwd welke hoster dit is? (Eventueel via pm).

Oorspronkelijk geplaatst door radem205

Zij beweren dat er geen overboeking plaatsvindt (voor 25 euro in de maand ).

Wat voor een rechten heb ik als klant in dit soort situaties. Het is een goedkope vps, ok. Maar hij hoort wel goed te functioneren als er nog geen 20 bezoekers online zijn...

Attendeer je hoster eens op dit topic en vraag hem om commentaar wat betreft de reacties hier over de trage I/O.

Is de overbelasting dagelijks rond dezelfde tijd? (zie bv. het gat rond middernacht)
Wat geeft top aan ten tijde van overbelasting?

Als mijn VPS gaat backuppen (dagelijks via cron) is ie ook een tijdje druk met i/o.

Verder kan een slechte MySQL database/query ook de (on)nodige belasting geven. Controleer daar eens op. Nb. als het een query probleem is, is er een slow queries setting waarmee je de langzaamste queries kunt identificeren. Aan de hand daarvan kan je gaan optimaliseren, indexeren, etc.

Ik vind 512 MB niet zoveel eigenlijk voor een vps..
Met Centos, Directadmin en bijvoorbeeld zoiets als Spamassassin zit dat geheugen zo vol. Dan gaat de vps virtueel geheugen gebruiken (swappen) hetgeen de schijven weer belast.
Aangezien de schijven blijkbaar al wat problemen vertonen is dit niet wat je wilt.

Oorspronkelijk geplaatst door pid

Precies mijn idee.
Is het niet zo dat wanneer je een piekje bezoekers krijgt, je machine tig Apache processen gaat spawnen (starten), vervolgens openhoud (keepalive-timeout) en dan blijft spawnen wat resulteert in een (te) hoog geheugen gebruik waardoor je machine gaat swappen?

@TS, neem sowiezo contact op met je hoster, de meldingen die je in je logs ziet zijn ook niet lekker.
@TS-2, andere oplossing is te vragen om een andere VPS op een andere host oid.

Ik ken dat gevoel. Gevalletje "Ik heb apache geconfigureerd in 5 minuten! (excl. koffie lurken tijdens het compileren en bouwen!)"-mentaliteit. Helaas moet iedereen ergens beginnen

Maar dat moet best snel opvallen als iemand met verstand (van het onderwerp ) eens even een globale blik over de httpd.conf werpt.

Tevens gaat je load dan naar 20.00-100.00 en zie je via het commando "free" (indien hij nog niet gaat forken) dat je swap oploopt. Hou er ook rekening mee dat dit met SuExec/PHP ook gebeurd (individuele PHP processen).

Wellicht kan je via "top -d 0.5" (kijk naar apache/php processen die excessief toenemen) en "free -s 0.5" (kijken of geheugen/cache gebruik omhoog gaat) eens openen in 2 aparte terminals, en dan wachten op "het moment".

Als je het resultaat even post (eventueel via screenshot(s)) dan kunnen we wellicht (sneller) wat meer over dit incident zeggen.

Bedankt voor jullie reacties. Mijn httpd.conf voor het betreffende domein ziet er als volgt uit:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 200
MaxRequestsPerChild 1000

Het punt is dat ik de hele dag paraat moet staan om op "het moment" te bekijken wat er gebeurd, en die tijd heb ik helaas niet. Ben ook nog maar een student .

Er zijn een aantal slow queries, maar dat zijn hele simpele queries die om nog onbekende reden traag zijn. Met explain is te zien dat de queries goed gebruik maken van de aangebrachte indexes.

Je hoeft helemaal niet de hele dag paraat te staan, je kunt ook zorgen dat je gewoon goede statistieken hebt, bijvoorbeeld doormiddel van Cacti. Na de crash kun je de stats bekijken en als je *overal* stats van hebt dan moet je iets kunnen zien. Zeker als je de logs rond die tijd erbij gaat houden.

Is er niets uit de logs en grafieken te halen is, dan is het 99% zeker een instabiel virtualisatieplatform of instabiele kernel/drivers. Dat laatste kun je al met vrij grote zekerheid controleren door na te gaan of je een stable kernel hebt.

installeer atop met een periodetijd van 30 seconde ofzo, je zult zien dat je daar heel veel mee kunt terugzien