Probleem met processen / Linux / PHP

[dakathefox]

Mijn vraag
Mijn server draait gemiddeld zo'n 150 taken per seconde. Eens per twee minuten draai ik een groot proces, dat ongeveer 30 seconden draait. De grootste afhankelijkheid daarbij is de beschikbaarheid van een externe API. Eens per minuut draai ik 10 kleinere processen, die duren allen ongeveer 10-20 seconden. En eens per kwartier heb ik een 10-tal grotere processen draaien, die soms 10 seconden duren, maar ook met een gerust hart 5 minuten.

Helaas loopt de boel met regelmaat vast. De vraag is dan ook: wat is wijsheid? Andere webserver software? Nog meer CPU? En verder: wat is slimmer: 100 kleine processen van 10 seconden of 10 grote processen van 100 seconden?

Relevante software en hardware die ik gebruik
Op dit moment heb ik een VPS bij Digital Ocean. 8 GB intern geheugen, 4 virtuele processoren. Op het OS draait Ubuntu LTE, in combinatie met Apache en Nginx. Alle overbodige systeemprocessen zijn gedeactiveerd, dus naast een firewall draait er verder niets bijzonders.

Wat ik al gevonden of geprobeerd heb
Cronjobs aangepast, maximale verwerkingstijden ingesteld, kleinere batches.

[Feanathiel]

Wat bedoel je specifiek met vastlopen? Dit kan namelijk sterk variëren, waardoor ook oorzaken sterk uiteen lopen.

Om even een begin te maken:
- Kun je nog naar de VPS verbinden wanneer het zaakje vastloopt?
- (te) Veel resources in gebruik? (cpu, geheugen, processes/threads)
- Gaat het om deadlocks?

[ Voor 46% gewijzigd door Feanathiel op 20-07-2016 22:08 ]

[dakathefox]

Ik kan nog steeds verbinding maken met de server om een reboot uit te voeren. Maar ik merk gewoon dat de server niet meer reageert als ik een browser open en een link aanklik.

Dit is hoe de server standaard draait. Op piekmomenten schiet het aantal taken naar 1500, waarvan 1400 zombie.

Tasks: 154 total, 1 running, 153 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.6 us, 0.5 sy, 0.4 ni, 96.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 8176816 total, 669260 used, 7507556 free, 82812 buffers
KiB Swap: 524284 total, 0 used, 524284 free. 279080 cached Mem

En vastloper:

Tasks: 894 total, 21 running, 788 sleeping, 0 stopped, 85 zombie
%Cpu(s): 28.9 us, 71.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 8176816 total, 1132696 used, 7044120 free, 87888 buffers
KiB Swap: 524284 total, 0 used, 524284 free. 281400 cached Mem

[ Voor 21% gewijzigd door dakathefox op 20-07-2016 22:43 ]

[GlowMouse]

Probeer de bottleneck te vinden. Wat geeft bv. "iostat -dx 1"? Zijn er teveel open netwerkverbindingen of geopende files?

[Biersteker]

inderdaad kijk even naar io (bijv met iotops). Misschien dat je replication/logging vertraagd in geval van sql queries. (dus hoge jbd2 io ipv sql )

[Ventieldopje]

Helaas loopt de boel met regelmaat vast. De vraag is dan ook: wat is wijsheid? Andere webserver software?

Nee.. de vraag is waar gaat het mis? Wat is "vastlopen" volgens jou?

[dakathefox]

Biersteker schreef op woensdag 20 juli 2016 @ 23:02:
inderdaad kijk even naar io (bijv met iotops). Misschien dat je replication/logging vertraagd in geval van sql queries. (dus hoge jbd2 io ipv sql )

SQL queries heb ik niet :-) Dus dat kan in ieder geval niet. Wel schrijf ik veel files weg.

[Tjolk]

Welke PHP versie praat je hierover? PHP 7 heeft bijvoorbeeld enorm veel performance verbeteringen gebracht. En heb je al onderzocht of het te herleiden valt naar specifieke processen? Vallen die wellicht over te hevelen naar een andere server, of valt daar in het proces wat te optimaliseren?

Meer ijzer kan altijd nog, maar is niet altijd een (goede) oplossing.

[HollowGamer]

Zonder logging wordt het moeilijk..

[True]

Ik heb geen antwoord op je vraag maar ik ben wel benieuwd waarom je bij jouw VPS een GUI nodig hebt en je dit niet remote zou kunnen afhandelen?

[Ventieldopje]

True schreef op donderdag 21 juli 2016 @ 13:19:
Ik heb geen antwoord op je vraag maar ik ben wel benieuwd waarom je bij jouw VPS een GUI nodig hebt en je dit niet remote zou kunnen afhandelen?

GUI? Ubuntu kun je ook prima headless zonder X en alle meuk draaien, dat is ook wat hij doet neem ik aan.

[Tjolk]

mind123 schreef op donderdag 21 juli 2016 @ 09:11:
[...]
Wel schrijf ik veel files weg.

Hier las ik eerder overheen, maar kan wel relevant zijn in het kader van performance. Zo heb ik bij CodeIgniter een keer geconstateerd dat bij de file handler voor iedere call naar write_file() (shorthand voor o.a. fopen(), fwrite() en fclose() ) een exlcusive flock() gedaan werd. Dat zorgde voor een hoop overhead, zeker bij de filecaching die hier ook hevig op leunde. Totale serverload destijds nam met zo'n 30% af toen we dat aangepakt hadden.

Nu heb je totaal geen informatie gegeven over wat voor processen je praat, maar wellicht kan in het geval van een framework ook iets dergelijks spelen.

[True]

Ventieldopje schreef op donderdag 21 juli 2016 @ 13:46:
[...]


GUI? Ubuntu kun je ook prima headless zonder X en alle meuk draaien, dat is ook wat hij doet neem ik aan.

Ja dat weet ik ook alleen verbaasde mij dit:

Ik kan nog steeds verbinding maken met de server om een reboot uit te voeren. Maar ik merk gewoon dat de server niet meer reageert als ik een browser open en een link aanklik.

[SPee]

mind123 schreef op donderdag 21 juli 2016 @ 09:11:
[...]
SQL queries heb ik niet :-) Dus dat kan in ieder geval niet. Wel schrijf ik veel files weg.

Een VPS draait veelal vanaf een SAN. Bestanden wegschrijven betekent dus dat deze over het netwerk gaan. Dus veel IO beketent netwerk IO, wat een hogere latency heeft dan lokaal. Per record naar bestand wegschrijven kan dan langer duren dan deze inmemory houden en pas aan het eind volledig wegschrijven.
Dus kijk of je kan aanpassen dat er "per bulk" wordt weggeschreven.

• Generatie proces aanpassen zodat het bestand pas op het eind wordt geschreven
• Wegschrijven naar een Ram FS en deze (periodiek) naar de doel verplaatsen

In hoeverre dit haalbaar is hangt af hoe groot die bestanden worden. Zijn het kleine bestanden, dan zou dit makkelijk kunnen. Schrijf je MB's of GB's weg, dan gaat dat natuurlijk wat moeizamer. (maar verklaart ook waarom het traag gaat )

[Ventieldopje]

True schreef op donderdag 21 juli 2016 @ 14:41:
[...]


Ja dat weet ik ook alleen verbaasde mij dit:


[...]

Ik hoop toch dat hij bedoelt dat hij een browser opent op zijn eigen PC en vervolgens de server probeert te benaderen die niet reageert

[DJMaze]

mind123 schreef op woensdag 20 juli 2016 @ 21:57:
Wat ik al gevonden of geprobeerd heb
Cronjobs aangepast, maximale verwerkingstijden ingesteld, kleinere batches.

Die cronjobs zijn toch geen http requests?
Dus niet:

code:

wget http....

Maar:

code:

php /home/location/to/file.php

Of:

code:

sh /home/location/to/file.php

[ Voor 6% gewijzigd door DJMaze op 21-07-2016 17:07 ]

[True]

Ventieldopje schreef op donderdag 21 juli 2016 @ 15:26:
[...]


Ik hoop toch dat hij bedoelt dat hij een browser opent op zijn eigen PC en vervolgens de server probeert te benaderen die niet reageert

Dat hoop ik ook ten zeerste, alleen de wat vreemde zinsbouw, onduidelijk uitleg en "een browser en een link" vind ik het nogal wat vaag worden.
Vandaar dus mijn initiële vraag

[Ventieldopje]

DJMaze schreef op donderdag 21 juli 2016 @ 17:06:
[...]

Die cronjobs zijn toch geen http requests?
Dus niet:

code:

wget http....

Maar:

code:

php /home/location/to/file.php

Of:

code:

sh /home/location/to/file.php

Dan nog heb je wel een maximale verwerkingstijd van PHP

offtopic:
Wacht, heb je NGINX niet gecompileerd met de --pinguin flag? Dat verklaart al je problemen.
* Dopje doet ook een duit in het zakje.

[ Voor 16% gewijzigd door Ventieldopje op 21-07-2016 18:33 ]

[dakathefox]

True schreef op donderdag 21 juli 2016 @ 14:41:
[...]


Ja dat weet ik ook alleen verbaasde mij dit:


[...]

Een PHP pagina is natuurlijk geen GUI. Net zo min als shell natuurlijk een GUI is.

[dakathefox]

True schreef op donderdag 21 juli 2016 @ 18:27:
[...]
Dat hoop ik ook ten zeerste, alleen de wat vreemde zinsbouw, onduidelijk uitleg en "een browser en een link" vind ik het nogal wat vaag worden.

En bedankt ;-)

De processen de ik heb draaien zijn PHP scripts. Die kan ik via de cron uitvoeren, maar ook via de browser. De cron is wat ik standaard gebruik natuurlijk, maar om de uptime te monitoren check ik ook elke minuut de beschikbaarheid van de webserver. Op het moment dat de webserver niet meer reageert, weet ik dat het aantal processen over de kop is gegaan en dat een reboot noodzakelijk is.

Is het zo duidelijk?

[Ramon]

Maar wat wil je nu van ons? Je zal toch echt zelf op onderzoek moeten gaan om te zien waarom de server niet meer reageert. Wij kunnen hier wel vanalles gaan roepen maar dat wordt snel saai. Als je meer hulp wil dan moet je ook meer delen

[Gomez12]

mind123 schreef op donderdag 21 juli 2016 @ 19:18:
[...]
De processen de ik heb draaien zijn PHP scripts. Die kan ik via de cron uitvoeren, maar ook via de browser. De cron is wat ik standaard gebruik natuurlijk, maar om de uptime te monitoren check ik ook elke minuut de beschikbaarheid van de webserver. Op het moment dat de webserver niet meer reageert, weet ik dat het aantal processen over de kop is gegaan en dat een reboot noodzakelijk is.

Is het zo duidelijk?

Kijk, hiermee zou je dus een fatsoenlijk plan van aanpak kunnen opzetten.

Kijk eerst in je geschiedenis of er een trend valt te ontdekken tussen reboot en webserver die niet meer reageert, is dat na een week? Of na een maand? Of al na een uur? Of wat?

Want dan zou stap 2 bijv kunnen zijn om elk start en stop van een proces te gaan loggen zodat je kan zien wat er draait als dat ding niet meer werkt.

Wat ik namelijk vermoed is dat je scheduling gewoon afhankelijkheden kent waardoor het niet klopt en de boel zich gaat ophopen. Bijv dat script naar die externe API, als dat naar een bestand schrijft en 30 seconden dat bestand bezet houdt terwijl je 10 scripts per minuut ook naar dat bestand proberen te kijken dan gaan die gewoon 30 seconden in de wacht, dan zit je dus al op 50 seconden wachttijd per minuut, nog eens 1x per kwartier processen hebben die naar dezelfde bestanden kijken en die rustig 5 minuten gaan locken, tja dan ga je ergens op de dag krijgen dat er 5 minuten en 50 seconden gewacht wordt terwijl er al weer 5 nieuwe runs gestart zijn.

Wat ook een heel simpele methodiek is is om gewoon per process een lock-bestand neer te zetten bij starten en weg te halen bij stoppen, en het proces gewoon niet uitvoeren als er nog een lock-bestand staat (maar bijv een mailtje sturen in dat geval) dan vererger je de situatie niet zoals je nu wel doet.

Jouw probleem zit hem namelijk (imho) helemaal niet in je hardware of in je aantal processen, maar gewoon puur in je afhankelijkheden en die zitten toch echt alleen in jouw eigen code. Een grotere server kan het wellicht langer laten voortduren, maar is geen definitieve oplossing.

[dakathefox]

Gomez12 schreef op donderdag 21 juli 2016 @ 21:54:
[...]
Wat ik namelijk vermoed is dat je scheduling gewoon afhankelijkheden kent waardoor het niet klopt en de boel zich gaat ophopen. Bijv dat script naar die externe API, als dat naar een bestand schrijft en 30 seconden dat bestand bezet houdt...

Dit + het advies van de lock heb ik al uitgezocht. Ik heb alles uiteindelijk weten te herleiden naar 1 specifieke taak. Die blijft problematisch, maar in geval van nood kan ik die altijd nog op een andere server onderbrengen. Daarmee is de pijn voor nu tijdelijk even weg, maar de vraag blijft nog wel.

Wat is effectief: 100 processen die 10 seconden duren, of 10 processen die 100 seconden duren?

[Voutloos]

No way dat de 1000 seconden die je in deze laatste hypothetische vraag over 10 of 100 processen verdeelt allemaal hetzelfde zijn. Er zit vast een verschil qua benodigde resources, locks nodig, context switches etc. etc.

Je blijft in algemeenheden zoeken, en dat ene proces verplaatsen klinkt eerlijk gezegd ook maar als een lukrake gok.

We hebben weinig info om mee te werken, dus je zal zelf maar meer moeten graven, meten, loggen, profilen.

[ Voor 4% gewijzigd door Voutloos op 21-07-2016 22:06 ]

[DJMaze]

Ventieldopje schreef op donderdag 21 juli 2016 @ 18:32:
Dan nog heb je wel een maximale verwerkingstijd van PHP

Maar niet de overhead van Apache en Nginx

En hier:

mind123 schreef op donderdag 21 juli 2016 @ 19:18:
De processen de ik heb draaien zijn PHP scripts. Die kan ik via de cron uitvoeren, maar ook via de browser. De cron is wat ik standaard gebruik natuurlijk, maar om de uptime te monitoren check ik ook elke minuut de beschikbaarheid van de webserver. Op het moment dat de webserver niet meer reageert, weet ik dat het aantal processen over de kop is gegaan en dat een reboot noodzakelijk is.

Is het zo duidelijk?

Het is nog steeds niet duidelijk of die cron taken puur PHP zijn of een crappy http request omdat de "webserver" (Apache?) niet reageert.

Het blijft gissen zolang TS niet verteld wat de cron commando's zijn....
Daarnaast is het ook prima mogelijk dat Apache/Nginx de server "traag" maken (veel requests) en dan is een reboot van de server totaal overbodig. Gewoon Apache/Nginx herstarten is genoeg.

[ Voor 71% gewijzigd door DJMaze op 21-07-2016 23:36 ]

[Ventieldopje]

In dat geval je server beter configureren.. SSL afhandeling op een load balancer en dat soort dingen

[Cartman!]

Waarom zowel Apache als Nginx en niet enkel Nginx?

[kwaakvaak_v2]

Ventieldopje schreef op vrijdag 22 juli 2016 @ 09:04:
In dat geval je server beter configureren.. SSL afhandeling op een load balancer en dat soort dingen

Ik gok dat dit zomaar zijn kleinste probleem is en meer naar micro-optimalisatie neigt. SSL terminator wordt pas boeiend als je 1000'en hits per minuut moet verwerken, niet per week

Als ik een snelle conclusie mag trekken, File IO. Veel read/write operations die de boel onderuit trekken. Misschien kan de TS/OP eens kijken naar streams in PHP. Is ook een stuk vriendelijker voor het geheugen dan alles in memory lezen.

Maar idd, zoals iedereen hier boven ook al zei, zonder specifieke input is het beetje veel koffiedik in een glazen bol kijken. Processen zeggen niets zonder heel precies te weten wat er in een process gebeurt. Meten is weten in dit geval. Iets als https://blackfire.io/ kan je veel meer vertellen dan dom raad werk op een forum

Cartman! schreef op vrijdag 22 juli 2016 @ 11:37:
Waarom zowel Apache als Nginx en niet enkel Nginx?

Default Plesk setup these days Nginx als proxy voor apache 2.4

[ Voor 10% gewijzigd door kwaakvaak_v2 op 22-07-2016 12:17 ]

[Gomez12]

mind123 schreef op donderdag 21 juli 2016 @ 21:57:
[...]
Wat is effectief: 100 processen die 10 seconden duren, of 10 processen die 100 seconden duren?

Je negeert nu net de belangrijkste variant : 1 proces wat 1000 seconden duurt.

Waarschijnlijk negeer je die omdat dat simpelweg een niet acceptabele tijd is. Echter is het wel de crux voor het antwoord op je vraag. Want als 1000 seconden te lang is, dan zullen de andere keuzes elkaar dus moeten bevechten om resources en wat dan het handigste is is afhankelijk van wat voor soort resources je processen gebruiken.

Heb jij 10 processen die allemaal 100% cpu gebruiken dan werken ze elk maar op 10% van de mogelijke kracht (OS-switching etc even daargelaten). Maar heb jij 1 process wat 100% cpu gebruikt en 1 process wat 100% Disk I/O gebruikt dan kunnen die wel weer perfect naast elkaar.
Oftewel het hangt ervanaf wat jouw processen doen en waar ze elkaar blokkeren.

P.s. Nu heb je 1 script geïsoleerd wat de hoofd-veroorzaker is, maar ik vermoed dat je nu na een langere tijd hetzelfde probleem weer gaat krijgen, want je hebt het nr 1 probleem weggehaald maar dat betekent enkel maar dat nr 2 nu de nieuwe nr 1 is.

P.P.s. sowieso zou ik me af gaan vragen of je niet zo af en toe gewoon een script kan overslaan (door met locks oid te gaan werken) ipv blind alles opstarten tot je hele server vaststaat. Helemaal aangezien je er ook nog een webserver op hebt draaien, 1 scriptkiddie die je webserver op vulnerabilities gaat checken kan anders ervoor zorgen dat er zoveel load gegenereerd wordt dat je scheduling in de soep loopt. En dan gaat het van kwaad tot erger als je maar blind processen blijft starten.

Oftewel Hoe erg is het als er in 1 minuut 9 van de 10 processen niet starten als je schijnbaar een onverwacht probleem hebt (want je timing klopt niet)

[Ed Vertijsment]

Los van het bovenstaande, bedenk je dat een server in principe meerdere taken (nagenoeg) tegelijkertijd kan doen. Het is echter niet altijd mogelijk om tegelijkertijd meerdere processen toegang te geven tot dezelfde data.

Ik heb vaak genoeg gezien dat een traag cron proces (bijvoorbeeld vanwege een externe call) een database locked. Dit resulteert dan in niet reagerende processen die ook toegang tot die tabel willen (de impact hiervan verschilt per database engine).

Als een IO resource (b)locked is kun je er 50 processoren tegenaan gooien maar dat gaat dan geen verschil maken (hoogstens om de block eerder op te heffen door een proces af te ronden).

Om dit soort zaken te debuggen raad ik je het volgende aan:

- Log alles, wanneer doet het probleem zich voor? Welk Ip? Welke pagina(s)?
- Check de status van de database
- Check de workload van de server
- Test met crons uitgeschakeld

Op basis van de problemen die je beschrijft vermoed ik dat het probleem in de database gezocht moet worden. Waarschijnlijk heb je ergens een lock die de andere processen laten wachten. Als het een tekort aan rekenkracht zou zijn zou het minder snel een "brick wall" raken, maar slechts marginaal trager worden.