Conference clt::cma

1490.0. "pthread_create: Not enough space" by GALVIA::GDRUDY () Thu Feb 20 1997 12:51

    I have a customer who has parallelized an application using Kap. The
    application runs successfully with PARRALLEL set to 1 but when set
    to 2 receives the message: pthread_create: Not enough space.
    
    Note 1189 discusses the same message.
    
    The system is an 8400 with 2 GB ram, Digital UNIX V4.0b. I have
    successfully run a parallelized version on our 8400. I have examined
    the customers vm & proc configuration parameters and they are as high
    or higher than our system. Their swap space is 4GB.
    
    The vm parameters are:
    
    ubc-minpercent = 10
    ubc-maxpercent = 80
    ubc-borrowpercent = 20
    ubc-maxdirtywrites = 5
    ubc-nfsloopback = 0
    vm-max-wrpgio-kluster = 32768
    vm-max-rdpgio-kluster = 16384
    vm-cowfaults = 4
    vm-mapentries = 400
    vm-maxvas = 2147483647
    vm-maxwire = 16777216
    vm-heappercent = 7
    vm-vpagemax = 130912
    vm-segmentation = 1
    vm-ubcpagesteal = 24
    vm-ubcdirtypercent = 10
    vm-ubcseqstartpercent = 50
    vm-ubcseqpercent = 10
    vm-csubmapsize = 1048576
    vm-ubcbuffers = 256
    vm-syncswapbuffers = 128
    vm-asyncswapbuffers = 4
    vm-clustermap = 1048576
    vm-clustersize = 65536
    vm-zone_size = 0
    vm-kentry_zone_size = 16777216
    vm-syswiredpercent = 80
    vm-inswappedmin = 1
    vm-page-free-target = 128
    vm-page-free-min = 20
    vm-page-free-reserved = 10
    vm-page-free-optimal = 74
    vm-page-prewrite-target = 256
    dump-user-pte-pages = 0
    kernel-stack-guard-pages = 1
    vm-min-kernel-address = 18446744071562067968
    contig-malloc-percent = 20
    vm-aggressive-swap = 0
    new-wire-method = 1
    vm-segment-cache-max = 50
    vm-page-lock-count = 64
    gh-chunks = 0
    gh-min-seg-size = 8388608
    gh-fail-if-no-mem = 1
    
    
    The proc parameters:
    
    max-proc-per-user = 128
    max-threads-per-user = 512
    per-proc-stack-size = 2147483648
    max-per-proc-stack-size = 2147483648
    per-proc-data-size = 2147483648
    max-per-proc-data-size = 2147483648
    max-per-proc-address-space = 2147483648
    per-proc-address-space = 2147483648
    autonice = 0
    autonice-time = 600
    autonice-penalty = 4
    open-max-soft = 4096
    open-max-hard = 4096
    ncallout_alloc_size = 8192
    round-robin-switch-rate = 0
    round_robin_switch_rate = 0
    sched-min-idle = 0
    sched_min_idle = 0
    give-boost = 1
    give_boost = 1
    maxusers = 128
    task-max = 2048
    thread-max = 4096
    num-wait-queues = 256
    
    
    What else should I be looking for? Any help would be much appreciated.
    
    Gerry.

Of course the real question is "how much are they USING already?" not "how
much are they ALLOWED to use?" If you've got a 8 gallon bucket with 4 gallons
in it, and they've got a 16 gallon bucket with 15 gallons in it, an extra 2
gallons will fit fine in your bucket, but not in theirs.

Their configuration parameters really don't help much without some context in
which to judge them.

	/dave

.0> I have successfully run a parallelized version on our 8400.

Of the same application?  If so, assuming your other statements are true, you
need an exorcist not a threads expert.

Anyway, were I you, I'd consider doing things like bumping vm-mapentries
and/or vm-vpagemax.  Also, you might want to check the other "limits" (i.e.,
"ulimit -a").


				Webb

    Apologies, I was rushing too much entering the note yesterday!
    
    Re .1, There system is idle apart from the benchmark application.
    Re .2 Yes I have run the same application, same data set, on our,
    similarly configured, 8400.
    
    Yes I have unlimited datasize, stacksize etc. but no luck.
    
    Thanks for your help.
    
    Gerry.
    
     

.0> I have examined the customers vm & proc configuration parameters and they
.0> are as high or higher than our system.

.3> I have run the same application, same data set, on our, similarly
.3> configured, 8400.

So, just to reiterate, you are running the same application over the same
data set on a machine with "less space", and it's not running out of space? 
I'll go back with my previous advice:  get an exorcist.

		(Sorry, you're beyond my help...)


					Webb

    An exorcist was not called for.
    
    I failed to mention that our similarily configured 8400, on which the
    code worked, was running Digital UNIX V3.2c (customer using V4.0a).
    
    When I doubled the value of vm-vpagemax to 256k the code ran fine.

*Grin*  This is apparently a new meaning for the phrase "similarily
configured" with which I was not previously familiar...  (For future
reference, "configuation" to us software folks includes hardware, firmware,
system parameters, and software version...  :-)


				Webb