Well, I have tested with PHP_FCGI_CHILDREN=20 and get the same result: 24348 www-data 20 0 291m 18m 1924 R 397 0.5 8:31.68 cherokee- worker
and about memory maybe a memory leak in php but the sum of all 20 php- cgi proccess some times are near 1G! although less than 1.5G with mod_php. Ryan, you're right about clean-up scripts, It's a architectural flaws in openx, authors say that in next version this will be solve... I hope. There is an option in openx that automatically do maintenance task during all code invocation at cost of degrade performance. I tried this too but in a short time get the same effect with cherokee, full cpu usage and this time never return to a normal state and stay always in full cpu usage. So, there is a problem with openx + mysql with myisam and this affect php-cgi responses when tables are locked and cherokee get a lot of petitions... (from server info: Number 245, Active: 245, Reusable: 231) and this result in cherokee-worker eating all cpu. Next, I will try cherokee 0.99 and some tricks in openx maintenance script. I forget... with PHP_FCGI_CHILDREN = 0 php-cgi never start :) El 26/02/2009, a las 13:56, Ryan McIntosh escribió: > Hi Antonio > > RAM is a lot cheaper than CPU on a typical server. I think letting > children sleep rather than killing them works better for most > environments. That said, it would be nice to be able to grow/shrink a > pool of children on demand. Since PHP is not threadsafe, that would > have to be a pre-forking model which could add significant processing > overhead for other users. It would best be done in a separate handler > (uCherokee might benefit from this). > > You were saying mod_php with apache2 used 1.5GB of RAM in this > environment. Cherokee will still use less. My suggestion would be to > look into refactoring some of your database cleanup script into > triggers. This could add request time (possibly, depending on how > they're written) but reduce cleanup time and the associated table lock > time. Perhaps have a look at MySQL slow queries logs to see if > adding/deleting an index or two might help get the cleanup done > faster. > > I'm going to say something harsh and judgemental that isn't aimed at > you personally - but is a generalization. Database cleanup scripts > are an unfortunate near-necessity in some cases, but usually there are > architectural flaws in the underlying application that can be fixed - > removing the need for cleanup scripts altogether. > > One other interim fix if this doesn't work... How long does your > database cleanup script take to run immediately after it has just run? > Could increasing the run frequency of your cleanup script improve > HTTP responsiveness? > > Ryan > > On Thu, Feb 26, 2009 at 5:29 AM, Antonio <[email protected]> wrote: >> Ok, I will set to 20 and try. I don't remenber where I read that 5 >> (default) was enought. >> >> This is the first time I work with fcgi, I have read about it and >> as I >> can see you always have to set a number of childrens, there isn't an >> option or env var to set min or max threads, this would be a best >> option, so that when you are in low load don't waste memory and >> resources. What about PHP_FCGI_CHILDREN = 0 ? this will let php >> manage >> automatic numbers of threads ? >> >> _______________________________________________ >> Cherokee mailing list >> [email protected] >> http://lists.octality.com/listinfo/cherokee >> _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
