TIBCO BW Memory Efficient Utilization

By | October 23, 2015

Efficient utilization of resources and achieving greater throughput with a good performance is always a key consideration for solutions developed in any organization. TIBCO BW based integration solutions are also measured on the same scale and performance tuning to gain maximum out of the finite resources has always been a need.

Memory is never infinite. Utilizing the available pool of memory in the most optimal way is the key to any TIBCO  based solutions. In this post; I am going to talk about some of the key performance tuning steps that you can consider to make your BW solutions work efficient, faster and desired.

Process Configurations for Efficient Memory Utilization

TIBCO provides various options for performance tuning at engine level by setting the MAX JOBS, FLOW LIMIT and ACTIVATION LIMIT for the process starters. These process configuration parameters have been explained in detail one of my previous blog posts which you can refer through below link:

An Overview of Using MAX JOBS, FLOW LIMIT and ACTIVATION LIMIT For Process Configuration


Enable Memory Saving Mode for Engine

TIBCO provides a memory saving feature which helps in optimized use of memory resources. This configurable option is by default set to false in bwengine.xml file. Set this property (EnableMemorySavingMode) to true for any specific process/engine or at a global level for all the BW engines.

Decide A Proper Value for Java Heap Size

For every BW engine running in a machine; memory pool is allocated based on the Heap Size configurations. Depending on the nature of your processes; choose Heap Size wisely and don’t simply go with default values.

Heap Size should be decided while considering that how many activities are there in the processes; are there any blocking activities in the processes; does the process involves any such XML transformations and mappings which require higher memory and all the complexities of the underlying processes. Initial Heap Size can be kept lower but Maximum heap size value should be sufficient enough to ensure that you don’t fall into memory related exceptions (like java.lang.OutOfMemoryError: unable to create new native thread etc.).

Thread Count Parameter

Thread Count is another important parameter which has a direct impact on throughput as well as memory utilization. The value of this property defines how much threads can run concurrently for a process engine. If the value of thread count is set low; it may result in a higher consumption of memory resources because of blocking nature of certain process activities. However, setting thread count value to some high number should also be decided carefully by keeping in mind the CPU resources availability.

You can also look into TIBCO performance tuning tips post which talks more about performance considerations.

Ajmal Abbasi

Ajmal Hussain Abbasi is a TIBCO Consultant By Profession with more than 6 years experience in TIBCO products. He has extensive practical knowledge of TIBCO Business Works, TIBCO Spotfire, TIBCO BE, EMS and TIBCO ActiveSpaces. He has worked on a number of highly critical integration projects in Telecom sector by using his skills in Tibco Designer, Adapters, TIBCO EMS, RV, Administrator, TIBCO BE, TIBCO ActiveSpaces etc. Ajmal Abbasi is also experienced in developing solutions using Oracle PL/Sql, Linux and Java. You can contact Ajmal Abbasi for Consultancy, Technical Assistance and Technical Discussions.

More Posts - Website - Facebook - LinkedIn

One thought on “TIBCO BW Memory Efficient Utilization

  1. Rob

    Hi Ajmal,
    we are experiencing some issues with the Xmx/Xms settings not being used when we start our BW applications. We set the TRA file with:
    java.extended.properties -Xms256m -Xmx512m -verbose:gc
    and after a restart, the ps aux shows Virtual memory at about 1.3 gigs, and RSS at about 300 megs. It does not seem to make any difference what values we set for Xm?, they are ignored and it starts with the same memory values pretty consistently. BW version 5.9.3, Java 1.6_30 on Redhat Linux 5.9
    Any suggestions what we are doing incorrect?


Leave a Reply

Your email address will not be published. Required fields are marked *