WONDERFUL detailed info Joel. Thank you very much for sending it all!

The DB error stuff sounds like it may be what's killing us too.

We have 2 SQL errors yet to be fixed in our app. They're invisible to the user
(and do no harm) so we haven't gotten around to fixing them.  I"ll fix 'em this
weekend and see what happens.

NEW ONE:
Can anyone tell me if this error I see in the Service Mgr log (
smDefaultPartition.log) is complaining about no free CP or DS workers?

==============
exception CNdNoFreeWorkersException{string reason="no free workers";}
     at
netdyn.cosi.service.loadBalancing.CNdLoadBalancingManager.allocateWorker(Compiled

Code)
exception CNdNoFreeWorkersException{string reason="no free workers";}
     at netdyn.cosi.service.CNdServiceImpl.allocateWorker(Compiled Code)
     at
netdyn.cosi.service.loadBalancing.CNdLoadBalancingManager.allocateWorker(Compiled

Code)
     at netdyn.cosi.stubs._tie_INdService.allocateWorker(Compiled Code)
     at netdyn.cosi.service.CNdServiceImpl.allocateWorker(Compiled Code)
     at netdyn.cosi.stubs._INdServiceImplBase._execute(Compiled Code)
     at netdyn.cosi.stubs._tie_INdService.allocateWorker(Compiled Code)
     at netdyn.cosi.stubs._INdServiceImplBase._execute(Compiled Code)
     at netdyn.cosi.stubs._INdServiceImplBase._execute(Compiled Code)
     at com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(Compiled Code)
     at netdyn.cosi.stubs._INdServiceImplBase._execute(Compiled Code)
     at com.visigenic.vbroker.orb.GiopProtocolAdapter.doRequest(Compiled Code)
     at com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(Compiled Code)
     at com.visigenic.vbroker.orb.GiopProtocolAdapter.dispatchMessage(Compiled
Code)
     at com.visigenic.vbroker.orb.GiopProtocolAdapter.doRequest(Compiled Code)
     at com.visigenic.vbroker.orb.ThreadPoolDispatcher.run(Compiled Code)
     at com.visigenic.vbroker.orb.GiopProtocolAdapter.dispatchMessage(Compiled
Code)
     at com.visigenic.vbroker.orb.WorkerThread.run(Compiled Code)
     at com.visigenic.vbroker.orb.ThreadPoolDispatcher.run(Compiled Code)
     at com.visigenic.vbroker
==================
Thanks,
Janet



                                                                  
 (Embedded                                                        
 image moved   "Joel Spryer" <[EMAIL PROTECTED]>           
 to file:      11/19/99 09:22 AM                                  
 pic28429.pcx)                                                    
                                                                  



Please respond to [EMAIL PROTECTED]

To:   Janet Traub/IS/SSC/THD
cc:   [EMAIL PROTECTED]
Subject:  Re: [ND] Threading problem with # of CP workers




Janet,

We are also experiencing the "no free worker" problems.  I've also noticed that
it
happens alot when there are errors in the dbms service relating to "invalid SQL
results" or "cannot open sequential cursor".  I am not sure how to capture these
errors so that it will not cause problems with the dbms service.

After a certain number of dbms errors, I'll notice that the reservation
revocations
for the dbms begin to climb.  It seems that after they've reached around 200,
the
various services begin to crash and burn.  Then, the only service we see is the
ndProcessLauncher.

At this point we have to perform an ndappsrv stop and start.  Then life is back
to
being "hunky dorey".

So every night we are "bouncing" the ND app services.  Performing a ndappsrv
stop
and start.  And hoping that during the day, we won't get too many dbms errors.

We've got an HP-UX 10.x with 856M memory running ND app server 4.12 and Netscape
Enterprise 3.5.1.  Our database is on a separate NT server running Oracle 7.3.x.
At
peak times there are no more than 25 concurrent hits on the Web server or on
against
the ND app server.

At this stage, we trying to fine tune our configurations.
    We upped the maxusers kernel setting from 100 to 400.

Our ND configuration is ...
    PE Service is running out of process with "java -mx150m -ss1M -noasyncgc"

    CP Service:
     # of workers = 4
        workers are run out of process with "java -mx100m -ss1M -noasyncgc"
     # of clients = 10

    DBMS Service:
     # of workers = 5
    Max db conns per process = 10
    Max db conns per db = 10
    Max rec to retreive = 9999
    Number of worker processes = 5
    Max # of Clients per Worker = 1

I've been working with ND Tech support to get the best configuration and resolve
these problems.  They did mention that there is a bug relating to the db workers
failing (#370192).  They have not given me any solutions or patches.

I also had considerable problems when I had the # of CP clientworkers (40=4x10)
more
than dbms workerprocesses (25=5x5 - older configuration).  It doesnt seem to
crash
as bad with there being more dbms workers.  I was hoping to limit the number of
connections to the database, but that would require drastically reducing the CP
workers.

I know there are probably some more settings that need to be tuned.  Our Unix
gurus
are getting GLANCE for the HP-UX so they can monitor the box and see what else
may
be failing or in need of extra resourcing.

I'm not sure if this helps any, but I know I benefit when I get an idea of what
others are running and what they are doing to fix it.

- Joel S.

[EMAIL PROTECTED] wrote:

> Hi folks,
>
> As I mentioned last week...our HP 10.x server gives us "no free worker"
messages
> when we run our ND4  CP service with this config:
>      # of workers = 2
>      # of clients = 4
>
> and then the server hangs, requiring a reboot.
>
> A co-worker suggests we try changing our config to:
>      # of workers = 8
>      # of clients = 1
>
> for the reason given below.
>
> May I get some opinions? Think this is worth a shot? Off hand, do you think
his
> suggested config requires significant more memory resources that our existing
> config?
>
> Thanks,
> Janet
>
> "If this fixes the problem, that's a good indication that we have a threading
> problem. I don't claim to know a whole lot about HPUX, but I have heard that
it
> doesn't handle multi-threading very well. What could be happening is that when
a
> single worker-client (thread) crashes, it brings down the entire process (the
> worker). This is what Lidia at ND is saying in her post last week. If any one
> thread hangs in each of the two processes you are running, both processes will
> die, effectively killing NetDynamics entirely."
>
> _________________________________________________________________________
>
> For help in using, subscribing, and unsubscribing to the discussion
> forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
>
> For dire need help, email: [EMAIL PROTECTED]

--
------------------------------------------------------
Joel Spryer                     Sr. Systems Developer
PPD, Inc.                       Information Technology
Research Triangle Park          Corporate Systems
3900 Paramount Parkway          Phone:  (919) 462-4047
Morrisville, NC 27560           Fax:    (919) 379-2617
------------------------------------------------------


_________________________________________________________________________

For help in using, subscribing, and unsubscribing to the discussion
forums, please go to: http://www.netdynamics.com/support/visitdevfor.html

For dire need help, email: [EMAIL PROTECTED]

pic28429.pcx

Reply via email to