EcoSys Performance Tuning Guide
The sections below outline a few key performance considerations. However, for a comprehensive review of performance, scalability, and sizing issues, refer to the EcoSys Performance Tuning Guide. You main obtain the guide from the EcoSys support channel.
Java Heap tuning
The maximum heap size of a Java application is limited by three factors: The CPU (32 bit or 64 bit) and the associated operating system limitations, the amount of virtual memory available on the system, and the amount of physical memory available on the system.
-
For 32 bit CPUs the maximum heap size is typically 1400MB.
-
For 64 bit CPUs, the maximum will depend on how much available virtual memory the operating system has. If the server is dedicated to a single application, the maximum heap size can be set to the physical memory size minus about 800MB – 1.0GB for the operating system.
It is imperative that the heap always stays in physical memory, as committing too much of a system's physical memory is likely to result in paging of virtual memory to disk, leading to significant performance degradation.
To decide how much memory to allocate to the heap, first check how much RAM the OS and other processes are consuming and add 20%-30% as a precaution, then allocate the remainder to the heap. See few examples in the table below.
Total RAM |
Used by OS and other Processes |
CPU |
Free RAM |
Recommended Heap |
---|---|---|---|---|
6,000MB |
2,500MB |
64 Bit |
3,500MB |
3,500MB |
8,000MB |
3,000MB |
64 Bit |
5,000MB |
4,000MB |
It is good practice to set the minimum -Xms and maximum -Xmx heap sizes to the same value in order to remove sizing decision from the virtual machine and improve performance predictability.
-
64 bit - To allow EcoSys to use memory above the 32 bit limitation on a 64 bit system you’ll need to change the ‘server.has32BitLimitOnHeapSize parameter in the ESFM_HOME\FMServerSettings.properties file to false:
server.has32BitLimitOnHeapSize=false
Refer to the EcoSys Performance Tuning Guide for detailed guidance on Java heap settings.
Tuning Oracle for EcoSys
Oracle settings differ from one environment to another and depend on the hardware, memory availability, OS, system processes and the load on the server.
It is imperative that the SGA size (sga_max_size) stays in physical memory, as committing too much of a system's physical memory is likely to result in paging of virtual memory to disk, leading to significant performance degradation.
To decide how much memory to allocate to the SGA, first check how much RAM the OS and other processes are consuming and add 30%-40% as a precaution, you can allocate the remainder to sga_max_size.
The recommended settings in the table below should work for most implementations; setting these settings incorrectly may cause the database server not to start. Contact EcoSys support to discuss your specific environment and needs.
Parameter |
Default |
Recommended |
Notes |
---|---|---|---|
open_cursors |
300 |
1000-3000 |
Maximum number of cursors each session can have open. |
session_cached_cursors |
20 |
150 |
Specifies the number of session cursors to cache. |
Processes |
500 |
5000 |
Number of allowed Oracle sessions. |
sga_max_size |
284M |
2000M-5000M |
Structural memory area that facilitates the transfer of data and information between clients and the Oracle database. |
sga_target_size |
284M |
2000M-5000M |
sga_target_size should be smaller or equal to sga_max_size. |
db_file_multiblock_read_count |
16 |
128 |
Only for Oracle 9i - Maximum number of database blocks read in one I/O operation during a full table scan. In Oracle 10g and later this parameter is set automatically – it is critical that this parameter is NOT set for these versions. |