Feeder performance issues

[kudzis]

Hello,

I've wrote 2 ways to calculate a measure and feed it. Way #1 eats all available RAM and crashes, way #2 works flawlessly (minor increase in RAM). Any idea why #2 works and what's causing it?

WAY #1:

Source (cube 'atsargos'):

Code: Select all

FEEDERS;
['Mato vnt','Poreikis pirkti'] => DB('salygos', !Inventory, 'Viso tiekėjų', !Laikotarpiai, !Sandėlis-tranzitas,
'VISO kontr. ir pap. pirkimų', !Planas-faktas, 'Pirkimo poreikis');

Target (cube 'salygos'):

Code: Select all

SKIPCHECK;

['Pirkimo poreikis'] = n:
if (
	attrn('Inventory', !Inventory, 'TMDeliveryDays')=0,
		DB('atsargos', !Inventory, !Laikotarpiai,
			'Mato vnt', !Sandėlis-tranzitas, !Planas-faktas, 'Poreikis pirkti'),0);

WAY #2:

Source (cube 'atsargos'):

Code: Select all

FEEDERS;
['Mato vnt','Poreikis pirkti'] => DB('salygos', !Inventory, 'Viso tiekėjų', !Laikotarpiai, !Sandėlis-tranzitas,
'VISO kontr. ir pap. pirkimų', !Planas-faktas, 'TMP Pirkimo poreikis');

Target (cube 'salygos'):

Code: Select all

SKIPCHECK;

['TMP Pirkimo poreikis'] =n: DB('atsargos', !Inventory, !Laikotarpiai, 'Mato vnt', !Sandėlis-tranzitas, !Planas-faktas, 'Poreikis pirkti');

['Pirkimo poreikis'] = n:
if (
	attrn('Inventory', !Inventory, 'TMDeliveryDays')=0,
		['TMP Pirkimo poreikis'],0);

FEEDERS;
['TMP Pirkimo poreikis'] => ['Pirkimo poreikis'];

[jim wood]

The rules point to different measures. I think you need to expand on the reason for this.

[mattgoff]

In between your tests did you restart the server?

[Steve Rowe]

You've not said what you are doing when the RAM is spiking.

If it is when you save the rule sheet for astargos then it is the feeder that is the problem.
If it is when you browse the cube salygos then it would either be the rule or the an overfeeding issue.

Breaking the rule logic into two steps should not make an difference to the calculation, in fact it should make 2 worse than 1.

My best guess (assuming not a bug) is that we are not comparing like with like. So in 1 the maybe any consolidations referred to in the feeder statement are many times larger than in 2.

I'm guessing you are on 32 bit TM1 and so have a hard RAM limit, in which case you will need to be quite careful with your feeders especially if you have high data volumes too.

When you say crash do you mean actually crash or "I got bored of waiting and killed it"?

Cheers,

[kudzis]

The rules point to different measures. I think you need to expand on the reason for this.

'TMP Pirkimo poreikis' was created as an intermediate measure just to hold values of DB('atsargos', !Inventory, !Laikotarpiai, 'Mato vnt', !Sandėlis-tranzitas, !Planas-faktas, 'Poreikis pirkti'); and participate in calculating ['Pirkimo poreikis']. Business logic is not changed.

In between your tests did you restart the server?

Yes. Before each test I was restarting the server. Edit: I am not using persistent feeders.

You've not said what you are doing when the RAM is spiking.

If it is when you save the rule sheet for astargos then it is the feeder that is the problem.
If it is when you browse the cube salygos then it would either be the rule or the an overfeeding issue.

Breaking the rule logic into two steps should not make an difference to the calculation, in fact it should make 2 worse than 1.

My best guess (assuming not a bug) is that we are not comparing like with like. So in 1 the maybe any consolidations referred to in the feeder statement are many times larger than in 2.

I'm guessing you are on 32 bit TM1 and so have a hard RAM limit, in which case you will need to be quite careful with your feeders especially if you have high data volumes too.

When you say crash do you mean actually crash or "I got bored of waiting and killed it"?

Cheers,

When I write a feeder and press "save rule", CPU load becomes 100% and RAM usage starts climbing until it windows reaches ~99% RAM usage (it takes 2-3 mins), then I get an error in my rule editor similar to "error saving rule: out of memory". Memory usage stays at 99% until I restart TM1 service.
I'm using TM1 64bit on Windows Server 2008 R2 Standard.
When I say "crash" I mean "RAM is used up and rule is not saved, but server functions a bit - I can still open small cubes, edit rules of other cubes and such, if I try to open larger cube I get "out of memory" error".

[Steve Rowe]

All seems a bit odd for a 64 bit box...
How much RAM have you got free before you save the rule? 2-3 minutes is very quick for RAM to run out even if something is wrong.
Can't really offer much more with the information to hand.

[kudzis]

All seems a bit odd for a 64 bit box...
How much RAM have you got free before you save the rule? 2-3 minutes is very quick for RAM to run out even if something is wrong.
Can't really offer much more with the information to hand.

I have ~8-9GB RAM free before saving a rule.

[Steve Rowe]

In that case we are probably missing a piece of information to explain this, I don't belive it would be possible for TM1 to chew through 8-9GB of RAM in 2-3 minutes following a rule save. It's fast but not that fast.

(You're not running 32 bit TM1 on 64 bit windows are you, you'll then have a much lower RAM limit and the amount you have spare on your box won't be relevant).
Cheers,