UBE Very Slow when outputting to XMLP

jolly

VIP Member
Hi All,

We have a UBE that when running conventionally to simple PDF output (i.e. no BIP) takes about 30 minutes.

However when we output this UBE through a fairly simple eText BIP template (no sorting etc) it takes a couple of hours.

Anyone have any idea why this could be?

E1 9.1, Tools 9.1.5.5 on iSeries V7R1 and DB2

Thanks
JohnO
 
Is BIP actually doing anything? I actually had an issue a few months ago where BIP just would process stuff like every hour or so. It wound up being the ping from a network monitoring solution was causing chatter on the xmlp kernel, and it would check to pick up the jobs until that ping was either delayed or a new kernel spun up when the load increased. Not sure if that helps, but if the job is stuck at W in the BIP job queue, it could be your issue.
 
Have you checked to make sure the XMLP kernel on the Enterprise Server has a solid XMX ("Java Max Heap Size") set?

We had to increase ours considerably higher than the default.
 
Brandon makes a really good point. The heap size can make a big difference in performance. We've seen substantial performance gains for BI Pub using JRockit JVM vs hotspot JVM.
 
Thanks very much for the suggestions guys!

I *think* we have identified another clue - this behavior is happening in a UBE that reads say a million rows from the BSVW, but most of them are suppressed by SuppressSectionWrite so there are only say 20k output records. I am wondering if the XMLP code is doing a bunch of work on rows that never get output whereas the PDF engine is just skipping it. XMLP might be doing something heavy like re-opening the XML file, seeking the end of file and then closing it (along with writing the open/close XML for an empty record).

Will report back soon, hopefully!

Cheers
JohnO
 
John,

I'm pretty sure that if you check the output XML file that suppressed sections/rows won't be there.
Easy enough to check it and see.
 
Small update - we doubled the memory (cache) allocated to the XMLP kernel but it doesn't appear to have made much difference so far.

jRockit no good for us... iSeries Enterprise Server.

So... off to Oracle to raise a case. Won't hold my breath.
 
Huh! Interesting. Never seen them or heard of them!

Currently 10/90/5 and no overrides.

Thanks
John
 
To start with I'd increase the small job memory allocation to 10. With regards to large v small job kernels, really depends on the sort of load you see but I try to keep them to whole numbers. So as an example, if you have 5 XML publisher kernels then I'd have either 20/80 or 40/60 split. Obviously if you have a larger number of big jobs then you increase the proportion of large job kernels and also look to increase the number of kernels overall. You can then set an override for the job you're have issues with to ensure that it always uses the large job configuration as BIP may not be allocating correctly.
 
Thanks Russell...

But... I think the problem is ahead of this phase in the process... The UBE is very slow creating the XML - and it is taking hours to get to the point that the XML data is handed to the RD queue. There seems something inherently wrong with the way the UBE is generating the XML , but the processing of the XML is not the problem. In other words, resubmitting the completed job to RD is not too slow - I can confirm that resubmitting a UBE that ran for 7 hours to RD only took a couple of minutes to process through the RD queue to completion.

So in summary - run the same UBE/version/data selection to PDF - about half an hour. Run it to XML - many hours. It is not associated with any particular UBE and can be demonstrated with pretty much any UBE.

My money is on the XML generator rescanning the output file on every output to find open/closing nested headers, scan to end of the file etc. Therefore the total number of i/o operations per number of output records could be some sort of Fibonacci exponential!


Cheers
JohnO
 
Back
Top