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 -- :{ andyf_at_speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/Received on Tue Jul 08 2003 - 03:22:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:14 UTC