IHS (IBM apache) spawns way too many processes

Hi,

We are seeing an issue where one of our IHS server spawns a huge
number of processes (250+ ) in excess of the MaxClients set on the
server (150).
The number of proceses does not seem to stop and eventually the server
runs out of available memory and crashes out (eventually being a
couple of hours)

Has anyone else seen this behaviour before?

We are running 1.3.28 of IHS server but might be a litlte behing on
bug patches.

we are looking to reduce MaxClients which will make hte server slower
but ought to stop it maxing our , except that currently MaxClients is
being ignored anyway...

Any help apreciated

Re: IHS (IBM apache) spawns way too many processes

On Sep 26, 2:08 pm, jibbajibba wrote:
> Hi,
>
> We are seeing an issue where one of our IHS server spawns a huge
> number of processes (250+ ) in excess of the MaxClients set on the
> server (150).
> The number of proceses does not seem to stop and eventually the server
> runs out of available memory and crashes out (eventually being a
> couple of hours)
>
> Has anyone else seen this behaviour before?
>
> We are running 1.3.28 of IHS server but might be a litlte behing on
> bug patches.
>
> we are looking to reduce MaxClients which will make hte server slower
> but ought to stop it maxing our , except that currently MaxClients is
> being ignored anyway...
>
> Any help apreciated

Okay posting my own answer just so it puts the information in here for
other people.

The problem is a known bug with IBM HTTP Server 1.3.28 and GSKit >
7.0.3.25. One our technicians had instaleld a new IHS instace which
upgrades the GSkit to a later version (7.0.3.27). When we saw this
issue we backed out this change but the GSkit upgrade does not get
removed by default.

Basically, each thread can only process one transaction and then gets
dumped as our version of the Webshpere plugin was old these handing
threads which sit in CLOSE_WAIT state are not reused and instead any
new request generates a new process. Very quicky we have 500 process
and the serivce falls over.

We downgraded the GSkit to 7.0.3.24 and updated the plugin to handle
hung threads more elegantly and this resolved the issue.