Call Object Kernel autostart

gregglarkin

gregglarkin

Legendary Poster
One of the settings in the Call Object Kernel is the number of processes to autostart. The Oracle default is zero. What value do you have yours set to?

[JDENET_KERNEL_DEF6]
krnlName=CALL OBJECT KERNEL
dispatchDLLName=XMLCallObj.dll
dispatchDLLFunction=_XMLCallObjectDispatch@28
maxNumberOfProcesses=100
numberOfAutoStartProcesses=0 singleThreadedMode=N
ThreadPoolSize=50
ThreadPoolSizeIncrement=10
 
we have numberOfAutoStartProcesses=0
BTW, we are currently restarting E1 enterprise services every night as we had issues with kernel recycling locking up users at 8.98.2.3. When we go live on 8.98.4.1 I hope to reintroduce kernel recycling.
 
I usually start up about half the max number of call object kernels. The only thing it really does is allow the users to either log in faster or get working quicker the first time they call an app, depending how you have your JAS server configured, after you restart services so they don't have to initilize the kernel.
 
[ QUOTE ]
One of the settings in the Call Object Kernel is the number of processes to autostart. The Oracle default is zero. What value do you have yours set to?

[JDENET_KERNEL_DEF6]
krnlName=CALL OBJECT KERNEL
dispatchDLLName=XMLCallObj.dll
dispatchDLLFunction=_XMLCallObjectDispatch@28
maxNumberOfProcesses=100
numberOfAutoStartProcesses=0 singleThreadedMode=N
ThreadPoolSize=50
ThreadPoolSizeIncrement=10

[/ QUOTE ]

How often do you anticipate restarting services?

Basically with AutoStart you are a trading service start time increase for the delay a user will experience while waiting for the kernel to start the first time a new kernel is needed.

I'd say if you have a ton of Call Object kernels and restart your services nightly (Why? I dunno) and AutoStart adds too much time to the restart (doubtful) then minimize the number of AutoStarts. If you either don't have many Call Object kernels and don't restart often, AutoStart all of 'em.
 
So the question is, where do you have your maximum set? At the moment, we have a typo (in my opinion) on one set of batch servers. The max value was set to 100, the autostart was set to 100. The server has a lot of ram, but that's a little bit over the top. We had around 135 jdenet processes active on the servers. I proposed scaling the number of autostarts back to a more reasonable number. We are waiting for the other CNC to return from vacation before I make that change.

I could see caluculating the maximum load for the server, and autostarting that many, or at least a good chunk, of the call object kernels. At the moment, I would expect to need around 22 call object kernels to support a full load.

Any thoughts on that?
 
[ QUOTE ]
So the question is, where do you have your maximum set? At the moment, we have a typo (in my opinion) on one set of batch servers. The max value was set to 100, the autostart was set to 100. The server has a lot of ram, but that's a little bit over the top. We had around 135 jdenet processes active on the servers. I proposed scaling the number of autostarts back to a more reasonable number. We are waiting for the other CNC to return from vacation before I make that change.

I could see caluculating the maximum load for the server, and autostarting that many, or at least a good chunk, of the call object kernels. At the moment, I would expect to need around 22 call object kernels to support a full load.

Any thoughts on that?

[/ QUOTE ]

Have you looked into Kernel Resource Management functions to measure your actual kernel usage?

http://blog.karamazovgroup.com/2010/05/enterpriseone-tools-release-8983-notes_06.html
 
Thanks Jeff.

That's very useful. We are only about six weeks post go-live on 9.0 and I am also supporting XE and a couple of instances of 8.12. I haven't had a chance to really dig in to the new tools.
 
[ QUOTE ]
So the question is, where do you have your maximum set? At the moment, we have a typo (in my opinion) on one set of batch servers. The max value was set to 100, the autostart was set to 100. The server has a lot of ram, but that's a little bit over the top. We had around 135 jdenet processes active on the servers. I proposed scaling the number of autostarts back to a more reasonable number. We are waiting for the other CNC to return from vacation before I make that change.

I could see caluculating the maximum load for the server, and autostarting that many, or at least a good chunk, of the call object kernels. At the moment, I would expect to need around 22 call object kernels to support a full load.

Any thoughts on that?

[/ QUOTE ]

The tuning for Call Object kernel has changed since multi-threading was introduced. The old and simple rule of thumb stating x number of processes per x number of users is no longer valid. the new rule of thumbs says to keep the number of Call Object kernels relatively low and allow threads to be spawned, not processes.

Here's what I do:

Calculate based on 2-5 users per thread but set threads per kernel to 20 and increase threads by increasing kernels to meet the number of threads required.


So, answering your question - having 100 CO kernel start sounds like an awful lot. If you assume 5 users per thread and you have 100 kernels with thread pools of 50 then you are autostarting enough threads for 5,000 users on that box. However, knowing how large your implementation is this is not out of range it seems.
 
[ QUOTE ]

So, answering your question - having 100 CO kernel start sounds like an awful lot. If you assume 5 users per thread and you have 100 kernels with thread pools of 50 then you are autostarting enough threads for 5,000 users on that box. However, knowing how large your implementation is this is not out of range it seems.

[/ QUOTE ]

yea, actually it is out of whack. We are only in phase one of a multi-year project. Phase one has 125 concurrent users at max load. I have servers for a whole lot more, but that is intentional. We are building out the overall environment well in advance. We are already looking at buying more exadata servers to anticipate our future load, but I digress....

So by my calcuations for 125 concurrent users, we would need 22 call object kernels. What I haven't looked at is the threads. Let me dig a little deeper on that.
 
Jeff,

just did the math, my calculation was based on the old method. But with the threads and based on your math, I need 25 threads. With a max load of 50 threads for call object kernel, I need to autostart one call object kernel.

Yea, autostarting 100 is a bit excessive.
 
[ QUOTE ]
Jeff,

just did the math, my calculation was based on the old method. But with the threads and based on your math, I need 25 threads. With a max load of 50 threads for call object kernel, I need to autostart one call object kernel.

Yea, autostarting 100 is a bit excessive.

[/ QUOTE ]

Or - to be more conservative:

125 concurrent users / 2 users per thread = 63 threads.

20 threads per call object kernel = 3.125 call object kernels.

Autostart four call object kernels on each active/active production batch server. (I have two boxes dedicated for production) Adjust over time as the load increases.

Does that sound about right?
 
[ QUOTE ]
Jeff,

just did the math, my calculation was based on the old method. But with the threads and based on your math, I need 25 threads. With a max load of 50 threads for call object kernel, I need to autostart one call object kernel.

Yea, autostarting 100 is a bit excessive.

[/ QUOTE ]

Hahaha, I was waiting for you to come to the conclusion that you needed exactly one CallObect kernel.

Feel free to autostart it if you wish.
cool.gif


I would actually size down the ThreadPool parameter to around 20. Denver tells me that is where they get the most stability.


With 125 users and the (liberal) assumption of 5 users per thread and a ThreadPool of 20 you would need 2 CallObject Kernels.

With 125 users and the (conservative) assumption of 2 users per thread and a ThreadPool of 20 you would need 4 CallObject Kernels.

Fudge a bit and set maxNumberOfProcesses=20 and autostart 4 of them.
 
[ QUOTE ]
[ QUOTE ]
Jeff,

just did the math, my calculation was based on the old method. But with the threads and based on your math, I need 25 threads. With a max load of 50 threads for call object kernel, I need to autostart one call object kernel.

Yea, autostarting 100 is a bit excessive.

[/ QUOTE ]

Or - to be more conservative:

125 concurrent users / 2 users per thread = 63 threads.

20 threads per call object kernel = 3.125 call object kernels.

Autostart four call object kernels on each active/active production batch server. (I have two boxes dedicated for production) Adjust over time as the load increases.

Does that sound about right?

[/ QUOTE ]


I just love it when two people cross postings at the same time....and come to the exact same conclusions.
 
Back
Top