Multiple Cognos instances in one server (Performance Tuning) -Suraj Neupane

Multiple Cognos instances in one server
(Performance Tuning)
-Suraj Neupane
(Consultant @ Denver Water)
Performance Tuning
• Most important aspect after data integrity (sometimes before).
• Various approaches to tuning:
– Tune parameters in Cognos server.
– Report/model: Prompts; Union; Calculations; graph/text; drill etc.
– Use tools and features within Cognos: schedule/cube/shared drive.
– Database/ETL: Aggregate tables; other apps against the same db.
– Use features from third party apps: Tidal scheduler, BSP etc.
– Hardware upgrade: License; cost.
– Application upgrade: License/deprecated/new features; training.
– Add instances of application. (Results may vary).
• This presentation focuses on adding reporting instances.
– Not multiple instances of different versions such as C8 and C10.
– It’s opposite of distributed installation.
2
Report Service Tuning
Things to keep in mind depending upon setup:
a. High Affinity connections: 1 per process
b. Low Affinity connections: 4 per process
c. Maximum number of processes: 2 per processor
Maximum RAM two instances can use with 4 CPU: 20gb
2 X BIBus = 4gb X 2 for RS = 8gb
2 X BIBus = 4gb X 2 for BRS = 8gb
Java processes: up to 2gb each.
Set peak periods (eg. 7am-6pm).
(Note: Refer to Administration guide for other tuning settings).
3
Cognos Architecture
4
Services in a dispatcher
Each dispatcher adds associated Cognos services as mentioned below:
Agent service
Annotation service
BRS
CM cache service
CM service
Data movement
Delivery service
Event Management
Graphics service
Human Task
Index data service
Index search service
Index update
Job service
Log service
Metadata service
Metric Studio service
Migration service
Monitor service
Presentation
Query service
Report data service Report service
Planning…
Powerplay service
System service
etc…
5
Expectation from additional instances
• Work around OS Stack memory constraints of 2gb per running
process.
(Note: system needs enough physical memory cache for this method)
• Take the most out of underutilized resources.
• Load balance requests with multiple dispatchers.
• Report level processing with additional Cognos services.
• Overall, improve performance utilizing existing resources.
6
Analyze current setup
• Licensing Model: Named vs PVU.
– Named licensing model (old) can use additional hardware that is a
better option than adding instances.
– Adding instances is recommended for PVU licensing model.
[Note: Always consider license compliance before changes.]
• Current application load on server
– Current CPU and RAM utilization.
7
Analyze current setup…
• Is current setup working as expected?
- Create performance log files and monitor CPU usage trend.
- Do not implement if the usage is consistently over 80%
- Check logs for errors, monitor performance.
Server errors appear even after tuning as per IBM recommendations.
12.123.4.5:9300 7448 2011-01-26 15:47:10.385 -7 Audit.RTUsage.ms.MS Failed to run task
[com.cognos.monitor.tse.BiBusRunContext taskID=BD1ABFCF70597059012D4D6BB3B081360012dc47f91b1].
Error is: DPR-ERR-2056 The Report Server is not responding.
One of the famous error is ‘Server did something wrong’.
8
Analyze current setup…
• Check background jobs for ‘Pending’ status during scheduling window.
9
Implementation Process
• Install ‘Application Tier Components’ for new instances in new directory.
Do not install ‘Gateway’, ‘Content Manager’ and ‘Cognos Content Database’.
10
Implementation Process…
• Configure Cognos services for 2nd instance:
– Configure log server, shutdown and dispatcher URI with different port
numbers than original Cognos configuration.
• Apply all the custom modifications to the 2nd instance (Important!).
• Stop original Cognos services and add dispatcher URI from 2nd instance.
• Save configuration and start both instances of Cognos services.
• Tune both instances same (logging, tuning etc.) in Cognos administration.
• Restart both Cognos services after tuning is complete.
[Note: Refer to Administration guide for additional details]
11
Verification
When the implementation is complete, multiple dispatchers with
different port numbers exist in Cognos administration window.
12
Verification…
How to verify if the load balancing is working?
• Run reports and check requests received in both dispatchers.
• The report service requests should be divided between the
two dispatchers. The numbers may not be exactly same but
should be close enough.
Example:
After 1.5 months:
• Monitor performance as the results may not be as expected
that requires additional tuning.
13
Results from our implementation
• Existing reports/jobs/schedules are working as
before; some have better performance.
• ‘Report server is not responding’ error reduced.
• Job schedules do not get stuck in ‘Pending’ status.
• The server has become more stable and efficient.
- Less restarts due to jobs not pending anymore.
14
Dependencies with external apps
Analyze the implication for external applications such
as Tidal scheduler, BSP Metamanager etc. before and
after implementation.
- Number of job services/connections configured in external
applications may need modification due to new tuning
parameters in Cognos dispatchers.
15
Summary
• Check IBM license before any work on Cognos server.
• Analyze existing setup for bottleneck.
• Add instances of reporting services to allow better use of
underutilized hardware.
• Monitor performance after implementation.
• Experience may vary depending upon server
configuration/resources.
16
Disclosure and Q & A
• Implement this method at your own discretion.
• If you have similar setup, please provide configuration settings that
worked best.
• Feedback/comments? Feel free to email me:
[email protected]
[email protected]
720-432-8842
• Find me @
Cognoise, Experts-Exchange, ittoolbox & IBM Cognos forums.
… Thank You …
17