Impact of feeders on RAM

[harrytm1]

Hi all,

I have some questions concerning feeders and the impact on RAM given my recent experience using TM1 9.5.2.

Let's say there are Cube A and Cube B. Both cubes do NOT contain any data at the moment. Assume that Cube A is smaller than Cube B in terms of number of dimensions and elements. Cube A is to feed into Cube B. I proceed to write a feeder in Cube A which is of course undesirable since Cube A is smaller.

After the feeder is saved, does TM1 utilise ALL possible RAM that is required to generate the feeder markers into the fed cells in Cube B? In other words, even if there is no data, all necessary RAM will have been committed at the point of rule save? This means that subsequent increase in RAM in Cube B is solely due to manually entered data plus the calculated data driven by rules.

Or does TM1 only utilise RAM when data starts to be written into Cube A which leads to calculations being done in Cube B? It is understood that feeders, when fed, cannot be removed by subsequent rule changes. It can only be cleared after the TM1 server is restarted.

FYI, I'm using Persistent Feeders. What happened was that the main cube's RAM utilisation shot up after users start to write data into the feeding cubes that lead to calculations in main cube. Although one can attribute this to the calculated cells, but i wish to find out if feeder is the contributing factor here as well.

Many thanks.

[lotsaram]

Harry - the short answer is that feeders will get "fired" once data is populated in the input cell on the LHS of the feeder statement. It is only at this point once the feeders have fired and placed markers in the target cells that the feeder should consume memory. No input data = no feeders = no memory consumption.

If you want to know what is using memory in your source and target cells all you need to do is turn on the performance monitor and browse the }StatsByCube cube.

[jim wood]

Lotsa is very right. No data = no memory. Data + over feeding = more memory though.

[Cam]

I proceed to write a feeder in Cube A which is of course undesirable since Cube A is smaller.

hi,

why this is undesirable ?

[lotsaram]

I proceed to write a feeder in Cube A which is of course undesirable since Cube A is smaller.

hi,

why this is undesirable ?

If you are feeding from a cube with less dimensions and the missing dimensions happen to be large then you are potentially asking for trouble (trouble = overfeeding = long rule saves and slow calculation performance).

Best case you have a 1:1 mapping between one (or a combination of) the dimensions you do have and the ones you don't and you can determine the ID of the missing element(s) you want to feed by an AttrS() or DB() in which case there is no overfeeding and you don't have a problem. Worst case there is no mapping and you have to resort to feeding the top consolidation in the missing dimension(s), this makes the target cube dense and can literally cripple a model with rule saves of multiple hours and long calc times when users access cubes. Typically not something you want to do.

[tomok]

Lotsa is very right. No data = no memory. Data + over feeding = more memory though.

Are you sure that's right. The OP said he was using persistent feeders which is the new feature where you can use a flat file to feed the cells immediately on server startup and not have to evaluate the feeders. I would think in this instance that memory would be taken up because the cube is being fed. I've yet to use this new feature but I can't imagine it wokring any other way.

[lotsaram]

Persistent feeders aren't relevant to the situation as the OP described. What persistent feeders do is load the feeder markers from a file rather than evaluate the rule file and cube data on server startup. However when NEW input data is added to a cube that happens to be on the LHS of a feeder statement then behaviour is as it always has been: feeders will be fired and memory will go up due to the feeder markers. When data is next saved the feeder file will be saved in addition to the cube file so things are in sync for the next server restart.

[Cam]

Worst case there is no mapping and you have to resort to feeding the top consolidation in the missing dimension(s), this makes the target cube dense and can literally cripple a model with rule saves of multiple hours and long calc times when users access cubes. Typically not something you want to do.

Got it, thanks!

[harrytm1]

thanks for your replies. dealing with feeders is such a hassle. i think it is good to size up at least 64GB RAM for every instance now.

[harrytm1]

Hi all,

I have some questions further to my earlier post.

I'm currently using version 9.5.2. I had previously used 9.4.1, 9.5 and 9.5.1. It seems that this current version utilises more RAM for feeders as compared to others as I have encountered huge feeders that I never encountered before in similar size cubes.

I have not gone to deploy the same data files in earlier versions just to prove it, but will do so once i have a chance.

FYI, I'm using the following config parameters which I'm not sure will cause RAM issue with the current version:
ReevaluateConditionalFeeders=T
AllowSeparateNandCRules=T
AllRuleCalcStargateOptimization=T
PersistentFeeders=T
UseStargateForRules=T
ViewConsolidationOptimization=T

Next question is, I need to bring the Profit After Tax (PAT) data from Profit Loss cube into Retained Earnings (RE) account in Balance Sheet cube. So the rule in BS is:
['RE', 'Value'] = DB('Profit Loss', !Entity, 'PAT', 'YTD ' | !Period, !Year, !Version, 'Value');

Note that the YTD value from PL is required to flow into BS for the month.

I wrote the following feeder in PL cube:
['PAT', 'YTD Jan', 'Value'] => DB('Balance Sheet', !Entity, 'RE', 'Jan', !Year, !Version, 'Value);
NOTE: This is repeated over 12 feeders to take care of each month.

Doing this will mean that ALL PL accounts under consolidation PAT will feed into a single cell under "RE" element in BS cube as long as they have values. In addition, the feeding of YTD means all underlyin Period elements in PL cube will feed into the single Period element in BS cube.

How should the feeder be written to reduce the overfeeding? I'm thinking of just feeding the month like for like without YTD i.e.
['PAT','Value'] => DB('Balance Sheet', !Entity, 'RE', !Period, !Year, !Version, 'Value);

Hoever, the main culprit will be PAT. But I cannot safetly assume one account within PAT to always have value and the just feed from that single account. This is just one of the many feeder issues whenever a parent is fed into a single element, or a parent is fed into another parent (which causes a permutation). Correct?

Many thanks in advance!