Cognos Analytics

Cognos Analytics

Connect, learn, and share with thousands of IBM Cognos Analytics users! 

 View Only

  • 1.  Configuration recommendations with limited hardware resources

    Posted 25 days ago

    Hi everyone,

    I know the general rule is "more hardware helps", but in our case we have to work with what is available.

    Requirement:
    We plan to onboard more than 5,000 new users on our IBM Cognos Analytics environment.
    These users will mainly run reports with prompts in the morning peak hours, roughly between 8:00 and 10:00 AM.
    Because the reports are executed live with user input, pre-calculation or scheduling is not an option.

    Current setup:

    • Single virtual server

    • 8 vCPUs

    • 128 GB RAM

    Question:
    What configuration would you recommend under these constraints, especially regarding:

    • Report Service

    • Query Service

    • Batch Service

    • Other relevant services (dispatcher settings, limits, JVM memory, etc.)

    We are mainly looking for practical configuration guidance and best practices to handle this kind of concurrent interactive workload with limited hardware.

    Thanks in advance for your insights!

    Jens



    ------------------------------
    Jens Bäumler
    Cognos Analytics, Planning Analytics and watsonx
    Apparo Group
    Germay
    www.apparo.de
    ------------------------------


  • 2.  RE: Configuration recommendations with limited hardware resources

    Posted 23 days ago

    Hi Jens,

    I will start by saying this is a loaded question with two possible answers.  Yea, it isn't gonna work or it will be fine. 

    Some questions you need to ask your client. 

    How many users do they have now and how active are they?  How active are the new users going to be?  Will each user run multiple reports each morning?  Notice any core dumps with current load?  What format are the reports going to be delivered (PDF, XLS, HTML)?  How long does the reports take to generate (1sec, 1 min or 1hour)?   Are you running reports off of a CQM or DQM package?  What type of data sources are the reports going off of - operational, reporting (aka DW), cubes, uploaded files, etc?   Are the users going to interact with the report output in full interactive mode or running it to excel/PDF?  Are they emailing the results to themselves or others?  Can the reporting database(s) handle the additional load?  

    So many questions that need to be answered on your end.  😀

    I believe out of the box, Cognos sets the # of low affinity connections to 8 with # of report connections set to 2 (or maybe its 4).  

    The # of low affinity connections is going to be determined by how complex the reports are (aka - how much data is returned and crunched by cognos vs the db and whether it is CQM vs DQM).  The # of connections are going to be determined by a combination of: # of CPU cores, the CPUs speed and available memory.  Assuming single core CPUs and without knowing the CPUs speed, I would start at 2 report connections per CPU and monitor the system.  This will give you the ability to handle 8 x 2 x (# of low affinity connections). If # of low affinity is set to 8 -- than you can (in theory) handle 128 reports ( 8 x 8 x 2) running at exactly the same time.   If the system responds okay with those settings, you may try bumping the # of report connections up and see if it behaves or not.  Please note -- the # of report connections (8 x 2) needs to be split between the batch and report services based on how the users are interacting with the system.  

    I hope this helps -- feel free to DM me.



    ------------------------------
    John Cusack
    Analytica iQ
    ------------------------------

    Original Message


  • 3.  RE: Configuration recommendations with limited hardware resources

    Posted 23 days ago

    Hi Jens, 

    as John mentioned already before there is no "golden rule" for a perfect configuration for your requirements as its driven by many factors. The answer is: it depends :-) 

    You will have to iterate to find the best possible settings for your user load scenario. 

    please also keep in mind to reserve some resources for the OS itself (1-2 CPUs) to handle patching, security scans, antivirus, backup etc to avoid operating systems hickups. Don't assign all CPUs to Cognos Report Services - this will kill your machine when you hit a peak load.

    You also have to take into consideration which query engine is used and which bitness the bibustkservermain.exe is using.   A 32bit bibustkservermain.exe reporting process is still bound to the 32bit memory limitations. Too many connections to a 32bit report service process may end in out of memory of the same and will kill all report executions which are currently assigned to this bibustkservermain process. 

    Bibustkservermain.exe only makes use of 64bit memory limitations if cognos configuration is set to 64bit only (means no CQM anymore on this Cognos instance). 

    DQM should be the technology of your choice to have performance on report executions. If possible and model is dimensional make use of the local dqm caches to reduce database roundtrips and utilize cached query results. 

    Feel free to reach out to me directly. 

    br. 

    Christian

     



    ------------------------------
    BI plus GmbH
    Bahnhofstraße 53, A-6300
    Wörgl
    c.misslinger[at]biplus.at
    ------------------------------

    Original Message


  • 4.  RE: Configuration recommendations with limited hardware resources

    Posted 18 days ago

    Hi,


    I've been managing an environment of 25k users and 4.4 million executions per month.

    To be very straight to the point:

    My configuration would be:

    • 3 tier install: Content Manager, App Tier and Gateway. Or 2 tier, if you don't want to use gateway (I prefer to use)
    • WLP (Cognos configuration) of CM and App tier set to 8GB, it's enough for this # users. But I would change bin64/bootstrap_wlp_zlinux64.xml file for these two installs. When using IBM JRE, Cognos takes the value set in Cognos configuration and divide by 2 for Xms and divide by 4 for Xmn. So, for -Xms parameter, I would set to "-Xms${dispatcherMaxMemory}m" and for Xmn to "-Xmn${dispatcherMaxMemoryBy2}m". This way, JVM will use resources in a better way.
    • Number of process for report, based on you RAM and CPU, you may set to 32 process and incresing. 
    • For high affinity and low affinity, set to 1 and make these configurations: https://www.ibm.com/support/pages/how-limit-how-many-requests-bibustkservermain-process-will-service-order-prevent-it-hanginggoing-orphan. This way, your BIBus will process only one report and die after. You will avoid issues with larger BIBus and concurrency of many reports in same process. Trust me.

    • For batch, make same configuration of report. But, you may set a lower value for number of process.
    • For query service, if Cognos will fetch data only in database, you may start with 24GB and 16GB of nursery. In my environment with several tests and monitoring, I've noted that Query services use much more nursery area than old gen.
    • Will use data sets, Spark? If yes, start use 8GB for flint, setting max and min, nursey and Spark threads. My suggestion to be set in Admin Console, Configuration, Dispatchers, Environment:
      • qs.queryExecution.flintServer.extraJavaOptions -Xmn7168m
      • qs.queryExecution.flintServer.minHeap 8192
      • qs.queryExecution.flintServer.maxHeap 8192
      • qs.queryExecution.flintServer.sparkThreads 16

    Based on this setting you will have CM 8GB + App 8GB + Query 24GB + Flint (Spark Data Set/Uploaded files) 8GB = 48GB used to start CA services. You will have 80GB for OS and report BIBus process.
    Maybe you will have enough resources to increase number of report process or even Query Service memory setting. Monitoring you environment will answear that.



    ------------------------------
    Jeam Coelho
    Cognos Solution Architect

    IBM Champion

    LinkedIn: https://www.linkedin.com/in/jeamcoelho/
    ------------------------------

    Original Message


  • 5.  RE: Configuration recommendations with limited hardware resources

    Posted 18 days ago

    Hi Jeam.

    This is an interesting and proven strategy in very large environments, especially with a strong focus on isolation and stability. For our environment, however, we are deliberately starting with a different, incremental approach and will adjust the configuration based on measured results.

    Initial configuration for our test scenarios:

    • Report Service

      • 12 report server processes (peak) 

      • Low affinity connections: >=4

      • High affinity connections: 2

      • Standard JVM settings as defined in Cognos Configuration (no manual patching of bootstrap XML files)

    • Batch Report Service

      • Separate report server processes

      • Reduced number of processes (e.g. 6), same affinity logic

    • Query Service (DQM)

      • Dedicated JVM

      • Initial heap size of approximately 16–20 GB

      • Default nursery sizing; fine-tuning only after GC analysis

    • Compute / Flint (datasets, uploads)

      • No manual scaling initially

      • Default heap and Spark thread settings; tuning only when real workload requires it

    This configuration is intended as a stable baseline; further adjustments will be made strictly based on load testing, monitoring, and observed bottlenecks.

    Thx Jens 



    ------------------------------
    Cognos Tipps: https://www.cognoise.de
    Lernvideos: https://apparo.university (also in english - please PM)

    Jens Bäumler
    Cognos Analytics, Planning Analytics and watsonx BI
    Apparo Group, Germany
    www.apparo.de
    ------------------------------

    Original Message


  • 6.  RE: Configuration recommendations with limited hardware resources

    Posted 18 days ago

    Hi All. 

    I found this document on the subject. That helps too.

    https://public.dhe.ibm.com/software/data/sw-library/cognos/mobile/C11/guides/PerfTuneMonitor_forCA11_1_7.pdf

    But in the end, there are probably different strategies, and there's no way around testing and optimizing step by step.

    Jens



    ------------------------------
    Cognos Tipps: https://www.cognoise.de
    Lernvideos: https://apparo.university (also in english - please PM)

    Jens Bäumler
    Cognos Analytics, Planning Analytics and watsonx BI
    Apparo Group, Germany
    www.apparo.de
    ------------------------------

    Original Message


Related Content