On Tue, 8 Jul 2003, Terry Lambert wrote:
> Dan Nelson wrote:
> > In the last episode (Jul 08), Andy Farkas said:
> > > If setiathome is making lots of syscalls, then running the 3 instanses
> > > should already show a problem, no?
> >
> > Not if it's ssh that's holding Giant for longer than it should. The
> > setiathome processes may be calling some really fast syscall 500 times
> > a second which doesn't cause a problem until ssh comes along and calls
> > some other syscall that takes .1 ms to return but also locks Giant long
> > enough to cause the other processes to all back up behind it.
>
> Specifically, if it's sleeping with Giant held because the
> Send-Q is full (use netstat to check) it could block things
> for a long time, waiting for the queue to drain.
scp was retrieving a file, not sending, and it was bandwidth limited.
Any other ideas? Why would 3 (niced) cpu intensive processes suddenly get
reduced cpu time (on a 4 cpu system) when a 4th non-resource intensive
process gets started?
Also, from something that BDE said once, this command will produce
unexpected results when run for more than a few hours:
for i in `jot -n -s ' ' 20 0 19 1`
do
nice -$i sh -c "while :; do echo -n;done" &
done
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
