Zoals de titel al aangeeft, wat kan er mis zijn wanneer 1 httpd process 100% cpu verbruikt.
Loop ergens in een script zat ik zelf aan te denken, maar dan is nog de vraag welk script.
Likes: 0
16/07/09 15:56
Zoals de titel al aangeeft, wat kan er mis zijn wanneer 1 httpd process 100% cpu verbruikt.
Loop ergens in een script zat ik zelf aan te denken, maar dan is nog de vraag welk script.
16/07/09 15:57
strace doen op de PID van het loopend proces?
16/07/09 16:21
Waarom er nog mensen zijn die PHP via apxs draaien is mij echt een raadsel. Google eens op suPHP of fcgi, daarmee maak je o.a. het tracken van draaiende scripts en heavy-load users een stuk eenvoudiger!
(om nog maar te zwijgen van een beter beveiligingsmodel en oplossing voor diverse rechten-gerelateerde problemen)
16/07/09 16:27
Dit gaat er ook komen alleen ik kan niet zomaar zoiets installeren zonder het van te voren te testen.
16/07/09 16:44
dat kun je nooit, iedere bak is toch net weer iets....Oorspronkelijk geplaatst door Boyke
16/07/09 16:58
Klopt, maar vooraf testen kan nooit kwaad.
Iemand nog meer suggesties om het huidige "probleem" te achterhalen?
16/07/09 16:59
Gelukkig hebben wij daar nu 6 jaar ervaring mee (eerst suPHP en nu fcgi) en er zijn slechts een paar 'nadelen', die net zo makkelijk zijn op te lossen;
Voordelen:
- Scripts worden onder eigen user uitgevoerd (dus bestanden die door een script worden aangemaakt zijn gewoon via FTP te verwijderen, zonder poespas)
- User X kan niets met de scripts van user Y (met een beetje tweaken kunnen ze e.e.a. niet eens zien)
- Monitoren van serverload laat ook zien welke PHP processen bij welke user horen, dus de intensiteit waarmee user X de server belast is direct duidelijk
- PHP4 naast PHP5 draaien
- Eigen php.ini per virtualhost
Nadelen:
- Users kunnen geen php flags doorspelen via .htaccess (maar daar is gelukkig een eigen php.ini voor)
- ...dat was het eigenlijk
Vooroordelen
- suPHP/fcgi zijn trager dan de apache module: bullshit.
M.a.w., zoek eens een goede tutorial op hoe je e.e.a. installeert en je hoeft nooit meer zulke vragen te stellen als je zojuist deed
16/07/09 17:01
I.d.d., vele voordelen.
Welk OS/CP gebruik je?
16/07/09 17:04
Wie, ik?
16/07/09 17:05
Nee joh, zo te lezen weet jij wel wat je doet, de TS dus
16/07/09 17:47
Dit stond inderdaad al enige tijd op mijn lijstje.
De term suPHP klinkt mij ook niet onbekend in de oren.
CentOs / Fedora gebruik ik.
16/07/09 20:07
Beide?
16/07/09 20:29
mod_ruid anyone?
Via APXS draaien heeft zo zijn voordelen, bij een grote klanten groep is het ontbreken van flags via .htaccess echt een GROOT nadeel.
Denk ook even aan overstappen als je allang mod_php draait, dan betekend het dat je ineens bij AL je klanten de .htaccess files moet aanpassen, want anders krijgen zij 500 errors van je Apache terug.
Daarnaast is met de juiste logging in Apache prima te zien welke user zo veel CPU tijd vreet.
Ceph, CloudStack en ZFS consultancy: 42on B.V.
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
16/07/09 20:41
En ondertussen zit TS zijn load tot aan het dak?
Probleem is lijkt me niet WAT hij zou moeten draaien, maar HOE hij zijn probleem oplost. Dat is de vraag.
Ts, mogelijk dat er nog eea in de logs staat wat er aan de hand is?
Kill anders apache even en start het opnieuw op.
16/07/09 21:04
Als een klant zijn site naar jouw infra verhuist dan neem ik aan dat hij wel even zal controleren of zijn zaakje werkt. Daarnaast is het een kleine moeite om klanten automatisch een eigen php.ini toe te wijzen (is allemaal standaard template werk).
Een bestaande infra overzetten kan wat problemen opleveren, maargoed daarom kondig je zaken aan. Problemen doen zich namelijk niet alleen voor door flags in .htaccess, maar met name door alle nozems die hun bestanden en mappen 777 chmod'en. (exploits anyone?
mod_ruid ziet er overigens ook nuttig uit en zou een alternatief kunnen zijn, ware het niet dat je dan nog steeds geen verschillende PHP versies naast elkaar kunt draaien.
Quote