[PATCH] Change algorithm for spare server maintanence

[Manoj Kasichainula <ma...@raleigh.ibm.com>]

The hybrid server maintains the number of total child processes based
on a count of idle processes. Right now, a process is counted as idle
when the number of idle threads in that process is greater than a
threshold. That threshold is meant to be 5% of the threads in a
process, and user-settable (it isn't right now, but it's meant to be).

The problem with this is that it's not very deterministic. A process
with 6% idle threads is considered the same as a process with 100%
idle threads. Also, this results in having more parameters to tune,
which is always a good thing to avoid.

This patch changes the algorithm. It counts the total number of idle
threads in the whole server, and the server is managed using this
number. We convert this idle-thread number into two idle-process
numbers: floor(idle_threads/threads_per_child), and ceil(), which are
then compared against MinSpareServers and MaxSpareServers.

Comments? Is this the right algorithm to follow?

If/once we can create and destroy threads on the fly, we can switch to
Max/MinSpareThreads and get rid of the floor() and ceil() stuff.

Manoj

Re: [PATCH] Change algorithm for spare server maintanence

[Dean Gaudet <dg...@arctic.org>]

On Tue, 20 Apr 1999, Manoj Kasichainula wrote:

> On Tue, Apr 20, 1999 at 09:26:37AM -0700, Dean Gaudet wrote:
> > To be honest I'd rather see a fixed number of children with a variable
> > number of threads each.  Each of them maintaining their own (portion of
> > the) scoreboard.
> 
> I'm not so sure. When we've hit MaxThreadsPerChild in every process,
> we should be able to start more processes. At the same time, if we

No we shouldn't.  If I say "do not run more than N concurrent children,
and no more than M conncurent threads in any one child" then the server
better stop there.  Otherwise what's the sense having those directives? 

Also, I want to be able to say "run one process and scale the number of
threads".  I also want to be able to say "run four processes because I
have 4 CPUs in this SMP box, and I'm using user-level threads". 

Other than replacing a child which dies, I don't see why we need to spawn
more children ... 

Dean

> have a lot of processes running with a few threads, it would be nice
> to collapse some of these threads together into fewer processes,
> though it's not that big a deal.
> 
> To implement something like this, I think you need to have pipes from
> the parent to each child. This means that you limit your number of
> child processes to the maximum number of file descriptors, but this
> isn't too big of a deal since each of our children can use the
> maximum number of threads.
> 
> Manoj
> 

Re: [PATCH] Change algorithm for spare server maintanence

[Manoj Kasichainula <ma...@raleigh.ibm.com>]

On Tue, Apr 20, 1999 at 09:26:37AM -0700, Dean Gaudet wrote:
> To be honest I'd rather see a fixed number of children with a variable
> number of threads each.  Each of them maintaining their own (portion of
> the) scoreboard.

I'm not so sure. When we've hit MaxThreadsPerChild in every process,
we should be able to start more processes. At the same time, if we
have a lot of processes running with a few threads, it would be nice
to collapse some of these threads together into fewer processes,
though it's not that big a deal.

To implement something like this, I think you need to have pipes from
the parent to each child. This means that you limit your number of
child processes to the maximum number of file descriptors, but this
isn't too big of a deal since each of our children can use the
maximum number of threads.

Manoj

Re: [PATCH] Change algorithm for spare server maintanence

[Dean Gaudet <dg...@arctic.org>]

To be honest I'd rather see a fixed number of children with a variable
number of threads each.  Each of them maintaining their own (portion of
the) scoreboard.

But what you posted looks fine for now...

Dean

On Mon, 19 Apr 1999, Manoj Kasichainula wrote:

> The hybrid server maintains the number of total child processes based
> on a count of idle processes. Right now, a process is counted as idle
> when the number of idle threads in that process is greater than a
> threshold. That threshold is meant to be 5% of the threads in a
> process, and user-settable (it isn't right now, but it's meant to be).
> 
> The problem with this is that it's not very deterministic. A process
> with 6% idle threads is considered the same as a process with 100%
> idle threads. Also, this results in having more parameters to tune,
> which is always a good thing to avoid.
> 
> This patch changes the algorithm. It counts the total number of idle
> threads in the whole server, and the server is managed using this
> number. We convert this idle-thread number into two idle-process
> numbers: floor(idle_threads/threads_per_child), and ceil(), which are
> then compared against MinSpareServers and MaxSpareServers.
> 
> Comments? Is this the right algorithm to follow?
> 
> If/once we can create and destroy threads on the fly, we can switch to
> Max/MinSpareThreads and get rid of the floor() and ceil() stuff.
> 
> Manoj
>