On Mon, 26 Feb 2001 sudog@sudog.com wrote:

> > 	If it chokes can you pull the network cable and get control of
> > 	the machine back, or has it really gone out to lunch?
>
> Nah, when it gets so bad I can't even type at the console I *have*
> seen it pull itself out of it, but only after about four or five hours
> of churning. This was in my own testbed machinery which I use to try
> (and usually fail) to simulate the real environment.
>
	Is it possible to leave a vmstat 5 running while this happens
	to see what is happening?

> > > If #3 (and corresponding perl cgi children) exceeds #2, apache stalls
> > > and is no longer capable of handling cgi. It must be SIGHUP'd to be
> > > corrected.
> > >
> > 	Hmm - have you ha a chance to try to debug what apache is doing
> > 	in this case?
> >
> > 	It would be nice if apache could be told to 'tune down' the
> > 	max processes when hitting a fork failed condition (presumably
> > 	to another 'MinMaxProcesses' limit).
>
> True enough, that sort of behaviour would be very nice. However it's
> looking like Apache rather than tuning down its forking, stops it
> completely. I think it would be pretty simpleto fix; however I haven't
> thus far been successful in simulating the failures in a non-live
> environment. :) I've tracked down the error message itself in Apache
> that it logs into its error log; just the "Resource temporarily
> unavailable". I think dealing with the problems at this juncture would
> be a good idea and something probably worthwhile pursuing (for me).
>
> Either that or I'm just setting up the environment incorrectly and I'm
> a goon. :)
>
	Even if there is an environment tuning option it really should
	work acceptably in the default situation.

> > > It's a juggling act once the kernel is tuned to be capable of dealing
> > > with the huge limits and doesn't panic any more under the loads.
> > >
> > 	Were the panics purely down to tuning the kernel params? Are
> > 	there PRs open on them?
>
> I must apologize, I couldn't find any open PRs but I figured you guys
> had enough work to do without worrying about something as seemingly
> trivial as this--all I had to do was increase MKMEMPAGES and
> MAXUSERs..  and NMBCLUSTERS, etc to reasonable limits within the
> currently available memory and the problems haven't resurfaced.
>
	If you can provoke a panic then you should really check for an
	open PR, and submit one if not. Its useful for anyone working
	in that area.

> > 	NetBSD -current supports a unified buffer cache, which will
> > 	hopefully eliminate the need to tune this at boottime, though
> > 	I'd imagine it will have some parameters that can be tweaked.
>
> Ah, my personal holy grail. :) A system that tunes itself. Scratch
> that. A NetBSD kernel that tunes itself. :)
>
	We're getting there :) NMBCLUSTERS sets an upper limit for
	mbuf usage, and the system tunes within that. Still a long
	way to go.

> > > This is so complicated, I was hoping another user here could offer
> > > some common server configurations based on available RAM and disk type
> > > (IDE vs SCSI) that they've been able to work with and not have to
> > > worry about things getting out of control.
> >
> > 	Are you using mod_perl or fastcgi on the server? Switching
> > 	a heavy perl/postgresql cgi client to fastcgi increased its
> > 	apachebench top rate from 1.8 hits per second to over 80.
> >
> > 	It would be really nice at the end to have a doc to put up on
> > 	www.netbsd.org - would you be willing to put one together? :)
>
> I'd be honoured to help throw something together--really. :) If I do
> get something written who should I be submitting a draft to?
>
	I'd suggest mailing a link to tech-kern to solicit comments,
	then www@netbsd.org (or me :)

> The modperl/modcgi is an excellent idea. I think I'm going to compile
> those in as my next step. Totally forgot about them in my focus on
> the rest of the system. :)

	30x to 40x speedup on a system I have here was certainly not
	to be sneezed at...

		David/absolute		-- www.netbsd.org: No hype required --