![]() The view took about 20 seconds to open, which is greater than the threshold mentioned in VMT. Numbers in the }StatsB圜ube for our cube looks like this.Īs you can see the view takes about 72,704 bytes, along with 11.7M calculated cells & consolidations in it. Let’s turn on the performance monitor and open up a view from this cube then we will wait for a minute – since }StatsB圜ube is updated once a minute. For this cube VMT has been set to 2 and VMM as 2,048,000 (this means 2,048,00KB – close to 2GB). One of the dimensions is extremely large with 0.5 million elements in it (Refer to my erstwhile post on creating large dimensions). ![]() I have created a cube VMM_VMT with good number of dimensions, lot of overfeeding. In this cube, we are interested in the 3 items – “ Memory Used for Views“, “ Number of Stored Views” and “ Number of Stored Calculated Cells“. I have created a cube called VMM_VMT and in the screenshot we are looking at its stats. The remaining 2 dimension we will put it in row and columns. To understand these statistics, let’s put the dimension }PerfCubes in Title and select the cube we are interested in. In order to view the memory usage, open the control cube with name }StatsB圜ube In your Architect, right click on the server and click on “ Start Performance Monitor“.The default value is F (turned off) for this parameter PerformanceMonitorOn parameter is static which means you will need to shutdown the TM1 service, make changes to the entry in tm1s.cfg file, save it and turn on the TM1 server. Adding an entry PerformanceMonitorOn=T in your tm1s.cfg file.1st and 2nd columns in the below table correspond to the TM1 view requested by user.Īfter VMM and VMT values have been set for a given cube, to understand memory usage you will need to turn on the Performance Monitoring on the TM1 server. Let me illustrate this with some hypothetical cases. VMM setting is more than TM1 view memory.TM1 view calculation time in seconds is more than VMT AND.Stargate) when it meets the following criteria: At such a time, the requested TM1 view is put into view cache (a.k.a. In a nutshell – if user requests a TM1 View then the engine processes it and renders it. If no value is specified, then a default value of 5 is used If you assign a value of 2,048 in VMM then system reserves 2,048KB (2MB) of memory for that cube.My prior post on VMM and its default value, as IBM documentation is incorrect.If no value is specified, then a default value of 128 is used Enter appropriate value of VMM and VMT for the cube you are interested in.Turn on “ Display Control Objects” from Architect’s View menu.Both of them are properties that needs to be set for each cube. To fine tune and control the Stargate Views, TM1 provides couple of settings namely VMM (View Maximum Memory) and VMT (View Minimum Time). This holds all the values in the cube that are calculated by rules, consolidations (natural/user-defined) Calculation cache – For a given TM1 Cube, there is only one calculation cache. ![]() ![]() View cache – An IBM Cognos TM1 cube can have one or more View caches associated with it.There are 2 types of caches in Cognos TM1: Engine will try to use as much as possible from the cache. Thereby significantly boosting the response time. Once a TM1 view is cataloged in Stargate, next time if the same view is requested, then TM1 server will NOT compute the TM1 view … instead it retrieves the TM1 view from Stargate and renders it. These Stargate views are different from the regular TM1 Views. While tuning is more of an art than science, one of the steps that we normally take is to look at utilizing the TM1 View Caches (a.k.a. In some IBM Cognos TM1 model, there is a possibility of one or more cubes taking longer time to open. ![]()
0 Comments
Leave a Reply. |