Onderwerp: 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:

1. Ram verhoogd van 512 naar 1024mb
2. van 1 naar 2 cores
3. Php timeout max_execution_time verlaagd van 18000 naar 300 (mijn 'fout')
4. 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)?

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.

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 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.

Oorspronkelijk geplaatst door Thijsvdbrink

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.

Oorspronkelijk geplaatst door systemdeveloper

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.

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. ;-)

Oorspronkelijk geplaatst door Yourwebhoster

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.

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.

Oorspronkelijk geplaatst door ebhosting

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.