[Date Prev]   [Date Next] [Thread Prev]   [Thread Next] [Date Index]   [Thread Index]


     Re: portmon too slow

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