XMLP for EBS Performance Issue
By Tim Dexter-Oracle on Oct 05, 2010
With an eventful weekend now fading into the past. A scary car crash (we're OK, truck is decidedly not.) I loved that truck, 255K miles and still going like a trooper until Saturday. When my son and I got T boned in our local town. This side still has a wheel attached; on the other, things are not so good. A broken axle and the wheel broken off at the hub. Yes, that is a tree poking out the other side of the truck bed ... we got hit hard!
My wife then ended up in hospital, for an unexpected stay (unrelated to the crash.) Coming home today, kids are happy they are tired of grumpy, sore and tired ol Dad :0)
I did finally find a real use for Facebook thou; keeping friends and family around the world up to date on her progress.
Back to the meat of the post ...
Just passing along a message from the development team for all EBS customers using the embedded version of BIP/XMLP.
As many of you may know (or not) every time the concurrent manager runs a java job it starts up a new JVM instance. This has caused some customers issues around performance. The dev team have got to the bottom of it!
We have discovered a bug 10160133 that causes very slow performance when running multiple FOProcessor under the EBS Concurrent Manager.
In short, it is caused by not enough entropy in the operating system random number generator, so the second or third processes have to wait (sometime a few minutes) until there is sufficient entropy to generate the next random number.
Without going into further details, the performance issue has been resolved. See bug#10160133 for patches on MySupport.
This bug doesn't affect running multiple FOProcessor in 10g or 11g because they all run from the same JVM. Therefore there is no fix for 10g or for 11g Enterprise or as part of the OBIEE suite.