Friday Jan 31, 2014

New updates have been made to the OBIEE "Best Practices Guide for
Infrastructure Tuning" whitepaper. This updated whitepaper is for 11g Release 1 (11.1.1.6, 11.1.1.7) and can be
downloaded from the My Oracle Support knowledge article: Doc ID 1333049.1

The new revised document contains the following useful new and/or updated
tuning items:

Wednesday Oct 16, 2013

One of the most challenging aspects of performance tuning is knowing where to begin. To maximize Oracle EPM System performance, all components need to be monitored, analyzed, and tuned. This guide describe the techniques used to monitor performance and the techniques for optimizing the performance of EPM components.

TOP TUNING RECOMMENDATIONS FOR EPM SYSTEM:

Performance tuning Oracle Hyperion EPM system is a complex and iterative process. To get you started, we have created a list of recommendations to help you optimize your Oracle Hyperion EPM system performance.

This chapter includes the following sections that provide a quick start for performance tuning Oracle EPM products. Note these performance tuning techniques are applicable to nearly all Oracle EPM products such as Financial PM Applications, Essbase, Reporting and Foundation services.

Introduction: One of the most challenging aspects of performance tuning is knowing where to begin. To maximize Oracle® Business Intelligence Enterprise Edition performance, you need to monitor, analyze, and tune all the Fusion Middleware / BI components. This guide describes the tools that you can use to monitor performance and the techniques for optimizing the performance of Oracle® Business Intelligence Enterprise Edition components.

Disclaimer: All tuning information stated in this guide is only for orientation, every modification has to be tested and its impact should be monitored and analyzed. Before implementing any of the tuning settings, it is recommended to carry out end to end performance testing that will also include to obtain baseline performance data for the default configurations, make incremental changes to the tuning settings and then collect performance data. Otherwise it may worse the system performance.

Tuesday Jun 26, 2012

When an HPCM application is first created, it is likely that you will want to carry out some optimisation on the HPCM application’s Essbase outline in order to improve calculation execution times.There are several things that you may wish to consider.

Glossary: -Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xrs reduce use of OS signals by Java/VM (see documentation) -Xmns<size> Sets the initial size of the new (nursery) heap to the specified value when using -Xgcpolicy:gencon. By default, this option is selected internally according to your system's capability. This option will return an error if you try to use it with -Xmn. -Xmnx<size> Sets the maximum size of the new (nursery) heap to the specified value when using -Xgcpolicy:gencon. By default, this option is selected internally according to your system's capability. This option will return an error if you try to use it with -Xmn. -Xverify:<option> With no parameters, enables the verifier. Note that this is the default; used on its own, this option has no effect.

Additional parameters to review:

You can force the JVM to use large pages, which is more efficient memory management.Java VM command line option: -Xlp64K
JVM Environment Entry: LDR_CNTLR = “DATAPSIZE=64K@TEXTPSIZE=64K@STACKSPSIZE=64K”

You should also consider using huger pages.PPC64 supports 4K(default) and 16M (although this is more likely to speed things up but unlikely solve your heap problem...)
General info for AIX and PPC:
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/large_page_ovw.htm
Java vm command line:
"-Xlp<size>
AIX: Requests the JVM to allocate the Java heap (the heap from which Java objects are allocated) with large (16 M pages, if a sizeis not specified. If large pages are not available, the Java heap is allocated with the next smaller page size that is supported by the system. AIX requires special configuration to enable large pages.

For more information about configuring AIX support for large pages, see http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.prftungd/doc/prftungd/large_page_ovw.htm.
The SDK supports the use of large pages only to back the Java heap shared memory segments. The JVM uses shmget() with the SHM_LGPG and SHM_PIN flags to allocate large pages. The -Xlp option replaces the environment variable IBM_JAVA_LARGE_PAGE_SIZE, which is now ignored if set.
AIX, Linux, and Windows only: If a <size> is specified, the JVM attempts to allocate the JIT code cache memory using pages of that size. If unsuccessful, or if executable pages of that size are not supported, the JIT code cache memory is allocated using the smallest available executable page size."
You should also turn on verbose gc.Java VM command line option: –verbose:gc

Consider some of the following Java VM command line options (some IBM vm specific):- -Xgcpolicy:subpool "Uses an improved object allocation algorithm to achieve better performance when allocating objects on the heap. This option might improve performance on large SMP systems"
- -Xcompressedrefs "Use -Xcompressedrefs in any of these situations: When your Java applications does not need more than a 25 GB Java heap. When your application uses a lot of native memory and needs the JVM to run in a small footprint."
- -Xcompactexplicitgc "Enables full compaction each time System.gc() is called."
- -Xcompactgc "Compacts on all garbage collections (system and global)."
- -Xsoftrefthreshold<number> "Sets the value used by the GC to determine the number of GCs after which a soft reference is cleared if its referent has not been marked. The default is 32, meaning that the soft reference is cleared after 32 * (percentage of free heap space) GC cycles where its referent was not marked." Reducing this will clear out soft references sooner. If any soft referenced-based caching is being used, cache hits will go down but memory will be freed up faster. But this will not directly solve your OOM problem: "All soft references are guaranteed to have been cleared before the OutOfMemoryError is thrown.
The default (no compaction option specified) makes the GC compact based on a series of triggers that attempt to compact only when it is beneficial to the future performance of the JVM."