Sequential forked processing of monitors would be a "Good Thing" (tm),
with the following basis:
1.) Proper care taken not to throttle the throughput OUT of the machine.
2.) Proper care taken not to fork 100 processes.
Given this, there should be a custom variable specified in each conf file
along with the time cycle variable for max amount of child processes
fork'd. However, this would add a bit of overhead to each daemon, checking
to make sure that there was enough memory to fork, etc. Could the noclogd
or another daemon control process forking for all the monitors in general?
Some ideas to kick around....
=-= Nathan
_________________________________________________________________________
Nathan Clemons
Associate Systems Engineer
WinStar iCi
Broadband Services
Great Woods Office Park 800 South Main St. Mansfield, MA 02048
_________________________________________________________________________
nclemons@winstar.com www.winstar.com (v) 800-234-0002 ext.1109
nathan@ici.net www.ici.net (f) 508-261-0430
On Mon, 16 Aug 1999, Michael Douglass wrote:
>
> Part of the problem as I see it is that portmon tends to wait TOO LONG
> for things to timeout when they are down. Another problem is that
> everything is monitored serially; perhaps having portmon fork off a
> couple of helper children who actually do all of the work and just
> take instructions/return results from/to the parent via pipes.
>
> Just thoughts.
>
> On Mon, Aug 16, 1999 at 09:01:12AM -0400, Mike Gibbs said:
> >
> > Portmon seems way to slow for what it is doing. Monitoring 150 servers
> > for 2 ports (smtp and http) it takes 1.5 hours to cycle once. Is this
> > normal, or a misconfiguration on my part? Also, if it is normal, what
> > functions are needed to output the same stuff to nocols databases if I
> > write my own portmon, so I can still use nocol for the gui.
> >
> >
> > Mike Gibbs
>
> --
> Michael Douglass
> Texas Networking, Inc.
>
> Any sufficiently advanced bug is indistinguishable for a feature.
> -- from some indian guy
>
|