Hi, Nice that you are working on increasing the control of environment resources. However I think this is a step back as in normal circumstances you'd wouldn't want an environment to completely stop if they use "too much" CPU as you'd risk the processor being idle instead, wasting CPU cycles. Instead, I think this should be implemented by a nice level setting which should be supported by all kernels. The nice level basically sets the priority of the threads, so if one environment is running with a lower nice level, it will get more CPU time if it currently competing with another environment that has a higher nice level. This is basic CPU time resource management and prevents idle cycles.
http://linux.die.net/man/2/setpriority Also, I have another feature suggestion. The biggest hurdle for me is controlling the RAM actually. One of the problems with using PHP as an apache module is basically that the apache childs suddenly consumes 10-40x more memory after they have handled a PHP request. This wouldn't be a problem is it wasn't for the fact that childs where randomly assigned PHP requests so if you're not closing down childs almost instantly after they have started, you'd end up with a bunch of childs, each allocating a big chunk of memory while just idling. I'd really want to be able to specify that incoming PHP requests should be directed to children that have already handled PHP requests and are now idling. E.g. if the incoming request is a PHP request, it should first check if there are idle children that has not handled a PHP request, and it should only pick another child if no such child is available. Likewise, for all other requests, it should pick alive "other children" first, and idle previous PHP handlers secondary. So you'd have a "A-B Priority" where "if you get an A request, 1: use idle A children 2: use idle B children, 3: start a new A child, **if you get a B request: 1. use idle B children 2. use A children which are "dirtied" to become B children 3. start a new B child". This option could be controlled like this: AlphaBetaRouting On BetaHandlers application/x-httpd-php application/python These options would be set on server level and processor level. Beta handlers is basically a list of request "types" or "handlers" that is used to identify "beta requests" that are first-hand assigned to "beta dirtied children". An extended feature of this would also set a limit on how many beta handlers a server/processor can have. An overloaded search.php script would then be unable to block access to other static files. There could also be request time limits on beta requests. For example, I don't want PHP/Python/etc scripts of my customers to run more than 30 seconds. But downloading big files is no problem, a A child can be locked up with that for hours as they don't consume much resources by being alive anyway. Thanks a bunch! Hannes On 19 January 2011 22:47, Marcelo Coelho <[email protected]> wrote: > Hello! > > Peruser patch (v15) - FreeBSD > > Patch from RC2: > http://opensource.mco2.net/download/apache/peruser/peruser-rc2-to-rc3-v15-freebsd.patch > > Full patch from vanilla Apache 2.2.17: > http://opensource.mco2.net/download/apache/peruser/peruser-rc3-full-v15-freebsd.patch > > Important: this patch works only with FreeBSD because cpu_usage.c uses > FreeBSD KVM Library to control CPU use. This patch will not work on Linux (I > guess). > > There is a new parameter MaxCPUUsage, to control CPU use by each processor. > It works like Linux cpulimit utility: if processor CPU use is greater than > MaxCPUUsage, sends a SIGSTOP, if lower, sends a SIGCONT. > > MaxCPUUsage defaults 0, wich means unlimited. > > Changes (from RC2): > > * (v15) Feature: /server-status with more details (CPU usage of each > processor and each ServerEnvironment). > * (v15) Feature: New configuration MaxCPUUsage > * (v15) Bug fix: some segfaults fixed. > * (v14) Bug fix: multiplexer segfault when passing big requests to processors > (URI with ~8192 bytes and big Referer header) > * (v14) Performance: faster idle server maintenance > * (v14) Clean-up: removed .orig files > * (v13) Code more "APR-ized" > * (v13) Bug fix: apachectl graceful works, even under high load. > * (v12) Not released to public > * (v11) Not released to public > * (v10) Bug fixed: fixed some segfaults > * (v10) Bug fixed: work around to a flaw in apr-util (as PR 43857) > * (v9) Not released to public > * (v8) Bug fixed: apachectl graceful now is more stable, like RC2 version > * (v8) Bug fixed: fixed some segfaults (thank you Dave Steinberg for sending > your core dumps) > * (v8) Bug fixed: server dies with infinite loop script, reported by Taavi > Sannik > * (v8) Bug fixed: "long lost child" error, reported by Taavi Sannik > * (v8) Performance: update_all_counters() rewritten without malloc() and > free() > * (v7) Bug fixed: multiplexers now can clone a processor child if all workers > are busy. > * (v6) Bug fixed: apachectl graceful now working properly, without "long lost > child" errors > * (v5) Not released to public > * (v4) Code cleanup > * (v4) Performance: childs are started in ~25ms, 40 times faster than in RC2 > (~1000ms) > * (v4) Bug fixed: now checking if total_processors is 1 (first access) to > start StartProcessors > * (v3) Performance: new child type (CHILD_TYPE_RESERVED) to avoid collision > (2 childs trying to get the same free slot) > * (v3) Bug fixed: fixed a bug in RC2, wait_timeout was always 0, never > sleeping to wait for new workers. > * (v2) Performance: StartProcessors, new configuration directive to control > the number of child processors per vhost at startup > * (v2) Performance: childs are started in ~50ms, 20 times faster than in RC2 > (~1000ms) > * (v1) Performance: faster to lookup for free slots (this is important on > busy servers, with many virtual hosts) > * (v1) Performance: faster to count processors, one single loop counts all > processors > * (v1) Bug fixed: bug when MinSpareProcessors is set to 0 (now all workers > processes are killed when idle_timeout is reached) > * (v1) Bug fixed: Free-up slots when a WORKER or PROCESSOR unexpectedly dies > > > Regards, > > -- > Marcelo Coelho > marcelo at mco2.com.br > > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser > _______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
