Jan 1, 2022

Optimizing Pulse 6 in a large environment

This article explains some tips to optimize Pulse performance in a large environment (10+ TM1 instances).

Before reading through this article, you should be familiar with the following articles:

In this example, we have three environments DEV, UAT and PROD with 2 servers each and each server with 3 IBM Planning Analytics (TM1) instances so 18 instances in total.

Where to install Pulse?

The Pulse Application Server uses the TM1 REST API to connect to each TM1 instance therefore it does not need to be installed on each TM1 server. It is recommended to install Pulse on its own server but if one server is not available, you can install it on one TM1 server as long as there is enough memory and disk space available according to the Pulse system requirements.

⚠️ More resources are required by Pulse 6 vs Pulse 5, please check the new system requirements before installing Pulse:

In our example, we chose to install the Pulse Application on its own server and one Pulse Monitor on each TM1 instance.

One centralized Pulse server to monitor all

One Pulse Application Server can monitor many TM1 instances. In best case scenario you will end up with the architecture below, one Pulse to monitor all the TM1 instances:

Even though one Pulse Application Server can monitor many TM1 instances from many servers, if your environment is large (20+ TM1 instances), one Pulse Application Server will need a lot of memory to monitor everything.

It is difficult to estimate in advance because it will depend on how many sessions and logs each instance is generating.

Optimizing Pulse

Each second Pulse is going to retrieve all the sessions, logs and metrics such as cpu, ram for all instances.

If you want to keep one Pulse to monitor all your TM1 instances there are few tips that you can apply to optimize Pulse performance:

1 – Deactivate some instances

Some TM1 instances might not need to be monitored by Pulse, you can deactivate some instances to reduce the amount of requests Pulse needs to do:

2 – Increase Pulse JVM memory

If Pulse CPU is always very high, you should increase the Pulse Application Server JVM:

3 – Increase Elasticseach JVM memory

If Pulse Elasticsearch CPU is always very high, you should increase the Pulse Elasticsearch JVM:

4 – Increase the State Poll or Message Log Poll intervals

You can reduce the number of requests Pulse needs to do per server. For example, for the DEV instances, you might not need the sessions every second in this case you can increase the State Poll interval and make it run every 2 or 5 seconds:

5 – Spread out the update documentation

By default Pulse executes the documentation for all instances at 1:45 am. If you are working with 10+ instances, this will require a lot of memory and CPU for Pulse. So you could spread out the execution of the documentation by 5-10 min for each instance:

6 – Cleansing Pulse data

When working with many TM1 instances, Pulse is going to store lots of data very quickly, it is very important to be aware of the Pulse maintenance job and having the MaximumPulseDiskSpaceGB set to a relevant value for your environment.

One centralized Pulse server per environment

If you have tried all the tips above and you are limited in terms of memory that you can allocate to Pulse then you will just need to install multiple Pulse. For example below, to monitor 18 TM1 instances, we ended up with 3 Pulse, one per environment (DEV, UAT and PROD):

Related content

Loading related content