This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

(OT?) stress test 2tickle fork error;to exhaust heap..


[Informal post. I'm not a developer. Is this a fair test, does it have any value?]

We have a test box (Windows Server 2003 Enterprise Edition), w/10GB RAM (PAE enabled).
Trying to stress the limits of cygwin 1.5.19 or the OS, I ran this test
from a bash session:

  # preliminary step: load private key, so "ssh localhost date" works w/o password
    eval $(ssh-agent); ssh-add ~/.ssh/id_rsa 

  # ******************************************************************** 
  # the stress test:
  #   (able to go to 80 ssh sessions; suggest you try just 15 or so 1st)
  # ******************************************************************** 

    for ((i=1;$i <=15;i += 1))
    do echo $i:
      ssh localhost /bin/sleep 600 >/dev/null 2>&1 &
      sleep 3
    done

    man bash
     # tap "G", to go to end, then quit, repeat this 3 more times

  # -------------------------------------------------------------------- 
  # to kill all ssh sessions and sleeps:
  # -------------------------------------------------------------------- 
   # note that "|" below is a "regexp 'or'":
     pgrep -f 'ssh localhost /bin/sleep 600|/bin/sleep 600' # just a listing
     pkill -SIGKILL -f 'ssh localhost /bin/sleep 600|/bin/sleep 600'

Results:

  If I eliminate the "sleep 3", problems start after 15 or so parallel ssh sessions - 
  some of the new ssh jobs die immediately.  Later if I run "man bash" 4 times
  in a row, in the bash session that ran the "for loop", I get fork errors at least once.

  By adding the "sleep 3", I do not get the fork errors - any idea
  why? I was able to get 80 sessions at once (task manager shown ~300
  processes), "jobs" shows 80 ssh sessions, and "man bash" ran just fine.

  In all cases, after the "man bash" the ssh sessions end up getting STOPPED, ie
  suspended, as shown by "jobs" command in bash - any way to prevent that? ( is that
  probably an OT UNIX question? )

I was able to get 80 ssh sessions, running at once, and was still able
to run "man bash" w/o any fork error. I suspect I could have gone
further. Can't remember if I did the test at the console, but I did have
an RDP session available, thinking that I could at least reboot through
terminal services if ssh became unusable.

How might I run a test to deliberately use up the 48MB heap?  I thought perhaps,
that enough multiple ssh sessions would do so.  

Here's the slightly adjusted heap setting on the server:

  bash-3.00$   ccs=/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet
  bash-3.00$   key="$ccs/Control/Session Manager/SubSystems/Windows"
  bash-3.00$   perl -lne 'print $1 if m{ (Shar.*?) }' "$key"
  SharedSection=1536,3584,768

--
thanks,
Tom


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]