Hyperion Financial Reporting server 9.3.1 - Performance with Large batches

Question

I have not been able to find any help yet, so hopefully someone here can help.
We have several financial reporting servers so that we can schedule reports and have users on seperate servers so that they do not interfere with each other.
The problem is that when bursted batch reports that select 100 - +1000 members from the bursting dimension run, the resources are maxing out memory and if multiple batches with the same large number of (but different members) are run at the same time, we start having failures on the services where they hang or worse the server crashes (one server crashed early this morning).
The Windows 2003 servers are Dell 2950 1x intel core 2 duo 3GHz with 8GB of RAM.
We found that if we set the java memory parms at anything higher than 1.5GB the services do not start, so all 8GB available is hardly being used by the server since the FR services (batch scheduler, print server, reports, RMI) are the only things running.
The batches are bursting the report for each member to a network folder for users to access and for archival purposes.
We may need to get Oracle involved, but if anyone here has insight I'd appreciate the assistance.

Answer 1

Hi Robert
I have come across similar issues where the reports take much longer to run as part of a batch than it does when accessed direct via the workspace. Our issue was that Financial Reporting was not dropping the connection to Essbase. We were using windows os and had to add a few DWORDs to the registry:
1. Open the registry and navigate to Local Machine\System\CurrentControlSet\Services\TCPIP\Parameters
2. Add new DWORD Value named TcpTimedWaitDelay, right click and select Modify. Select decimal radio button, type in 30 (this is the number of seconds that TCP/IP will hold on to a connection before it is released and made available again, the default is 120 seconds)
3. Add new DWORD Value named MaxUserPort, right click and select Modify. Select decimal radio button, type in 65534 (this determines the highest port number TCP can assign when an application requests an available user port from the system, the default is 5000)
4. Add new DWORD Value named MaxFreeTcbs, right click and select Modify. Select decimal radio button, type in 6250 (this determines the number of TCP control blocks (TCBs) the system creates to support active connections, the default is 2000. As each connection requires a control block, this value determines how many active connections TCP can support simultaneously. If all control blocks are used and more connection requests arrive, TCP can prematurely release connections in the TIME_WAIT state in order to free a control block for a new connection)
I think we did this to both our essbase and application server and rebooted both afterwards, it made a dramatic improvement to batch times!!
As a personal note I try not to have too many batches running at once as they can interfere with each other and it can lead to failures. Where I have done this before we tend to use windows batch (.bat) files to launch the FR batches from the command line, if time allows I run a few batches to get a reasonable estimate of the time to complete and in my .bat file I add a pause of around that amount of time in between sending the batch requrests to the scheduler. Admittedly I've not done it yet where the number of reports in a bursting batch is as many as 1000.
Hopefully this will help
Stuart