On Fri, Jun 07, 2002 at 08:53:31AM -0700, David K. Z. Harris wrote:
> (Just remember the math in your configuration file (cons.h) before
> you do the build...we're using maxgrp=96, but just make sure that
> you can spawn enough processes to cover all of the ports that you
> want to connect to, and make sure your host has enough RAM for
> all of the processes.)
if you're using pre-7.2.X code, this is true. hopefully everyone's
upgraded to 7.2.2, which ignores the concept of maxgrp and just forks
processes while it can. if you have more processes than you care for,
you can have each process manage more consoles by using the -m flag
(default is 16).
On Fri, Jun 07, 2002 at 12:02:29PM -0400, Greg A. Woods wrote:
> That said, as you can see above there's still a very serious memory
> leak somewhere, and that'll drastically affect scalability in any
> production system.... The second conserver process is allocating an
> additional 1.2KB or so with every client connection (I have a cron job
> that makes console client connections to collect data from my three UPS
> units once every minute).
hmmm...i just did a test with 7.2.2 (and i don't know why it would be
different with 7.2.1) by having conserver manage five consoles. i then
did:
i=1; while true; do (echo "echo $1"; sleep 1) | \
~/./conserver/playpen/conserver-7.2.2/console/console bash; \
i=$((i + 1)); done
it's currently spewing:
underdog (root) 288:# [Enter `^Ec?' for help]
echo 287
287
underdog (root) 289:#
and still going. the memory size hasn't grown at all (using both pmap
and ps to check sizes - solaris here). i also have a redhat 7.3 system
running the same test - just started it up. it's up to 109 connections
and there hasn't been a change in memory usage, according to ps.
well, we're up to 983 on the solaris test - still no change in memory
usage. i don't know if it's a netbsd library leak, or maybe the
solaris and linux libraries are more forgiving about something, but i
can't reproduce the problem. if you or anyone can pin things down, i'd
love to hear about it. at 307 and 1130 now - still no change.
if, for some reason, the clients aren't getting disconnected, you'd
have a constant memory increase. but, you should either have a whole
lot of console binaries running, or if you do a 'console -w', you'd see
a list of clients on the console. i kinda doubt that's what's going
on, but i wanted to mention it.
Bryan
> (Just remember the math in your configuration file (cons.h) before
> you do the build...we're using maxgrp=96, but just make sure that
> you can spawn enough processes to cover all of the ports that you
> want to connect to, and make sure your host has enough RAM for
> all of the processes.)
if you're using pre-7.2.X code, this is true. hopefully everyone's
upgraded to 7.2.2, which ignores the concept of maxgrp and just forks
processes while it can. if you have more processes than you care for,
you can have each process manage more consoles by using the -m flag
(default is 16).
On Fri, Jun 07, 2002 at 12:02:29PM -0400, Greg A. Woods wrote:
> That said, as you can see above there's still a very serious memory
> leak somewhere, and that'll drastically affect scalability in any
> production system.... The second conserver process is allocating an
> additional 1.2KB or so with every client connection (I have a cron job
> that makes console client connections to collect data from my three UPS
> units once every minute).
hmmm...i just did a test with 7.2.2 (and i don't know why it would be
different with 7.2.1) by having conserver manage five consoles. i then
did:
i=1; while true; do (echo "echo $1"; sleep 1) | \
~/./conserver/playpen/conserver-7.2.2/console/console bash; \
i=$((i + 1)); done
it's currently spewing:
underdog (root) 288:# [Enter `^Ec?' for help]
echo 287
287
underdog (root) 289:#
and still going. the memory size hasn't grown at all (using both pmap
and ps to check sizes - solaris here). i also have a redhat 7.3 system
running the same test - just started it up. it's up to 109 connections
and there hasn't been a change in memory usage, according to ps.
well, we're up to 983 on the solaris test - still no change in memory
usage. i don't know if it's a netbsd library leak, or maybe the
solaris and linux libraries are more forgiving about something, but i
can't reproduce the problem. if you or anyone can pin things down, i'd
love to hear about it. at 307 and 1130 now - still no change.
if, for some reason, the clients aren't getting disconnected, you'd
have a constant memory increase. but, you should either have a whole
lot of console binaries running, or if you do a 'console -w', you'd see
a list of clients on the console. i kinda doubt that's what's going
on, but i wanted to mention it.
Bryan