Vpsje upgraden?

[Saven]

Yoo,
Ik heb enige tijd een VPS waar ik een bepaald platform op host met tegenwoordig iets meer dan 100 users. 't Is een soort beheeromgeving voor de users. Op de achtergrond draaien veel cronjobs c.q. tasks. Platform is een PHP systeem (specifiek Kohana framework).

Omdat ik gebruikmaak van het ORM systeem en het een best complex systeem is met soms veel database rows (100K rows voor 20 users ofzo) is het systeem niet meer zo snel voor een user als een jaar geleden 't is niet tergend traag, maar ik hou van snelle response en dat de boel 'snappy' is. Wanneer een user zijn overzicht laadt is de parsetime soms wel 1,5seconden

Als ik mijn VPS upgrade van 2 (Xeon) cores naar 4 cores, wordt de boel dan ook sneller? De cpu is meestal idle, de meeste load komt van de cronjobs/tasks.. De users zijn meestal niet aanwezig in de beheeromgeving, die komen er bij wijze van spreke maar 1 keer per maand.

Ik kom er zelf niet helemaal uit, ik lees dat multi core processors nut kunnen hebben voor meerder applicaties tegelijkertijd. Overige resultaten hebben vooral betrekking op desktop apps en ook daar zijn de meningen blijkbaar over verdeel

Iemand een idee of het de moeite waard is om te upgraden? 't Is bijna een verdubbeling van de kosten

[Verwijderd]

Heb enige tijd geleden hetzelfde probleem gehad. Overwoog toen ook om m'n VPS te upgraden, uiteindelijk ook gedaan. Wat bleek; dit had weinig met de snelheid v.d. verwerking van (MySQL) database rows te maken... Geen effect dus... Een gevalletje "Plaats een Ferrari motor in een Volkswagen" .. Je kunt beter overwegen om je database rows en structure eens goed onder de loep te nemen en misschien (laten) optimaliseren? Ook kan een upgrade van MySQL of PHP naar de nieuwste versie nogal eens schelen. Plan B kan dan altijd nog een VPS upgrade zijn.
Succes

[Firesphere]

Kijk eens naar je indexes op de SQL database bijvoorbeeld. En de hoeveelheid objecten die PHP zou moeten verwerken. Door dat te cachen of effectiever in te richten, haal je veel meer snelheidswinst dan meer hardware er tegenaan gooien.

[Saven]

Ja, optimalisatie wordt zeker nog aan gewerkt Indexes zijn overal netjes al aanwezig overigens. Maar dat was niet helemaal wat ik wilde weten

[JackBol]

Waarom doet de query er 1,5 seconde over? Waar staat het systeem op te wachten?
Ik heb het gevoel dat de bottleneck eerder de leestoegang tot storage is dan de CPU.

[MAX3400]

Geen idee wat je VPS nu kost en wat de upgrade kost. Je zou allicht even kunnen kijken bij een hoster als https://www.digitalocean.com/ om daar een grote VPS te deployen en dan jouw "nieuwe setup" te testen; je betaalt toch per uur dus mogelijk kost het je een paar Euro per dag om een quadcore CPU met 8GB RAM op SSD-storage te testen.

Verder vraag ik me inderdaad af of je geen logging hebt van je huidige VPS waarin metingen van bepaalde zaken worden opgeslagen. Niet alleen van MySQL maar ook bepaalde wait-times van de kernel zelf. Ook mis ik even of/wat voor caching er plaatsvindt op de huidige VPS waardoor je minder van disk maar meer uit RAM kan opvragen.

Multicore CPU's kunnen helpen met een snellere ervaring maar als jouw task, software, whatever daar niet geschikt voor is (of niet goed compileerd), heb je kans dat zelfs op een nieuwe Xeon decacore met HT, je maar 1 core gaat gebruiken.

[gekkie]

Hoeveel geheugen zit erin ?
(en wordt ook alles door je DB gebruikt, vaak is de default config van linux distributies vrij conservatief)

Vaak is bij databases die uitdijen geheugen eerder een probleem dan raw cpu power.
Aangezien het een VPS is .. is meestal de IO betrekkelijk beroerd, dus alles wat niet gecached is in het geheugen duurt vrij lang voor een lookup.

[Saven]

JackBol schreef op zaterdag 27 februari 2016 @ 11:42:
Waarom doet de query er 1,5 seconde over? Waar staat het systeem op te wachten?
Ik heb het gevoel dat de bottleneck eerder de leestoegang tot storage is dan de CPU.

Het is een uitgebreid ORM dingetje, niet zomaar simpele queries. Waaronder dus gebrek aan joins Maar dat is niet zo boeiend an sich, heb voor de ORM opzet gekozen vanwege de eenvoud, dus gewone queries worden vrijwel niet gebruikt

gekkie schreef op zaterdag 27 februari 2016 @ 11:43:
Hoeveel geheugen zit erin ?
(en wordt ook alles door je DB gebruikt, vaak is de default config van linux distributies vrij conservatief)

Vaak is bij databases die uitdijen geheugen eerder een probleem dan raw cpu power.
Aangezien het een VPS is .. is meestal de IO betrekkelijk beroerd, dus alles wat niet gecached is in het geheugen duurt vrij lang voor een lookup.

Ehh 1 gb, Dat is volgens mij ook nog wel voldoende
IO valt wel mee denk ik, worden niet achterlijk veel files geladen

[ Voor 36% gewijzigd door Saven op 27-02-2016 11:53 ]

[MAX3400]

Saven schreef op zaterdag 27 februari 2016 @ 11:52:
[...]

Het is een uitgebreid ORM dingetje, niet zomaar simpele queries. Waaronder dus gebrek aan joins Maar dat is niet zo boeiend an sich, heb voor de ORM opzet gekozen vanwege de eenvoud, dus gewone queries worden vrijwel niet gebruikt

Oke, geen random queries maar ook geen joins? Neem aan dat voor 95% van de werkzaamheden er wel stored procedures of andere zaken zijn ingeregeld? Of is elke klik van elke user uiteindelijk een volledige custom query naar de DB?

Saven schreef op zaterdag 27 februari 2016 @ 11:52:
[...]

Ehh 1 gb, Dat is volgens mij ook nog wel voldoende
IO valt wel mee denk ik, worden niet achterlijk veel files geladen

1GB??? Voor een VPS? Daar draait dus je OS op, de applicatie zelf, eventueel je http-daemon & PHP en dan ook nog MySQL?

Ik zou je bijna adviseren; bouw de inhoud van je eigen VPS een na op een lokale VM met VMware of iets dergelijks en gooi er een 4GB RAM tegenaan. Ik denk dat daar dus de grootste winst te halen valt.

[ Voor 34% gewijzigd door MAX3400 op 27-02-2016 11:57 ]

[Saven]

MAX3400 schreef op zaterdag 27 februari 2016 @ 11:56:
[...]

1GB??? Voor een VPS? Daar draait dus je OS op, de applicatie zelf, eventueel je http-daemon & PHP en dan ook nog MySQL?

Ik zou je bijna adviseren; bouw de inhoud van je eigen VPS een na op een lokale VM met VMware of iets dergelijks en gooi er een 4GB RAM tegenaan. Ik denk dat daar dus de grootste winst te halen valt.

Hehe zou dat zoveel opleveren? Er is altijd genoeg ram vrij volgens mij. Direct Admin laat ook nog het volgende zien (lijk op 4gb ipv 1?):
Total Memory 4194304 kB
Free Memory 3282204 kB

Dus weet niet hoe dat zit. Zit overigens op deze 1e vps: https://www.fxw.nl/vps/managed-premium-vps/

edit: swap is wel 1gb
Total Swap Memory 1048576 kB
Free Swap Memory 421404 kB

[ Voor 6% gewijzigd door Saven op 27-02-2016 12:02 ]

[McKaamos]

Saven schreef op zaterdag 27 februari 2016 @ 11:59:
[...]

Hehe zou dat zoveel opleveren? Er is altijd genoeg ram vrij volgens mij. Direct Admin laat ook nog het volgende zien (lijk op 4gb ipv 1?):
Total Memory 4194304 kB
Free Memory 3282204 kB

Dus weet niet hoe dat zit. Zit overigens op deze 1e vps: https://www.fxw.nl/vps/managed-premium-vps/

Da's aleen wat gebruikt wordt door kernel en applicaties/daemons, ja.
Echter, wat Linux doet, is de rest van het geheugen gebruiken voor caching.

Log voor de grap eens in met SSH en kijk eens met het commando htop.
Dan zie je hoeveel er daadwerkelijk cache is.
Als er nog een ruime hoeveelheid geheugen vrij is na de cache (als in, meer dan 10%), is extra geheugen onbelangrijk. Zit je tussen de laatste 10% en volledig gevuld, dan heb je baat bij meer RAM.

[MAX3400]

Saven schreef op zaterdag 27 februari 2016 @ 11:59:
[...]

Hehe zou dat zoveel opleveren? Er is altijd genoeg ram vrij volgens mij. Direct Admin laat ook nog het volgende zien (lijk op 4gb ipv 1?):
Total Memory 4194304 kB
Free Memory 3282204 kB

Dus weet niet hoe dat zit. Zit overigens op deze 1e vps: https://www.fxw.nl/vps/managed-premium-vps/

DirectAdmin logt niet in op jouw VPS. De VPS is geschaald, volgens het linkje, op 1GB RAM. DirectAdmin laat "waarschijnlijk" de virtual node zien want hij zegt toch echt dat er 4GB in zit en 3.1GB vrije ruimte.

Een hele simpele berekening; als jij inderdaad de virtual node ziet en je bent de enige user, gebruik je dus 900MB voor jouw VPS en dat is dus al 90% van de toegewezen ruimte. Maar jouw hoster kan mogelijk de waarden in DirectAdmin wel uitleggen?

[ Voor 3% gewijzigd door MAX3400 op 27-02-2016 12:03 ]

[Saven]

McKaamos schreef op zaterdag 27 februari 2016 @ 12:02:
[...]

Da's aleen wat gebruikt wordt door kernel en applicaties/daemons, ja.
Echter, wat Linux doet, is de rest van het geheugen gebruiken voor caching.

Log voor de grap eens in met SSH en kijk eens met het commando htop.
Dan zie je hoeveel er daadwerkelijk cache is.
Als er nog een ruime hoeveelheid geheugen vrij is na de cache (als in, meer dan 10%), is extra geheugen onbelangrijk. Zit je tussen de laatste 10% en volledig gevuld, dan heb je baat bij meer RAM.

htop is volgens mij niet geïnstalleerd, ben ook niet een echte unix held, vandaar de 'managed' vps

Anyway heb je hier wat aan?

top - 12:03:51 up 487 days, 18:16, 1 user, load average: 0.80, 0.40, 0.16
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 0.3%sy, 0.2%ni, 98.2%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4194304k total, 939808k used, 3254496k free, 0k buffers
Swap: 1048576k total, 626636k used, 421940k free, 156800k cached

[MAX3400]

Saven schreef op zaterdag 27 februari 2016 @ 12:07:
[...]

htop is volgens mij niet geïnstalleerd, ben ook niet een echte unix held, vandaar de 'managed' vps

Anyway heb je hier wat aan?

top - 12:03:51 up 487 days, 18:16, 1 user, load average: 0.80, 0.40, 0.16
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 0.3%sy, 0.2%ni, 98.2%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4194304k total, 939808k used, 3254496k free, 0k buffers
Swap: 1048576k total, 626636k used, 421940k free, 156800k cached

Mmm, simpele samenvatting zonder achtergrond:
- 1GB RAM used
- 600MB swap used
- 1 running proces
- onbekend aantal users ingelogd

Je uptime is wel netjes hoog; neem aan dat wel alle updates/packages correct zijn?

Goed weekend alvast

[McKaamos]

Saven schreef op zaterdag 27 februari 2016 @ 12:07:
[...]

htop is volgens mij niet geïnstalleerd, ben ook niet een echte unix held, vandaar de 'managed' vps

Anyway heb je hier wat aan?

top - 12:03:51 up 487 days, 18:16, 1 user, load average: 0.80, 0.40, 0.16
Tasks: 68 total, 1 running, 67 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 0.3%sy, 0.2%ni, 98.2%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4194304k total, 939808k used, 3254496k free, 0k buffers
Swap: 1048576k total, 626636k used, 421940k free, 156800k cached

Die laatste waarde, 156MB cached, samen met de bijna 1GB used, vult het RAM wel volgens mij. Stampvol, inclusief ruim de helft van je swapspace gevuld. Daar mag wel een giegje of 2 bij, me dunkt
Waar die 4GB vandaan komt durf ik zo niet te zeggen, maar dat zal de host zijn, zoals MAX zegt. En dan een memoryballoon die jou beperkt tot 1GB, maar zodat er makkelijk opgeschaald kan worden door extern de balloon kleiner te maken.

Edit: Ik ben ook geen unixheld trouwens. Maar htop is overzichtelijker dan top. Je kan vast wel htop installeren.
Iets van 'sudo apt-get install htop', 'sudo yum install htop', of welke packagemanager er ook maar op staat.
Ik zou het RAM iig upgraden naar 4GB en de databaseconfiguratie nalopen.
Er is een bestandje, my.cnf, waar de configuratie in staat. Er zijn ook wel wat templateversies van dat bestand aanwezig op een stock linux install, zoals my.cnf-medium, my.cnf-large, etc.
Daar kan je wel wat voorbeelden uit halen zodat je maximaal ge-/misbruik maakt van de hoeveelheid RAM en daarmee een speedboost produceert voor je database transacties.

[ Voor 24% gewijzigd door McKaamos op 27-02-2016 12:27 ]

[Soldaatje]

Je kan ook beter eerst uitzoeken wat zoveel geheugen gebruikt, en dan pas eventueel upgraden.
Misschien een simpele instelling, mysql beperken tot zoveel MB bijvoorbeeld.

[Thralas]

MAX3400 schreef op zaterdag 27 februari 2016 @ 12:16:
Je uptime is wel netjes hoog; neem aan dat wel alle updates/packages correct zijn?

Het is maar net wat je netjes noemt. Als TS z'n eigen kernel draait (you should) dan loopt 'ie 1001 securityfixes achter. En de recente glibc bugs zijn ook het snelst uit te roeien met een reboot na de update.

McKaamos schreef op zaterdag 27 februari 2016 @ 12:16:
Die laatste waarde, 156MB cached, samen met de bijna 1GB used, vult het RAM wel volgens mij.

Volgens mij is die 156 MB SwapCached, dus dat gaat over swap space (daarom staat het ook op de swap-regel) en heeft dan niets met RAM te maken.

Stampvol, inclusief ruim de helft van je swapspace gevuld. Daar mag wel een giegje of 2 bij, me dunkt.
Waar die 4GB vandaan komt durf ik zo niet te zeggen, maar dat zal de host zijn, zoals MAX zegt. En dan een memoryballoon die jou beperkt tot 1GB, maar zodat er makkelijk opgeschaald kan worden door extern de balloon kleiner te maken.

Die laatste kwestie zou ik eerst uitzoeken alvorens te concluderen of er geheugen tekort is of niet. En wordt er uberhaupt actief geswapped (zie vmstat)? Dat is natuurlijk nogal desastreus voor de performance.

Welke virtualisatietechniek wordt er gebruikt TS?

[The Eagle]

Zo te lezen heb je voor je DB 1GB ram in gebruik, en das weinig. Dan kan ie dus ook weinig cachen
Check verder eens de staleness van je indexen. Klinkt namelijk alsof de DB optimizer gewoon full table scans doet ipv indexen gebruiken.

[gekkie]

Saven schreef op zaterdag 27 februari 2016 @ 11:52:
Ehh 1 gb, Dat is volgens mij ook nog wel voldoende
IO valt wel mee denk ik, worden niet achterlijk veel files geladen

Erhmmm je DB doet natuurlijk ook IO .. en afhankelijk van hoe groot je DB is en je queries kan dat nogal oplopen. Denk dat als je niets wijzigt aan geheugen en snellere storage .. het toevoegen van raw cpu power weinig gaat opleveren. Hoe groot is je DB inmiddels (inclusief indexen en de hele rambam) ?

Maar goed zoals iedereen eerder al aangaf .. als je het echt zeker wil weten zul je het toch moeten uitzoeken door te kijken die queries van 1500ms .. doe een explain .. gebruikt het ook werkelijk de index of niet .. doet het ding allemaal ingewikkelde joins die eigenlijk niet echt nodig zouden moeten hoeven zijn .. kijk naar je cache hit ratio .. komt het uit geheugen cache of moet het toch vanaf storage komen.

Update: Erhmmm tsja als je al swap gaat gebruiken dan zijn alle bets wel zo ongeveer off.
vind ik 1,5 seconde nog rap

[ Voor 5% gewijzigd door gekkie op 27-02-2016 13:20 ]

[Saven]

McKaamos schreef op zaterdag 27 februari 2016 @ 12:16:
[...]

Die laatste waarde, 156MB cached, samen met de bijna 1GB used, vult het RAM wel volgens mij. Stampvol, inclusief ruim de helft van je swapspace gevuld. Daar mag wel een giegje of 2 bij, me dunkt
Waar die 4GB vandaan komt durf ik zo niet te zeggen, maar dat zal de host zijn, zoals MAX zegt. En dan een memoryballoon die jou beperkt tot 1GB, maar zodat er makkelijk opgeschaald kan worden door extern de balloon kleiner te maken.

Edit: Ik ben ook geen unixheld trouwens. Maar htop is overzichtelijker dan top. Je kan vast wel htop installeren.
Iets van 'sudo apt-get install htop', 'sudo yum install htop', of welke packagemanager er ook maar op staat.
Ik zou het RAM iig upgraden naar 4GB en de databaseconfiguratie nalopen.
Er is een bestandje, my.cnf, waar de configuratie in staat. Er zijn ook wel wat templateversies van dat bestand aanwezig op een stock linux install, zoals my.cnf-medium, my.cnf-large, etc.
Daar kan je wel wat voorbeelden uit halen zodat je maximaal ge-/misbruik maakt van de hoeveelheid RAM en daarmee een speedboost produceert voor je database transacties.

Hmm zal dat eens checken vdweek, hoop dat ik er uit kom

Thralas schreef op zaterdag 27 februari 2016 @ 12:49:

Welke virtualisatietechniek wordt er gebruikt TS?

Ik heb eerlijk gezegd geen idee , kan ik dat ergens in DirectAdmin vinden? Zij zouden in principe alles van updates moeten voorzien.

gekkie schreef op zaterdag 27 februari 2016 @ 13:17:
[...]

Erhmmm je DB doet natuurlijk ook IO .. en afhankelijk van hoe groot je DB is en je queries kan dat nogal oplopen. Denk dat als je niets wijzigt aan geheugen en snellere storage .. het toevoegen van raw cpu power weinig gaat opleveren. Hoe groot is je DB inmiddels (inclusief indexen en de hele rambam) ?

Maar goed zoals iedereen eerder al aangaf .. als je het echt zeker wil weten zul je het toch moeten uitzoeken door te kijken die queries van 1500ms .. doe een explain .. gebruikt het ook werkelijk de index of niet .. doet het ding allemaal ingewikkelde joins die eigenlijk niet echt nodig zouden moeten hoeven zijn .. kijk naar je cache hit ratio .. komt het uit geheugen cache of moet het toch vanaf storage komen.

Update: Erhmmm tsja als je al swap gaat gebruiken dan zijn alle bets wel zo ongeveer off.
vind ik 1,5 seconde nog rap

Database is innoDB, als ik me niet vergis wordt daarmee RAM gebruikt ipv harddisk toch?
Wat betreft de swap, er is nog RAM vrij, dus ik snap ook niet helemaal waarom de swap wordt gebruikt.

Ik ben de rest van het weekend even afwezig maar kom zo snel mogelijk er op terug

[Thralas]

Saven schreef op zaterdag 27 februari 2016 @ 14:10:
Ik heb eerlijk gezegd geen idee , kan ik dat ergens in DirectAdmin vinden?

Volgens het internet is het Xen. Je hoster heeft het niet eens expliciet op hun site staan (?!).

Onder Xen schijnt de balloon driver (indien aanwezig) soms stats te exporteren naar /proc/xen/balloon.

Alleen zou je verwachten dat deze 'gereserveerd' geheugen daadwerkelijk consumeert, dan kan ik niet helemaal rijmen met die 3G free.

Zij zouden in principe alles van updates moeten voorzien.

Wie is zij? DirectAdmin? Of de hoster? Je linkte eerder naar een 'managed' VPS. Je kernel suggereert dat er weinig gemanaged wordt. Slechte zaak, wat mij betreft.

Mocht je er uiteindelijk concluderen dat upgraden de oplossing is zou ik ook naar alternatieve hosters kijken - ik heb een vermoeden dat je I/O performance ook niet wereldschokkend is met die SAS storage.

[Erulezz]

Wat voor OS heb je? Als je CentOS o.i.d. draait doe eens voor de grap:

yum check-upgrade / yum check-update

Ben heel erg benieuwd hoeveel packages er klaar staan om te updaten als ik je uptime zie.
Heb je al eens een disk speedtest gedaan?

[ Voor 15% gewijzigd door Erulezz op 27-02-2016 17:50 ]

[Saven]

Erulezz schreef op zaterdag 27 februari 2016 @ 17:49:
Wat voor OS heb je? Als je CentOS o.i.d. draait doe eens voor de grap:

yum check-upgrade / yum check-update

Ben heel erg benieuwd hoeveel packages er klaar staan om te updaten als ik je uptime zie.
Heb je al eens een disk speedtest gedaan?

Dat zijn er inderdaad nogal wat Voordeel bij fxw is dat als ik wat sloop of geïnstalleerd/geconfigureerd moet hebben dat zo gedaan is door hun. Disk speedtest nog niet gedaan, geen idee hoe


Misschien eens kijken naar transip ssd vpsjes dan, mijn serverbeheerkennis is niet zo heel hoog.

[ Voor 3% gewijzigd door Saven op 02-03-2016 11:29 ]