From my understanding StatsByCube can, in many cases be inaccurate so it would be good see what debug says.
Original Message:
Sent: Wed March 27, 2024 11:37 AM
From: Bernhard Busslehner
Subject: PA 2.0.9.19 - MTFeeders.AtStartup=T, massive Feeder memory uplift for some cubes
Hi Ryan,
thank you for answer & hints. I will try to briefly answer your questions.
- Have you tried to use bookmark files to better manage the cube load times at start up?
- Not yet. I am only aware of the parameter "IndexStoreDirectory", which is not in use at the moment.
As far as I understand the bookmark files are generated by TM1 automatically - right?
What is the advantage of using bookmark files?
- Do you have any feeders that are conditional on cube data?
- In rare cases we do have conditional feeders and are aware of the difficulties combined with MTFeeders.AtStartup.
But the affected cubes are not using conditional feeders or feeders at all.
- When you say "automatically generating a feeder" what do you mean?
- The server is generating feeders for a Cube that is not having a feeders statement.
We have a cube storing massiv amount of data on the N-Level. No C-Level aggregation needed, cause it is a lookup cube on N-level.
Some Rules are applied on N-Level using DB & ATTR functions, therfore requesting data from other cubes. But this cube has no feeders at all, as they are not necessary if there is no need in the usage for aggregation or zero suppression.
Before the use of MTFeeders.AtStartup=T no feeders where generated at all for this cube. So far, expected behaviour.
After the use of MTFeeders.AtStartup=T the cube is generating feeders - based on the CubeStats - for every existing populated cell in this cube. So far, unexpected behaviour.
It seems that the Server is in rare cases generating feeders automatically even if there is no Feeders Statement in place.
- Is the number of fed cells listed in the stats cube increasing?
- Yes, it is. Unfortunately, not in all cases. Some cubes are not changed at all and in extreme cases - see previous comment - there is a change from zero feeders to as many feeders as populated cells in the cube.
Seems that the area definition of rules and therefore the effected number of cells is impacting the number of feeders generated.
- Have you used one of the debug options to determine that feeders are actually there?
- DebugUtility( 100, 0, 0, pCube, pPath|'\cubename_feeders.txt', '' ); Lists all calculated feeders in a text file, including the total number, for the given cube
- Thx for this useful hint. I was not aware of the DebugUtility. Will give i a try asap.
Is this approach better than the Stats-Cubes? The Stat Cubes seems to be not the most valid source of information.
br, Bernhard
------------------------------
Bernhard Busslehner
Original Message:
Sent: Wed March 27, 2024 10:34 AM
From: Ryan Clapp
Subject: PA 2.0.9.19 - MTFeeders.AtStartup=T, massive Feeder memory uplift for some cubes
Anytime you multi-thread an operation more RAM is required, combine that with the v11 memory allocator and you can certainly have significant growth in the memory baseline. A few questions come to mind
- Have you tried to use bookmark files to better manage the cube load times at start up?
- Do you have any feeders that are conditional on cube data?
- When you say "automatically generating a feeder" what do you mean?
- Is the number of fed cells listed in the stats cube increasing?
- Have you used one of the debug options to determine that feeders are actually there?
- DebugUtility( 100, 0, 0, pCube, pPath|'\cubename_feeders.txt', '' ); Lists all calculated feeders in a text file, including the total number, for the given cube
------------------------------
Ryan Clapp
Original Message:
Sent: Tue March 26, 2024 12:32 PM
From: Bernhard Busslehner
Subject: PA 2.0.9.19 - MTFeeders.AtStartup=T, massive Feeder memory uplift for some cubes
After the following changes in the tm1s.cfg file some of our cubes showing massive increase in memory consumption. Rooting in an uplift of memory for feeder generation.
We are on PA local 2.0.9.19
MTQ=10
MTCubeLoad=T
MTFeeders=T
MTFeeders.AtStartup=T
Our analysis has shown, that the parameter MTFeeders.AtStartup=T is generating massiv feeder uplift during restart, but this uplift is only applying to some cubes and not all of them. Furthermore, the cube showing the highest uplift is not using a FEEDERS Statement at all.
Our further analysis has shown that the following factors seems to trigger the behaviour.
1) Usage fo MTFeedersAtStartup=T and restarting the server
2) Cube with a significant amount of populated cells
3) Rule is applied to the cube, even when there is no FEEDERS statement
The defined area in the Rule ['abc']=N: has a major impact.
Worst case is a Rule with an undefined / "empty" area []=N
Result: The cube is generating automatically a feeder for each populated cell that is covered by the defined area in the rules statement. If the worst case rule statement (empty area) is used, this leads to the fact that for each populated cell a corresponding feeder is generated. Leading to a massiv feeder generation and therefore massiv memory consumption uplift.
Is this behaviour intended?
Because we are having lookup cubes in place holding massiv amount of data on N-level for lookup purposes but not using Feeders at all. These cubes are highly impacted by this behaviour.
Also the documentation for MTFeeders.AtStartup is not mentioning this behaviour.
Seems for me that PA is automatically generating Feeders in rare cases.
Maybe Huberts feederless rules engine has found a way to break free from the labs? ;)
hoping for some community help and insights.
kind regards
Bernhard
------------------------------
Bernhard Busslehner
------------------------------