Planning Analytics

 View Only
Expand all | Collapse all

Stargate View creation time increasing

  • 1.  Stargate View creation time increasing

    Posted 22 days ago

    Hi there,

    We are on Planning Analytics on Cloud version 11.8.02800.9 (from the configuration tab in Administration)

    We have a process that runs daily where it creates a stargate view then uses that recordset to process.  The stargate view used to take approximately 10-15 minutes to run in January but is now taking upwards of 40 minutes. 

    What I am seeing is the stargate process taking around 40 minutes to run then another process to load it taking about 6 minutes to load.

    I saw the data only existed in the stargate view from 2025 onward but was pulling all fiscal periods back to 2008. I tried limiting the stargate view to greater than 2024 and saw the stargate view creation go to .11 seconds but the second piece to load go to 40 minutes.

    I could really use some advice on how to troubleshoot this and any help/recommendations on getting things back to the 10 minute range to process.

    Thanks in advance



    ------------------------------
    Bret Pothier
    ------------------------------


  • 2.  RE: Stargate View creation time increasing

    Posted 21 days ago

    Hi Bret,

    Could you confirm which loggers you have enabled?



    ------------------------------
    George Tonkin
    Business Partner
    MCI Consultants
    Johannesburg
    ------------------------------



  • 3.  RE: Stargate View creation time increasing

    Posted 21 days ago

    In our dev environment where I have been testing I had it set to the following but it was creating a ton of log files

    #
    #  Enable INFO level logging through the shared memory appender, by default.  The server #  will write informational messages, as well as errors and warnings to the log file.
    #
    log4j.logger.TM1=ALL, S1

    # S1 is set to be a SharedMemoryAppender
    log4j.appender.S1=org.apache.log4j.SharedMemoryAppender

    # Specify the size of the shared memory segment
    log4j.appender.S1.MemorySize=100 MB

    # Specify the max filesize
    log4j.appender.S1.MaxFileSize=100 MB

    # Specify the max backup index
    log4j.appender.S1.MaxBackupIndex=20

    # Specify GMT or Local timezone
    log4j.appender.S1.TimeZone=Local



    ------------------------------
    Bret Pothier
    ------------------------------



  • 4.  RE: Stargate View creation time increasing

    Posted 21 days ago

    Have a look at this article to get a better handle on what is going into the stargate: https://community.ibm.com/community/user/businessanalytics/blogs/george-tonkin/2023/12/02/get-the-most-out-of-planning-analytics-logging

    I have a suspicion that more years are going in than you think, and may just be zero suppressed.



    ------------------------------
    George Tonkin
    Business Partner
    MCI Consultants
    Johannesburg
    ------------------------------



  • 5.  RE: Stargate View creation time increasing

    Posted 21 days ago

    Thank you I will take a look. I think it is years as well. Just trying to prove it out.



    ------------------------------
    Bret Pothier
    ------------------------------



  • 6.  RE: Stargate View creation time increasing

    Posted 21 days ago

    When you say stargate, do you mean running the ViewConstruct formula in TI or some other method of querying the data?



    ------------------------------
    Ryan Clapp
    ------------------------------



  • 7.  RE: Stargate View creation time increasing

    Posted 20 days ago
    Edited by Karl Blackler 20 days ago

    Hi Bret,

    I've used similar techniques to precalculate a view before processing it with a TI process.

    The general premise is that the TI process retrieves the result from the cache and doesn't have to recalculate the view while it processes, thus saving a lot of time.

    To get the view to cache in the first place requires you to play with the VMM and VMT values, and generally these are designed for end-user views not larger TI view sources.

    Your issue sounds like the view size has just exceeded the VMM size, and its going back to non-stargate.

    I'd test increasing the VMM size and seeing if this solves the issue.

    Good luck

    ------------------------------
    Karl Blackler
    Head of Product Development
    Cortell Australia Pty Ltd
    Brisbane QLD
    ------------------------------



  • 8.  RE: Stargate View creation time increasing

    Posted 20 days ago

    Thank you . I will look in to it



    ------------------------------
    Bret Pothier
    ------------------------------



  • 9.  RE: Stargate View creation time increasing

    Posted 20 days ago

    Sachin has an excellent article on analysing Stargates here: https://everanalytics.wordpress.com/2016/03/22/stargate_deepdive/



    ------------------------------
    George Tonkin
    Business Partner
    MCI Consultants
    Johannesburg
    ------------------------------



  • 10.  RE: Stargate View creation time increasing

    Posted 17 days ago

    Thank you for all the help so far.

    I have done a few of the things in the article above, but I do not see any value in stored views for the cube that the stargate is running against. I also see the VMM and VMT values are blank for that cube.  Should those have a value in them in order to get the view cached? I do see the view listed under the cube so it is being created.  That being said the cube is fed mostly by rules I believe and is updated every night which I think would cause the stargate to generate anew each night.



    ------------------------------
    Bret Pothier
    ------------------------------



  • 11.  RE: Stargate View creation time increasing

    Posted 17 days ago

    Since limiting the stargate view to data greater than 2024 drastically reduced the view creation time but shifted the delay to the loading process, it suggests the bottleneck might be in how the data is being processed or transferred. I recommend checking the following: 1) Ensure your stargate view query is optimized and only pulls necessary data, 2) Review system logs or performance metrics to identify resource constraints (e.g., memory, CPU), and 3) Consider breaking the process into smaller chunks or parallelizing tasks if possible.



    ------------------------------
    Dr. Renzo Santoro
    ------------------------------



  • 12.  RE: Stargate View creation time increasing

    Posted 16 days ago

    ok so I have looked at it in more detail and I have additional questions, please bear with me.

    Details

    • The process that runs the stargate view initially runs at 4am daily.
    • The process that calls it a second time runs at noon daily.
    • I see no VMM and VMT values set from the cube the stargate is generated
    • I see no Memory Used for Stored Views or Number of Stored Views populated for the cube the stargate is generated 
    • I have checked and the other jobs that run between 4am and noon daily do not touch the cube or dimensions the stargate view is generated
    • I can see the view that is created by the stargate process listed in the Views for the cube

      Questions
    • What would cause the stargate view to be visible in the view list but not show in the StatsByCube?
      I have turned on and left performance monitor on in case it is a timing issue of what is being captured
    • If the view is listed and I can open it, why would the second process that calls it need to run it again?
      Would it not see the existing view and skip creating it again or is the stargate view explicitly saying create a new one.
    • Do I need to set VMM and VMT values? Does leaving them blank not make it meet the criteria by default?

    Thank you for all the help on this, I greatly appreciate it



    ------------------------------
    Bret Pothier
    ------------------------------



  • 13.  RE: Stargate View creation time increasing

    Posted 16 days ago

    Today I tried the following.

    I deleted every element that was not used in the dimensions (around 1000), and I deleted the stored stargate view to see if it would generate a new one and maybe cache it properly showing details in the statsbyCube.

    The stargate view still took a long time (2607 seconds) to complete AND/BUT the view was not created under the cube.



    ------------------------------
    Bret Pothier
    ------------------------------



  • 14.  RE: Stargate View creation time increasing

    Posted 15 days ago
    Edited by Matthias Holthus 15 days ago

    Hi Bret,

    concerning your questions from post 12: 

    a) "Stargate view" is just another term for "cached view". Thus you can have a lot of saved views showing up in your list but that doesn't mean, they are stargate views. They only show up in the stats cube when they are cached aka stargate views.

    b) The process reloads the specified view into the cache. It (almost, depends on the system usage context) ensures, the view is cached at a given time you want it to be cached. As memory reservation for caching is limited by default or VMM setting, old cached views will be thrown out of memory when new ones are loaded.

    c) VMM is 128kb and VMT 5 seconds by default per cube if you don't specify it differently. Your view will only be cached (stargate view), when loading time for a view exceeds VMT and is below VMM.

    The link George posted is really good on understanding this.

    In your case it looks like your view is just way larger than the VMM setting and thus doesn't get cached and needs to be fully loaded each time.

    Kind regards
    Matthias



    ------------------------------
    Matthias Holthus
    ------------------------------



  • 15.  RE: Stargate View creation time increasing

    Posted 6 days ago

    Thank you everyone for all the help and advice. I was able to get the stargate size down by going through the exercise of deleting elements that were no longer used in a few of the larger dimensions used. This seems to have had a positive effect in cutting the stargate view creation time in half.

    Thanks again

    Bret



    ------------------------------
    Bret Pothier
    ------------------------------