Page 1 of 1
Feeder performance issues
Posted: Wed May 09, 2012 11:53 am
by 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'];
Re: Feeder performance issues
Posted: Wed May 09, 2012 1:46 pm
by jim wood
The rules point to different measures. I think you need to expand on the reason for this.
Re: Feeder performance issues
Posted: Wed May 09, 2012 4:57 pm
by mattgoff
In between your tests did you restart the server?
Re: Feeder performance issues
Posted: Wed May 09, 2012 9:28 pm
by 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,
Re: Feeder performance issues
Posted: Thu May 10, 2012 6:12 am
by kudzis
jim wood wrote: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.
mattgoff wrote: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.
Steve Rowe wrote: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".
Re: Feeder performance issues
Posted: Thu May 10, 2012 12:23 pm
by 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.
Re: Feeder performance issues
Posted: Fri May 11, 2012 6:23 am
by kudzis
Steve Rowe wrote: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.
Re: Feeder performance issues
Posted: Fri May 11, 2012 1:39 pm
by 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,