Onderwerp: Slim om up te graden?

Hoi,

Ik huur een VPS bij DeziWeb nu met 2GB RAM. Mijn site groeit best wel snel en daarom zitten we nu aan onze max. Althans, de RAM wordt bijna altijd voor minimaal 95% gebruikt.
Ik zit er nu aan te denken om te gaan upgraden naar 3GB RAM, maar ik las net een bericht van iemand dat het heel normaal is voor Linux systemen om alle RAM te gebruiken (ivm caching enzo).

Ik vind het prima als de server zoveel RAM gebruikt als die wilt, als hij maar niet daalt in performance.
De site runt heel snel, behalve op de punten wanneer de meeste gebruikers online zijn. Dan gaat hij denk ik over zijn limiet heen door pieken en dan loopt alles vast. (mysql krijgt table locks waardoor queries blijven opstapelen etc etc)

Bestaat er een mogelijkheid om te zorgen dat Linux niet álles gebruikt, maar maar 80%, zodat er ook ruimte overblijft voor pieken?
Ik zou het namelijk zonde vinden om er straks bij een nieuwe server erachter te komen dat hij exact hetzelfde doet, en dat het gewoon hoort bij Linux.

Met vriendelijke groet,
Wuggles

Linux (zeker in combinatie met bijvoorbeeld DIrectadmin oid) "vreet" bijna al het geheugen meteen op.
Dit is op zich normaal. Zodra je heftig begint te swappen naar de harddisk, dan moet je je zorgen gaan maken. Is dit ook het geval?

Je kunt ook kijken naar tuning van je mysql en apache. Dat helpt ook al een boel.

Weet je zeker dat het gebruikt is of dat caching het geheugen gebruikt? Je kan dit met `free -m` controleren.

Zoals de andere al adviseren, kijk eerst even hoeveel cache/buffer de server gebruikt en hoeveel daadwerkelijk gebruikt wordt. Wordt er gebruik gemaakt van swap, zo ja hoeveel wordt er gebruikt. Ga hierna aan de slag met optimalisatie van je mysql (index, correcte query's, ...) eventueel gebruik van mysql cache in het geval je dat niet doet. En in het geval je website zelf nog geen cache gebruikt kun je daar ook mee aan de slag. Want zolang je dit niet zult optimaliseren kan je zoveel mem bij pluggen of upgraden als je wilt maar het resultaat zal hetzelfde blijven.

Om te antwoorden op je andere vraag, ja je kan apache/mysql/... verhinderen om meer ram te gebruiken van bij de start, maar dit zal je wel problemen opleveren wanneer je meer nodig hebt en het dan niet meer beschikbaar is. Of dat je website bvb trager wordt omdat programma eerst vrije ram moet aanspreken om het dan te cache en op te laden, dan wanneer het al in cache zit.

Verder zou ik ook een monitoring programma installeren om te onderzoeken waar de bottleneck precies zit (cpu, ram, hd's, ...), want voor het zelfde geld is de i/o van de hd's niet vlug genoeg om je pieken op te vangen.

Mysql locks hebben meestal te maken met slechte queries, disk io of de mysql instellingen (mem)

Ik gok ook dat het in het verkeerd gebruik van MySQL zal zitten, in combinatie met een traag IO.

Ga even achter die console-toegang aan, wacht op een druk moment, en geef dan het commando

vmstat 1

Laat dat een minuut lopen en post hier even de uitvoer (afbreken met Ctrl-C).

Let wel opdat dat als je meer dan 2GB ram hebt je meestal 64bit nodig hebt of PAE ondersteuning in je Kernel ( http://en.wikipedia.org/wiki/Physical_Address_Extension )

Hmm, ik zweer dat ik hierop geantwoord heb.. blijkbaar is mijn post nog niet goedgekeurd?

Bedankt iig iedereen voor het antwoorden, ik ga nu meteen achter de login van m'n console aan.

Hier is de link naar een printscreen van mijn Process view.
Dit was van gisteravond en je kan zien dat er dus veel geswapt wordt.. 1 GB ongeveer.. later staat er dat 1.2 GB voor cache gebruikt wordt?

Je hebt 1.2GB aan cache, je hebt voldoende geheugen. Je zal het probleem ergens anders moeten zoeken, al aan optimalisatie gedaan?

MySQL optimalisatie heb ik best wat aandacht aan besteedt, maar het probleem is dat mijn spel waar het om gaat best wel groot is en je kan misschien wel begrijpen dat we liever op andere manieren optimaliseren dan dat we elke query gaan nakijken bijvoorbeeld. Het gaat hier om zo'n 1000 verschillende soorten queries in totaal denk ik.
Toch weet ik wel dat echt niet alle queries in orde zijn bij ons.

Ik heb een print screen gemaakt van mijn mysql status, misschien zien jullie daar iets vitaals in?
hier dus

Wuggles

Oorspronkelijk geplaatst door Wuggles

MySQL optimalisatie heb ik best wat aandacht aan besteedt, maar het probleem is dat mijn spel waar het om gaat best wel groot is en je kan misschien wel begrijpen dat we liever op andere manieren optimaliseren dan dat we elke query gaan nakijken bijvoorbeeld. Het gaat hier om zo'n 1000 verschillende soorten queries in totaal denk ik.
Toch weet ik wel dat echt niet alle queries in orde zijn bij ons.

Ik heb een print screen gemaakt van mijn mysql status, misschien zien jullie daar iets vitaals in?
hier dus

Wuggles

Ik heb het niet over het optimaliseren van de queries, maar van mysql zelf. Al http://mysqltuner.pl gedraait?

Hij geeft een waarschuwing over index gebruik.
123 GB aan data maakt geen goed gebruik van indexen.

Dat wil niet direct zeggen dat je nu overal index moet gaan gebruiken, maar goed moet kijken welke indexen er zijn of die wel optimaal worden gebruikt.
Maak je gebruik van MyISAM of InoDB?

Oorspronkelijk geplaatst door Wuggles

Hmm, ik zweer dat ik hierop geantwoord heb.. blijkbaar is mijn post nog niet goedgekeurd?

Bedankt iig iedereen voor het antwoorden, ik ga nu meteen achter de login van m'n console aan.

Hier is de link naar een printscreen van mijn Process view.
Dit was van gisteravond en je kan zien dat er dus veel geswapt wordt.. 1 GB ongeveer.. later staat er dat 1.2 GB voor cache gebruikt wordt?

Je leest de data verkeerd, je hebt 1GB swap in totaal waarvan maar 67MB in gebruik is. Dit is dus totaal te verwaarlozen, van je 2GB total ram heb je 1,2GB cache die vrij komt als een ander programma het nodig zou hebben. Dus daar zit het probleem ook niet, een upgrade naar 3GB ram zou alleen resulteren in meer gebruik van cache en je initieel probleem niet oplossen.

@Yourwebhoster Ah, mijn excuses. Nee MySQL optimalisatie zelf heb ik nooit heel veel naar gekeken. Wanneer ik weer toegang tot mijn Console heb zal ik dat uitvoeren.

@Rollerscapes Hmm, wat betekent deze 123GB aan data precies? Dit is geen bandwidth oid, dus gebruikt hij dat op de server zelf teveel dan?

@The-BosS Bedankt.. dat scheelt een hoop. Hoe kan ik ervoor zorgen dat ik de data wel goed laat lezen? Wat zit er precies in die cache?

Oorspronkelijk geplaatst door Wuggles

@The-BosS Bedankt.. dat scheelt een hoop. Hoe kan ik ervoor zorgen dat ik de data wel goed laat lezen? Wat zit er precies in die cache?

Dit kan je het beste zien met 'htop' of 'free -m' of andere tools dan de default top. Maar begin dus eerst even met de optimalisatie van je website (mysql, cache, ...), misschien ook handig dat je even vermeld hoeveel connecties (users) per seconde je over de vloer krijgt op piek momenten. Want wie weet is je vps en server indeling gewoon veel te laag voor wat je wilt doen.