Bekijk Volledige Versie : VPS server ligt geregeld plat - Hoog dataverkeer
Hey,
Afgelopen vrijdag is een redelijk grote website (met een aantal complexere mysql queries) online gegaan. Nu zijn er op de drukste tijden zo rond de 30 - 40 mensen aanwezig.
Ook bevat de website een mp3 gedeelte waar veel mp3's te beluisteren zijn. Het lijkt er op dat dit een hoog dataverkeer oplevert naar de server toe.
Nu ligt (vanaf afgelopen vrijdag) iedere dag de server wel 1 of 2 keer geheel plat (SSH onbereikbaar, website onbereikbaar, etc.). Pingen gaat nog wel, alleen reageert de server totaal niet meer.
Een zeer behulpzame webhoster heeft mij zeer op weg geholpen om te zien waar het probleem ligt. In de grafieken die ik van hem ter beschikking heb gekregen (opgevraagd via snmpd) zijn rondom de servercrashes een aantal pieken waarneembaar in zowel het dataverkeer als het CPU gebruik.
In de bijlage vind je een overzicht van enkele grafieken. Daar in is te zien dat de server gisteravond twee keer plat is gegaan en dat het dataverkeer toenam.
Ook wanneer een log bestand van een paar mb wordt geopend via SSH, dan crasht de server en is ie 10 minuten onbereikbaar.
De behulpzame webhoster denkt aan een I/O probleem in combinatie met het hoge dataverkeer. Aan de grafieken is dit ook af te lezen, echter zou ik graag nog wat meer meningen willen horen over wat hier aan de hand kan zijn.
Het betreft een VPS server met 512Mb RAM.
Hebben jullie enig idee wat hier mis kan zijn?
Hoe de CPU belast wordt is helaas niet te zien. Een IO probleem zou natuurlijk kunnen maar zou gezien het geringe dataverkeer geen probleem mogen zijn. Dit is bij een VPS natuurlijk ook afhankelijk van wat er verder op dezelfde host staat en de gebruikte virtualisatie techniek. Bij dergelijke lage verkeer volumes hebben wij in ieder geval nog nooit problemen ervaren.
Dataverkeer zelf is niet echt snel een probleem, het kan inderdaad een i/o probleem zijn, maar dat hoeft niet per definitie aan de website te liggen. Als er gewoon niet voldoende i/o beschikbaar is, dan gaat je systeem vanzelf flippen. Meestal gaat je systeem dan meer processen starten omdat hij niet op tijd de draaiende kan afronden, waardoor meer geheugen nodig is, vervolgens gaat je systeem swappen (nog meer i/o nodig). Als de swap eenmaal vol is zal je systeem met vrij grote waarschijnlijkheid overlijden.
In dit geval lijkt het mij trouwens wat anders, systeem crasht zo te zien helemaal niet op het hoogtepunt maar veeel later. Je mist ook wat belangrijke grafieken en vraag me af of deze wel helemaal kloppen. Ik zou in iedergeval de logfiles rond die tijd eens goed gaan bekijken.
Volgens mij is het dataverkeer inderdaad nog wel te overzien, bekijk de logs eens eventueel in samenwerking met je hoster,
Mijn hoster is niet echt behulpzaam (ook al ligt het probleem wellicht aan hun kant), moet hiervoor al gelijk tientallen euro's neerleggen.
Maar ja, als dat misschien de oplossing geeft dan is het natuurlijk wel rendabel.
In de logs kan ik weinig eigenaardigheden ontdekken (apache log, errorlog, etc.).
Je moet ook niet in de Apache logs kijken maar in bv de kernel log.
Syslog en klogd is gestart, echter zie ik in /var/log/messages alleen maar logs van de firewall (csf). Hier moeten ook de logs van het systeem in te vinden zijn toch?
kern.log syslog etc moet je in kijken. En dan circa 10min voor de crash tot en met de crash kijken of er bijzondere berichten staan.
Ik heb een soortgelijk probleem meegemaakt waarin VPSsen vanuit het niks crashten, of niet meer bereikbaar waren. Het kan aan je hoster liggen, maar omdat je zegt dat je wel nog te pingen bent zou het wellicht ook met je OS temaken kunnen hebben.
Welk OS draai je? en heb je al eens geprobeerd deze opnieuw te installeren?
Ik draai CentOS. Ik heb het niet zelf geprobeerd opnieuw te installeren. Dat lijkt mij een klusje voor de hoster, toch?
Dit ligt er aan: is de VPS managed of neem je hem onbeheerd af? Indien het laatste kan je via aanvraag of via een control panel geleverd door de huidige je server opnieuw installeren. De vraag is of je dit wilt sinds je het zelf niet geconfigureerd hebt (begrijp ik uit je verhaal)
De grafiek die je nodig hebt, staat er niet tussen. Kijk even als je er eentje kan toevoegen voor je disks, met daarin de bytes read/written en transacties read/write.
Als je dat zelf niet kan, ga dan even in je console, tik "vmstat 5 100" en paste de uitvoer hier (op een drukker moment best).
Ik draai CentOS. Ik heb het niet zelf geprobeerd opnieuw te installeren. Dat lijkt mij een klusje voor de hoster, toch?
Normaalgesproken heb je via een controlepaneel de optie om de VPS opnieuw te installeren, c.q. het image opnieuw terug te zetten.
Let wel; je bent dan alles kwijt en begint van voor af aan, als je hoster voor jou e.e.a. heeft ingesteld dan moet hij dit weer opnieuw doen. De vraag of of hij dat kostenloos wilt doen of niet.
De grafiek die je nodig hebt, staat er niet tussen. Kijk even als je er eentje kan toevoegen voor je disks, met daarin de bytes read/written en transacties read/write.
Als je dat zelf niet kan, ga dan even in je console, tik "vmstat 5 100" en paste de uitvoer hier (op een drukker moment best).
Hij is bezig met vmstat 5 100 uit te voeren. Het duurt ff. Want via snmp krijg ik geen output voor read/write van de disks.
Wanneer ik hdparm draai (hdparm -t /dev/sda1) dan krijg ik een goede responsetijd van de hardeschijf (op een rustig moment weliswaar), maar ik krijg wel deze errors in de kernel log:
Sep 7 13:53:30 dutch24 kernel: hdc: tray open
Sep 7 13:53:30 dutch24 kernel: end_request: I/O error, dev hdc, sector 0
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 0
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 1
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 2
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 3
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 4
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 5
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 6
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 7
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 8
Sep 7 13:53:30 dutch24 kernel: Buffer I/O error on device hdc, logical block 9
Sep 7 13:53:30 dutch24 kernel: hdc: tray open
Sep 7 13:53:30 dutch24 kernel: end_request: I/O error, dev hdc, sector 256
Sep 7 13:53:30 dutch24 kernel: hdc: tray open
Sep 7 13:53:30 dutch24 kernel: end_request: I/O error, dev hdc, sector 0
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 :p).
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.
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).
Zij beweren dat er geen overboeking plaatsvindt (voor 25 euro in de maand :p).
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. :D
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.
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
iedereen adviseert TS om in zijn VM te kijken, ik zet mijn spaarpot toch echt op de node zelf waarbij de host mem vol loopt en begint te swappen....
iedereen adviseert TS om in zijn VM te kijken, ik zet mijn spaarpot toch echt op de node zelf waarbij de host mem vol loopt en begint te swappen....
Ook dat moet terug te zien zijn als je stats gaat bij houden, als je ziet dat je eigen swap vol loopt terwijl je minder i/o aan het doen bent bijvoorbeeld. Het is natuurlijk sowieso zo dat performance problemen bij een VPS/VDS, primair altijd bij de aanbieder ligt. Maar afhankelijk van de kosten voor de VPS/VDS kun je bepalen of de geleverde performance redelijk is of niet.
Daarnaast lijkt mij het in elk geval altijd het best om toch eerst uit te zoeken of het probleem niet toch bij jezelf ligt alvorens je een ander de schuld gaat geven. :) Scheelt ook een hoop gedoe als je achteraf daar discussies over krijgt.
iedereen adviseert TS om in zijn VM te kijken, ik zet mijn spaarpot toch echt op de node zelf waarbij de host mem vol loopt en begint te swappen....
Dit heeft TS al aan hoster aangegeven (als eerste) die zegt dat het niet aan hun ligt, als ze moeten gaan kijken (op de host wel te verstaan) wordt de tijd bij TS in rekening gebracht.
Dit heeft TS al aan hoster aangegeven (als eerste) die zegt dat het niet aan hun ligt, als ze moeten gaan kijken (op de host wel te verstaan) wordt de tijd bij TS in rekening gebracht.
Een dergelijke reactie zou ik een reden vinden een andere hoster te gaan zoeken. De host controleren bij problemen vind ik tot het gedeelte horen waar de hoster voor verantwoordelijk is (zonder kosten voor in rekening te brengen).
Een dergelijke reactie zou ik een reden vinden een andere hoster te gaan zoeken. De host controleren bij problemen vind ik tot het gedeelte horen waar de hoster voor verantwoordelijk is (zonder kosten voor in rekening te brengen).
Dat is al geadviseerd.
Ik ga hier ook niet 10x zeggen dat ik het een schandalige manier van zaken vind (ook al is dit wellicht de 10e keer...)
Reden waarom hier niet op in gegaan kan worden: TS betaald per jaar, en heeft er pas een paar maanden opzitten.
Ik snap wel dat je niet even een tweede VPS er naast zet, vooral niet na zo'n situatie..