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
