Bekijk Volledige Versie : VPS meerdere malen per dag down
Sinds een aantal maanden draai ik een VPS bij XLS. Ik was de eerste maanden bezig een site te ontwikkelen. Echter, nadat de site begin december live is gegaan gaat de VPS meerdere malen per dag down.
Support bij host is vriendelijk maar bij vlagen wat traag. Tot nu toe is het volgende geprobeerd:
Ram verhoogd van 512 naar 1024mb
van 1 naar 2 cores
Php timeout max_execution_time verlaagd van 18000 naar 300 (mijn 'fout')
Php memory_limit = van 256 verlaagd naar 128M
De server lijkt minder vaak down te gaan, maar nog steeds moet ik hem 1 a 2 maal daags rebooten.
VPS: CentOS 5.6, Optimised Joomla! VPS, DirectAdmin, 20 GB HDD, 2 cores, 1024MB. Er draait 1 site op de VPS, Joomla 1.5 en heeft gemiddeld 100 bezoekers per dag.
In het eventlog - binnen de eigen xls n2 interface - zie ik regelmatig de volgende meldingen: warn, stale en warn in combinatie met 'load, wap, iowait'. Verder heb ik een stats screenshot toegevoegd van de laatste maand + een screenshot van het eventlog. Mogelijk geeft dat meer inzicht.
Afgezien van een paar PHP.ini aanpassingen heb ik verder niets op de vps aangepast. En hij draait dus eigenlijk zoals hij is opgeleverd.
Wat zou de oorzaak kunnen zijn van dit probleem ? / Hoe en waar kan ik achterhalen wat het probleem is. En niet minder belangrijk...hoe het op te lossen :)
ps. Ik ben een redelijke linux newbie en ga mogelijk switchen naar een managed vps. Maar dat terzijde.
software is up to date enzo (yum update blablabla)?
Yourwebhoster
23/12/11, 19:08
Je hebt een erg hoge load op de server en iets zit zeker niet goed op de server. Je volledige memory gebruik je niet dus ik neem niet aan dat dat het probleem zou zijn.
Wellicht heb je wat aan een tool als CSF icm LFD, die kan bij hogere load een ps aux sturen waarmee je kan zien wat er aan de hand is. Of je moet ten tijde van het trager worden de vps in de gaten houden en kijken wat er draait als de load hoger is. Mocht het een eis zijn dat het snel opgelost is dan raad ik aan iemand in te huren (plaats een topic in het aanbiedingen forum).
Edit: Na het opleveren heeft de vps ook altijd onderhoud nodig, juist om dit soort dingen te voorkomen of direct meer informatie over zaken als deze te hebben.
Thijsvdbrink
23/12/11, 19:59
iowait?
Test maar eens een hele dag of je Hoster wel 24/7 je een stabiele IOPS aflevert op hun SAN.
Geen idee hoe je dat doet in CentOS, maar als je een scroptje schrijft dat 100MB heen en weer lopieert tussen 2 folders, en de tijd registreert, dan zie je vanzelf wat hij doet denk ik.
systemdeveloper
23/12/11, 20:09
Als ik het goed zie als je met een 1024mb vps nu 2000mb gebruikt, dan komt dat verschil uit je swapfile die waarschijnlijk gewoon op de main storage staat.
Dat is ALTIJD retetraag.
Yourwebhoster
23/12/11, 20:14
iowait?
Test maar eens een hele dag of je Hoster wel 24/7 je een stabiele IOPS aflevert op hun SAN.
Geen idee hoe je dat doet in CentOS, maar als je een scroptje schrijft dat 100MB heen en weer lopieert tussen 2 folders, en de tijd registreert, dan zie je vanzelf wat hij doet denk ik.
Als je naar disk I/O kijkt dan is deze vrij hoog.
Als ik het goed zie als je met een 1024mb vps nu 2000mb gebruikt, dan komt dat verschil uit je swapfile die waarschijnlijk gewoon op de main storage staat.
Dat is ALTIJD retetraag.
Je moet naar RAM kijken en niet total memory. RAM is het daadwerkelijke verbruik zonder cache, waarvoor total memory is weet ik niet.
Thijsvdbrink
23/12/11, 20:20
ow, en je swap is erg hoog denk ik, als al het virtuele geheugen geswapt wordt, draai je dus al je geheugendingetjes van een harddisk, en dat is een beetje slecht voor de performance, als je SAN dan ook nog hapert, is het einde verhaal.
Check dat bij de hoster.
wij hadden bij hoster X SAN issues, en het duurder erg lang, en na heel veel uitzoekwerk, dat ze dat SAN qua IOPS en latency erg ver overcomitted hadden.
-edit, wat die 2 hierboven zeggen. ;-)
systemdeveloper
23/12/11, 20:21
Als je naar disk I/O kijkt dan is deze vrij hoog.
Je moet naar RAM kijken en niet total memory. RAM is het daadwerkelijke verbruik zonder cache, waarvoor total memory is weet ik niet.
Die graf. van de swap 'lijkt' wel vol, al ken ik hun grafieken niet, dus ik kan me zeker vergissen.
Yourwebhoster
23/12/11, 20:24
Bij swap is hoeveel beschikbaar is, de gaten zijn neem ik aan de keren dat hij uitviel hoewel het ook pieken zouden kunnen zijn.
De grafieken geven je inderdaad een indicatie dat er wat aan de hand is met io/memory/cpu .. maar het geeft niet genoeg details om nu precies te zeggen wat er aan de hand is.
Daarvoor is meer detail nodig zoals: kijk eens in je systeem logs (/var/log/messages ) en wat is de output van top als je cpu naar de 100 gaat?
Puur door de kijken naar de statistieken zou dit mijn 'best guess' zijn:
Op de momenten dat je 'load' door het dak heen schiet gaat ook je disk IO/s enorm omhoog.
Je CPU en netwerk gaan niet echt mee in deze pieken. Het aantal processen gaan wel rechtevenredig mee omhoog.
Ik denk dus dat je server op die momenten wat extra request voor zijn kiezen krijgt waardoor hij wegens het overvolle RAM als een malle begint te swappen. Dit zorgt voor de hoge disk IO. Door de traagheid van SWAP (= disks) staan de processen lang te wachten wat voor de hoge load zorgt. Op een bepaald moment is je RAM en je SWAP vol en geeft je OS er de brui aan. Je vind hiervoor meestal wel 'Paging' error in je system log.
Ik denk dat je goedkoopste optie is om even je RAM te verdubbelen voor een maandje. (ben je waarschijnlijk voor een tientje klaar) Als dit het probleem verhelpt weer je wat je te doen staat, je geheugengebruik verminderen. Apache modules uitschakelen, max theads enz.
Post eens de tab "Details" tijdens zo'n piek uit N2. Dat geeft info welke processen de RAM vragen.
Zoveel disk IO is nogal veel > Ik zou ook goed uitzoeken wat die website doet.
Meer RAM zal zeker iets [schijn]oplossen, maar niet als je plugins gebruikt / zelf geprogrammeerd wat niet goed in elkaar zit.
RAM is het daadwerkelijke verbruik zonder cache, waarvoor total memory is weet ik niet.total memory is ram en swap opgeteld
Die graf. van de swap 'lijkt' wel vol, al ken ik hun grafieken niet, dus ik kan me zeker vergissen.Gaat de grafiek lijn van swap/ram omhoog, dan is er meer vrij/beschikbaar.
Gaat de grafiek lijn van swap/ram omhoog, dan is er meer vrij/beschikbaar.
Omgekeerde logica als je het mij vraagt ;)
Vraag 1 maand om een verhoging van je ram, als je dan nog last hebt weet je dat het niet het swappen is :)
Je zou htop kunnen installeren(yum install htop)
Deze geeft een heel goed overzicht van CPU/Geheugen/SWAP gebruik en nog meer.
Jouw uitwisseling is zeer hoog, denk ik, alle virtuele geheugen verwisselen, en dus goed voor al uw opslag op harde schijf dingen, een beetje slecht.:innocent:
Babelfish?
Yourwebhoster
03/03/12, 13:19
Babelfish?
jep, gaat om zijn website linkje:) gerapporteerd iig.
Als ik een server zie sterven dan is dat vrijwel altijd door teveel IO, oftewel de disk is te traag. XLS draait natuurlijk meerdere VPS'en op hun cloud infrastructuur, dus je deelt de hardeschijf met honderden andere VPS'jes. Een disk is normaal al de traagste schakel in een server, en op zo'n gedeelde disk dus al helemaal.
Dus je hebt denk ik 2 opties :) Optie 1 is uitzoeken of je misschien relatief veel disk IO doet en zoja of je dat misschien terug kan brengen. Optie 2 is een dedicated machine nemen of een VPS waarbij je meer IO kunt doen.
Het probleem bij die VPS-en van hun is inderdaad de IO wait / IOPS die niet mee kunnen komen, hoor hier meer mensen over klagen helaas. Als je naar de info op hun website kijkt over het platform is het ook niet spectaculair. Raid 6 is nu ook niet iets wat bekend staat om de goede prestaties. Als ze dit tunen / verberen kan het een zeer leuk product zijn.
Ik heb daar ook een vps en laatste was ook mijn vps down. "Hij was uit zijn geheugen gelopen". Ja nou dat zal, maar dat is erg vreemd met maar een handje vol bezoekers en 1GB geheugen. Ik heb dus het idee dat dat ook een IO tekort was.
Ze gaan daar wel iets aanbieden met ssd cache, maar ik heb nu wel het idee dat ze daar chronisch tekort aan IOPS hebben.
Dit zal een probleem bij vrijwel elke VPS aanbieder zijn denk ik:
- iSCSI of FC is al een extra laag t.o.v. DAS (Direct Attached Storage ofwel gewoon een schijf in je server), maar je moet als VPS aanbieder wel pronken met redundancy en HA, dus DAS is geen optie.
- Waar een reguliere machine sneller SAS zal hebben zal een VPS iSCSI storage machine eerder SATA hebben doordat SAS een te hoge prijs per GB heeft en de tarieven voor VPSjes onder druk staan.
Ik heb daar ook een vps en laatste was ook mijn vps down. "Hij was uit zijn geheugen gelopen". Ja nou dat zal, maar dat is erg vreemd met maar een handje vol bezoekers en 1GB geheugen. Ik heb dus het idee dat dat ook een IO tekort was.
Heel vaak is het uit geheugen lopen een gevolg van trage IO. De apache childs blijven langer actief omdat het langer duurt de content te genereren. Hierdoor loopt het aantal apache processen op, wordt er meer geheugen gebruikt, dan wordt er geswapped, hierdoor worden de disks weer trager, waardoor apache nog langer moet wachten, waardoor.... etc.
Disk IO is een belangrijk onderdeel van de performance van je server. In een shared omgeving is dat erg moeilijk te sturen. Extra disks plaatsen of guests via IO restricties beperken zijn zo'n beetje de enige oplossingen.
Redbeenl, na aanleiding van jouw bericht en ook wat test gegevens op wht.com (http://www.webhostingtalk.com/showthread.php?t=1040757) was de IO inderdaad ver onder de maat.
Ze hebben bij xls een onderzoek gestart en inderdaad problemen gevonden. Er is nu al het een en andere gedaan, en ze kijken er binnenkort nog weer verder naar. Iig bedankt dus voor je inzicht!
Mijn vps is nu verhuisd en heb nu een velen malen betere IO. De vraag is natuurlijk wel of dat zo blijft als het platform weer voller loopt, maar voor nu ben ik tevreden.
Yourwebhoster
06/09/12, 11:55
Hoge load!
Ga je nog nuttige posts hier doen of alleen maar onzin posts met kreten als e-mail en Hoge load!?
Zo dan.. heb je daar 5 maanden over moeten nadenken? :lovewht: