TM1 Forum

TM1 system table shows our system suffers with large memory consumed by feeders of some cubes, and also I notice there are some files with '.feeder' suffix in TM1 data folder, with large size.


Here is my question:

If I have 2 cubes. Cube A is source file, and cube B is target file.

Rule of cube A is like below:
-----------------------------------------------------------------------
SKIPCHECK;

FEEDERS;
['Sales'] => DB('Cube B', !Account, !other_dimensions...);
####################################################


Rule of cube B is like below:
-----------------------------------------------------------------------
SKIPCHECK;

['Sales']=N: DB('Cube A', !Account, !Other_dimensions...);

FEEDERS;
####################################################


Question1:
After saving of all rules, in which cube name will the memory of the feeder (as shown in rule of cube A above) be allocated?

Question2:
If system shows a cube consumes large feeder memory, but there are many feeders in that cube, how can I find the memory size consumed by each feeder statement? so that I can review and promote the statement.


Regards,
Chris

Q1/ (the easy part that I'm pretty sure you knew the answer to already)
The feeders are always saved in the TARGET cube (in your case "cube B") where memory is consumed for feeders and where the .feeders file is where the feeder flags are actually saved to disk. The feeder generation is from saving the source cube or doing a TI process feeders command on the cube that contains the feeder statement.

Q2/
The hard part. No there is no way to know how much memory or how many feeders each individual feeder statement is generating. Depending on the size of your rule file and number of feeder statements this could be tedious to do but the only way to do it is to selectively switch off all but one feeder statement and save the rule and rotate the active feeder. To do this you will need persistent feeders off and to unload the cube after each iteration. Depending on how the feeders are constructed you may well have overlapping area statements on the feeders so this is something to watch for. Could be tedious! I would analyse the area statements on the feeders in a fair bit of detail before doing anything like this.