Onderwerp: Server crash

Hallo,

Mijn server is onlangs gecrashed doordat het geheugen vol zat en de CPU op 100% zat te stampen. Dit bij zo'n 350 gelijktijdige gebruikers (live data). Deze VPS (Tilaa) fungeert als endpoint voor een publieke api (niet zwaar). Verwacht binnenkort een piek van zo'n 1250/1500 gelijktijdige gebruikers die de api consumeren

Wat opvalt is de hoge swap lezen/schrijven resp 11.7/4.7 GB

Netwerk in/uit is 164 MB / 1.3 GB

Nu kan ik een hogere CPU en meer geheugen nemen maar weet niet zeker hoeveel ik moet nemen en of dat het probleem oplost. Is het beter om zoveel mogelijk geheugen te nemen of juist CPU? Jullie een idee?

Tilaa VPS
2048MB
2 x 2.4 Ghz @ 60%
10 GB HDD

Centos 6.4
PHP 5.4
MySql

Push data via nodejs/socketio

Dit is natuurlijk niet op te bouwen uit de gegevens. Hoeveel CPU gebruikt een proces, hoeveel geheugen gebruikt datzelfde proces, enzovoort. Nogal karige server gezien er MySQL op draait. Bedoel je met -tegelijk- ook echt tegelijk, dwz doen die bezoekers op exact hetzelfde tijdstip iets? Als dat proces updates/inserts in MySQL gaat doen en er daadwerkelijk 1500 tegelijk dat doen mag je wel een toffe bak neerzetten.

Je kan dan of flink capaciteit neerzetten (aparte dbserver met bv 16 cores + 20G memory + SSD storage) en een iets lichtere webserver, je kan ook de site zo optimaliseren dat dit niet nodig is (Varnish, Redis, Memcached, etc, etc), maar wij weten niet wat je precies doet voor elke bezoeker

Api is alleen lezen. Data wordt gecached op de vps

Het gaat om live scores. Bij een wijziging wordt de nieuwe uitslag gepushed

Mooi, klinkt als goed cachebaar. Zet er Varnish voor en flush de specifieke pagina uit Varnish wanneer er een wijziging in de score is. Gaat sowieso lukken met de huidige specs.

Caching wordt nu gedaan door Laravel's (php framework) file cache

Ik de docu staat "For larger applications, it is recommended that you use an in-memory cache such as Memcached or APC.". Ik zou zeggen dat dit wel van toepassing is op jezelf toch . Echter zag ik ook Redis support staan. Ik zou daarbij voor Redis gaan, dat biedt voordelen tov Memcached en APC.

Varnish is overigens niet hetzelfde. Varnish zet je voor Apache en cached de hele pagina in principe. Dat is sowieso nog sneller en geeft nog meer capaciteit, maar is ook het lastigst goed te implementeren.

De definitie van 'larger application' is natuurlijk een beetje vaag. Een max van 1500 gebruikers gedurende 5 uur (wedstrijddag) klinkt mij eigenlijk niet als heel veel. Vergis ik mij daarin?

Het was net 1500 tegelijk, nu is het wel een stuk lager . Heb je de Tilaa VPS met SSD storage of met HDD?

Nee bedoel 5 uur lang op elk moment 1500. Wel degelijk 1500 tegelijk dus Daarna een drop richting 100

Draait niet op SSD

Die cache die je nu dus gebruikt slaat alles op trage harddisks op. Er moet dus 1500x tegelijk van die schijf gelezen worden, wat elke keer weer search times etc kost. Je wil die data dus uit je werkgeheugen serveren, want dat is honderden keren sneller. Je kan dat doen met het eerder genoemde Redis (of Memcached of zelfs een tmpfs). Upgraden naar SSD storage zal ook al schelen, hoewel je dan misschien nog niet de volle 1500 gaat redden. MySQL gaat in ieder geval ook een stuk vlotter op SSD storage.

Oorspronkelijk geplaatst door SF-Jeroen

Die cache die je nu dus gebruikt slaat alles op trage harddisks op. Er moet dus 1500x tegelijk van die schijf gelezen worden, wat elke keer weer search times etc kost. Je wil die data dus uit je werkgeheugen serveren, want dat is honderden keren sneller. Je kan dat doen met het eerder genoemde Redis (of Memcached of zelfs een tmpfs). Upgraden naar SSD storage zal ook al schelen, hoewel je dan misschien nog niet de volle 1500 gaat redden. MySQL gaat in ieder geval ook een stuk vlotter op SSD storage.

Die cache files worden al door het filesystem in ram gecached, ook al staan ze initieel op disk.
Swappen krijg je alleen door een gebrek aan ram, dus je moet eerst naar de exacte oorzaak kijken van dat ramgebruik voordat je nog meer ram gaat opmaken aan verschillende caching mogelijkheden.

Kan ik dat nog terugzien met terugwerkende kracht? Welke commando's moet ik dan uitvoeren? Is die 100% CPU te verklaren doordat hij enorm aan het swappen was? Dus doordat er een gebrek aan ram was en is gaan swappen en dat ie daarom naar 100% ging?

Werk dat in grote lijnen zo?

Als ie aan het swappen is (wat behoorlijk traag is zoals Jeroen al zei) dan kun je eigenlijk geen pijl meer trekken op wat verder gebeuren gaat. Als je apache processen gaan oplopen omdat je geen ram hebt en de boel uit de swap moet komen dan kom je vroeg of laat zelfs op een punt dat je cpu alleen nog maar bezig is met processen switchen en dat er verder niks meer gebeurd behalve een crash.

Maar met gezond verstand kun je wel een eind komen. Je kunt met top eens kijken wat je http processen aan geheugen gebruiken en je maximum aantal processen zodanig aanpassen dat het binnen je ram valt. Dat is wel een erg laag aantal dan, maar de kans dat je bak onderuit gaat is dan wel klein. Dat aantal kun je dan langzaamaan weer opvoeren.

Wat je eigenlijk moet uitvogelen is hoeveel processen je per seconde aan wilt kunnen en wat mogelijk is op je vps. Als het 0,01 seconde duurt om je data uit mysql te krijgen en naar buiten te spugen, dan weet je bv al dat je niet op meer dan 100 requests per seconde hoeft te rekenen.

Een benchmarktool zoals 'ab' kan wel eens goed inzicht geven in hoeveel concurrent users je aankunt.

Bij de meeste cloud providers kan je elk moment schalen. Misschien kan je ervoor kiezen om omhoog te schalen in het weekend. Hier beschrijft iemand eenzelfde probleem met 1GB ram en 1000 clients: http:// blog.lightstreamer.com/2013/05/benchmarking-socketio-vs-lightstreamer.html . Loop je nodejs applicatie eens na of deze wel geoptimaliseerd is.

Je zou munin kunnen installeren om statistieken bij te houden van je vps.

Ik ga ermee aan de slag. Dank allemaal. Meer tips zijn welkom!