Greg Ames <[EMAIL PROTECTED]> writes:
> Jeff Trawick wrote:
> >
> > Even if child process creation is limited by ap_daemons_limit, we
> > still write trace messages saying we're about to spawn x children,
> > where x > ap_daemons_limit.
> >
> > This patch doesn't let idle_spawn_rate get over ap_daemons_limit / 2.
> > It writes the log message at that threshold as well.
> >
> > @@ -1030,7 +1032,7 @@
> > }
> > else {
> >
> > - if (idle_spawn_rate >= 8) {
> > + if (idle_spawn_rate >= ap_daemons_limit / 2) {
> > ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_INFO, 0,
>ap_server_conf,
> > "server seems busy, (you may need "
> > "to increase StartServers, ThreadsPerChild "
>
> ...but then we can't see it ramp up. Do we need to? dunno. I'd prefer
> to see it ramp up until we're happy with how it works.
>
> I realize we don't want to put out a log msg with wrong info. Looks
> like "free_length" is what we should be using in this msg, rather than
> idle_spawn_rate.
yessir, free_length looks like the field to trace, and we should do so
when this condition occurs
if (free_length >= 8) {
}
rather than when this one occurs
if (idle_spawn_rate >= 8) {
}
(good news: can't recreate any threaded.c weirdness on AIX or Solaris,
though certainly I'm not running close to user/system resource limits
on those boxes, unlike with the Linux box where I have troubles when I
pound threaded.c)
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
