We are often asked by client’s VMware and Hyper-V administrators, where Cognos BI is hosted within a virtualised environment for confirmation on how Cognos deals with CPU cycles and the result/requirement this has on the Hypervisor platform. This blog will aim to clarify this.
Cognos BI from the 8.4 version to the present 10.2.2 version, works on a multithreaded application tier. When end users/administrators execute workload within Cognos whether this is the manual execution of BI reports, scheduled reports or environment administrative/maintenance tasks, this fires off a Cognos dispatcher process in CPU. This process can also have a number of connections to it.
Cognos at any one time can fire off a maximum number of processes across the CPU cores which are available on the host hypervisor server and dependent on the number of CPU cores which are assigned to that hosted server, you have a recommended maximum number of processes for each Cognos sub service. It is possible to change these maximum number of processes for each sub service, which each dispatcher is allowed to process at any one time. The configuration of these maximum number of processes is classed as dispatcher tuning.
What is common/expected behaviour on each of the Cognos dispatcher servers is that CPU can sit idle/low activity for periods of time and Hypervisor administrators often question why numbers of CPU cores are assigned to Cognos application servers, when they appear to not being used within their Hypervisor management console/monitoring software. However, at the times of peak workload, Cognos will peak CPU time which is made available to it, with a combination of the number of CPU cores available to the host operating system and the maximum number of process which the dispatchers are allow to fire off at any one time. This is why performance tuning can become vital to an environment to optimise CPU usage during peak Cognos workload cycles.
Basically, the more CPU cores which you make available to a guest VM which hosts the Cognos Application server/dispatcher, the further you can push dispatcher tuning extents to ensure that additional CPU time that is available, is fully utilised by Cognos.
From the Hypervisor layer it is therefore important that CPU cores are available to Cognos dispatchers when heavier workloads are placed upon it and that the guest VMs are not put into long queues for CPU core availability on the Hypervisor host. Where we have seen problems in the past is where a workload appears to be executing at the user/administration side be that a report or administrative task, but all servers hosting the Cognos dispatchers appear to be sitting idle in terms of CPU usage. In some cases it has appeared that the Hypervisor layer which is shared with many other VMs, are contending for CPU core availability and therefore entering a queued state. This should therefore be closely monitored by the Hypervisor administrator to ensure CPU core availability for VMs which are hosting Cognos.
Other issues that we have seen in the past with virtualised environments are memory contention with other guest VMs, but also performance bottlenecks to shared storage where the underlying VMDK’s are stored leading to poor I/O rates to the SAN storage.
Whilst we don’t recommend a specific CPU make and model to use for virtualised Cognos environments, configuration and tuning at the Hypervisor layer should be optimal to allow good CPU core availability to guest VMs.Back to blog