To use or not to use persistent feeders?
-
- Posts: 110
- Joined: Sat Nov 06, 2010 10:10 am
- OLAP Product: Cognos TM1
- Version: 10.2.2
- Excel Version: Excel 2013
To use or not to use persistent feeders?
Hi guys,
I'm just wondering - do you use persistent feeders or not?
If yes - why?
If not - why?
I have my own opinion for this topic but I would like to hear also others...
BR
Vladino
I'm just wondering - do you use persistent feeders or not?
If yes - why?
If not - why?
I have my own opinion for this topic but I would like to hear also others...
BR
Vladino
-
- Community Contributor
- Posts: 341
- Joined: Wed Nov 03, 2010 9:16 pm
- OLAP Product: tm1
- Version: 10 2 2 - 2.0.5
- Excel Version: From 2007 to 2013
- Location: Earth
Re: To use or not to use persistent feeders?
Hi,
We found various bugs with persistent feeders in various releases, although I admit we do not re-test it with every new release and it may well happen that the latest 10.2.2 FP6 / 10.3 works fine.
So as long as the server comes up in an acceptable (good question what is acceptable though) time, we do not use persistent feeders
We found various bugs with persistent feeders in various releases, although I admit we do not re-test it with every new release and it may well happen that the latest 10.2.2 FP6 / 10.3 works fine.
So as long as the server comes up in an acceptable (good question what is acceptable though) time, we do not use persistent feeders
-
- Community Contributor
- Posts: 217
- Joined: Thu Aug 15, 2013 9:05 am
- OLAP Product: TM1
- Version: 10.2.1.1
- Excel Version: 14.0.6129.5000
Re: To use or not to use persistent feeders?
Persistent feeders help a TM1 server start up quicker. When the persistent feeders parameter is set to T, the TM1 server will create .feeder files for each cube that has feeders in their rule files. when the TM1 server starts up it matches the feeders for each cube by the coordinates in the .feeder files and loads them, removing the need to recalculate the feeders and that in turn saves time.vladino wrote:Hi guys,
I'm just wondering - do you use persistent feeders or not?
If yes - why?
If not - why?
I have my own opinion for this topic but I would like to hear also others...
BR
Vladino
A drawback of persistent feeders is the use of disk space. .Feeder files can be huge and you will have to take extra care when using them.
Although the use of persistent feeders make a TM1 server start up quicker, are they really worth it? How many people need there live TM1 server to start up quickly? Should they not be running all day and perhaps even during the night. If you need to restart your servers, you can do it at night time. If there is a crash, the .feeder files may be invalidated. It may however be the case that you have historical models, that need to be brought up upon request, in this case then persistent feeders would be beneficial.
So you need to weigh the likely hood of needing to get your TM1 model up quicker and the maintenance side of .feeder files.
Also, as the IBM document notes, you will probably see an improvement in start up times, if your model takes more than 5 minutes to start up, so anything less than that and I wouldn't bother.
By the way, I have just found this IBM tech note http://www-01.ibm.com/support/docview.w ... wg27039210. Did anyone else know of this?
Thanks.
Trevor.
-
- Posts: 60
- Joined: Thu Nov 17, 2016 2:13 pm
- OLAP Product: TM1
- Version: 10.2.2
- Excel Version: 2013
Re: To use or not to use persistent feeders?
Can PersistentFeeders=T cause a TM1 Crash?
yes from Cognos TM1 version 10.1.1 the PersistentFeeders were turned to T
yes from Cognos TM1 version 10.1.1 the PersistentFeeders were turned to T
-
- Community Contributor
- Posts: 217
- Joined: Thu Aug 15, 2013 9:05 am
- OLAP Product: TM1
- Version: 10.2.1.1
- Excel Version: 14.0.6129.5000
Re: To use or not to use persistent feeders?
Well, it can cause you to run out of disk space, which will cause a crash, but apart from that I am not so sure.
- Steve Rowe
- Site Admin
- Posts: 2444
- Joined: Wed May 14, 2008 4:25 pm
- OLAP Product: TM1
- Version: TM1 v6,v7,v8,v9,v10,v11+PAW
- Excel Version: Nearly all of them
Re: To use or not to use persistent feeders?
I think...
The only reason to use persistent feeders is if for some reason you need to ensure fast starts of the TM1 Server and you can't use Mutli Threaded Loads because of RAM Restrictions.
Given a well designed stable TM1 Instance in a well controlled environment (yes I know, fat chance) fast starts should never be important. If your environment / business process requires restarts then you should be addressing those issues not using persistent feeders to mask the fact that they exist.
Development should never be done with persistent feeders on as again it will mask inefficiencies in the build or hide the impact of the feeders required to make the model work.
This cfg is a solution to a problem, if you have this problem you should make sure it is fully understood and you have applied the correct solution.
IMO they should never be on by default.
The only reason to use persistent feeders is if for some reason you need to ensure fast starts of the TM1 Server and you can't use Mutli Threaded Loads because of RAM Restrictions.
Given a well designed stable TM1 Instance in a well controlled environment (yes I know, fat chance) fast starts should never be important. If your environment / business process requires restarts then you should be addressing those issues not using persistent feeders to mask the fact that they exist.
Development should never be done with persistent feeders on as again it will mask inefficiencies in the build or hide the impact of the feeders required to make the model work.
This cfg is a solution to a problem, if you have this problem you should make sure it is fully understood and you have applied the correct solution.
IMO they should never be on by default.
Technical Director
www.infocat.co.uk
www.infocat.co.uk
-
- MVP
- Posts: 2834
- Joined: Tue Feb 16, 2010 2:39 pm
- OLAP Product: TM1, Palo
- Version: Beginning of time thru 10.2
- Excel Version: 2003-2007-2010-2013
- Location: Atlanta, GA
- Contact:
Re: To use or not to use persistent feeders?
Not so fast my friend. I have clients with multi-national operations where down-time, at any time of the day, can potentially disrupt work even for planned outages like code deployments. Persistent feeders has been a god-send for those people in that deployments can mean minimal disruptions. I agree Persistent Feeders can be bad for development environments but it can be a great thing for production environments.Steve Rowe wrote:Given a well designed stable TM1 Instance in a well controlled environment (yes I know, fat chance) fast starts should never be important. If your environment / business process requires restarts then you should be addressing those issues not using persistent feeders to mask the fact that they exist.
-
- MVP
- Posts: 3687
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: To use or not to use persistent feeders?
I have to say I don't understand the comments from my colleagues in this thread at all. I don't get why people are down on persistent feeders. I think they're great and I use them always. Fast starts are always better than slow starts, I can't see why anyone would think different.
I have no issue with the default behaviour in recent versions being persistent feeders on.
In a production system I can't think of any reason to NOT have persistent feeders on. ... Yes sure ideal world blah, blah, controlled restarts out of hours blah, blah, systems should be stable blah blah. BUT sometimes the world isn't ideal and production systems crash. When this happens I want my system to be back up in the shortest possible time. Feeder files can be huge, so what, disk space isn't expensive. If it means cutting server restart time by 80%+ I'll take it thanks very much.
(Edit: Yes there was a bug in 10.2.2 series where someone from IBM lost their mind and a non-rule cell which contained data and was fed (i.e. OVERFED) from a .feeders file wiped out the data, but this bug is thankfully fixed.)
In my experience persistent feeders have always been stable and never heard of a crash due to them. The only issue is when PersistentFeeders is combined with MaximumCubeLoadThreads for faster loads and there is a feeder consistency check failure on server restart which then results in massive memory blowout due to redundant feeders. (technically this is a problem with the multi-threaded load as opposed to persistent feeders as the problem is exposed when forced to load without the feeder files.)
One thing I do agree on is that Persistent Feeders aren't ideal for development systems where rules are being developed as it makes unloading cubes to debugging feeder issues more difficult.
I have no issue with the default behaviour in recent versions being persistent feeders on.
In a production system I can't think of any reason to NOT have persistent feeders on. ... Yes sure ideal world blah, blah, controlled restarts out of hours blah, blah, systems should be stable blah blah. BUT sometimes the world isn't ideal and production systems crash. When this happens I want my system to be back up in the shortest possible time. Feeder files can be huge, so what, disk space isn't expensive. If it means cutting server restart time by 80%+ I'll take it thanks very much.
(Edit: Yes there was a bug in 10.2.2 series where someone from IBM lost their mind and a non-rule cell which contained data and was fed (i.e. OVERFED) from a .feeders file wiped out the data, but this bug is thankfully fixed.)
In my experience persistent feeders have always been stable and never heard of a crash due to them. The only issue is when PersistentFeeders is combined with MaximumCubeLoadThreads for faster loads and there is a feeder consistency check failure on server restart which then results in massive memory blowout due to redundant feeders. (technically this is a problem with the multi-threaded load as opposed to persistent feeders as the problem is exposed when forced to load without the feeder files.)
One thing I do agree on is that Persistent Feeders aren't ideal for development systems where rules are being developed as it makes unloading cubes to debugging feeder issues more difficult.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
-
- Community Contributor
- Posts: 311
- Joined: Mon May 12, 2008 8:11 am
- OLAP Product: TM1
- Version: TM1 11 and up
- Excel Version: Too many to count
Re: To use or not to use persistent feeders?
+1 for Tom. I have people using the system around the clock, and minimising downtime is key.
Paul
- Steve Rowe
- Site Admin
- Posts: 2444
- Joined: Wed May 14, 2008 4:25 pm
- OLAP Product: TM1
- Version: TM1 v6,v7,v8,v9,v10,v11+PAW
- Excel Version: Nearly all of them
Re: To use or not to use persistent feeders?
I feel the need to respond!
I thought I had qualified my statement (yes I know, fat chance) well enough...
I'm talking in general terms, for the general system and the general level of competence. They mask the true behaviour of the system and can hide defects in the feeders themselves.
As a developer / site DBA you should only be using them if you are very comfortable with feeders.
The majority of the systems we deliver have them on for the reasons the others mention, start-up convenience.
What measures do you put place to delete the .feeder files to prevent over feeding in the longer term?
I thought I had qualified my statement (yes I know, fat chance) well enough...
I'm talking in general terms, for the general system and the general level of competence. They mask the true behaviour of the system and can hide defects in the feeders themselves.
As a developer / site DBA you should only be using them if you are very comfortable with feeders.
The majority of the systems we deliver have them on for the reasons the others mention, start-up convenience.
What measures do you put place to delete the .feeder files to prevent over feeding in the longer term?
Technical Director
www.infocat.co.uk
www.infocat.co.uk
- Alan Kirk
- Site Admin
- Posts: 6629
- Joined: Sun May 11, 2008 2:30 am
- OLAP Product: TM1
- Version: PA2.0.9.18 Classic NO PAW!
- Excel Version: 2013 and Office 365
- Location: Sydney, Australia
- Contact:
Re: To use or not to use persistent feeders?
I see Steve's point but admit that I feel inclined toward the Lotsaram / Tomok view here.
But just one small thing:
The obvious advantage is startup speed. The just as obvious disadvantage is that save time increases, but I haven't seen that to be a real problem. Disk space is (or should not be) not a huuuuge issue... if the feeder files are that huge it's probably time to re-evaluate the feeders anyway. The only other down side that I've encountered is that occasionally, very occasionally and without any underlying change having been made to the system, on reboot I may get an error message telling me that there is "an inconsistency" in the feeder files and that they will be deleted and the server will be rebooted... but the reboot doesn't happen and I have to restart the service manually. Not sure why, and it doesn't happen all the time. It's not something that happens often enough for me to worry about.
But just one small thing:
The more common reason for not being able to use MT loads is that you have conditional feeders. And if you have to use conditional feeders it probably means that you have lots and lots of (probably complex) feeders. And IMHO that's exactly the kind of environment where you can do without an across the board re-evaluation of all of the feeders at startup unless you feel like heading down to the coffee shop and putting your feet up for a while.Steve Rowe wrote:The only reason to use persistent feeders is if for some reason you need to ensure fast starts of the TM1 Server and you can't use Mutli Threaded Loads because of RAM Restrictions.
The obvious advantage is startup speed. The just as obvious disadvantage is that save time increases, but I haven't seen that to be a real problem. Disk space is (or should not be) not a huuuuge issue... if the feeder files are that huge it's probably time to re-evaluate the feeders anyway. The only other down side that I've encountered is that occasionally, very occasionally and without any underlying change having been made to the system, on reboot I may get an error message telling me that there is "an inconsistency" in the feeder files and that they will be deleted and the server will be rebooted... but the reboot doesn't happen and I have to restart the service manually. Not sure why, and it doesn't happen all the time. It's not something that happens often enough for me to worry about.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
- Alan Kirk
- Site Admin
- Posts: 6629
- Joined: Sun May 11, 2008 2:30 am
- OLAP Product: TM1
- Version: PA2.0.9.18 Classic NO PAW!
- Excel Version: 2013 and Office 365
- Location: Sydney, Australia
- Contact:
Re: To use or not to use persistent feeders?
Ooops, I forgot to respond to this, though I meant to.Steve Rowe wrote:What measures do you put place to delete the .feeder files to prevent over feeding in the longer term?
I for one don't as such, but that's mainly because I know that once a value goes from zero to non-zero it won't go back to zero often enough to make a material difference. If I do a major re-jig of cubes or rules, I'll sometimes just manually delete any .feeders files and let the system refresh itself that way, but in my own environment it's not enough of an issue to worry about. I can imagine that it might be something that needs addressing in other environments, though.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
-
- Community Contributor
- Posts: 217
- Joined: Thu Aug 15, 2013 9:05 am
- OLAP Product: TM1
- Version: 10.2.1.1
- Excel Version: 14.0.6129.5000
Re: To use or not to use persistent feeders?
There is something else that needs to be taken into account when deciding on the use of persistent feeders, and that is memory.
Now the IBM document for using persistent feeders states:
So the IBM statement may still stand true, but there is at least a correlation between .feeder files usage and memory.
Trevor.
Now the IBM document for using persistent feeders states:
but, a while back I started a post http://www.tm1forum.com/viewtopic.php?f ... 680#p58680 that asked why I am seeing vastly different RAM consumptions of TM1 servers. One sever was a live model, the other was a snapshot of that live model at year end. The live model used persistent feeders, the snapshot did not. The result of RAM usage was:Using the Persistent Feeders feature will increase your system size on disk only. Memory size is not affected by the use of this parameter.
In short, a conclusion was reached that demonstrated how .feeder files saved calculation time and therefore memory usage, because less resources were being used due to the coordinates of the feeders being saved down.With PersistentFeeders = load time 70 seconds RAM usage = 6,993,380 K
Without PersistentFeeders = load time 861 seconds RAM usage = 13,569,300 K
So the IBM statement may still stand true, but there is at least a correlation between .feeder files usage and memory.
Trevor.
-
- Posts: 110
- Joined: Sat Nov 06, 2010 10:10 am
- OLAP Product: Cognos TM1
- Version: 10.2.2
- Excel Version: Excel 2013
Re: To use or not to use persistent feeders?
Hi guys,
first of all - a big THANK YOU to all for your answers!
Now what's behind the question...
I've been using persistent feeders in the past. It was really good to have the model up and running that fast, especially during the planning cycle. But then users have experienced wrong results in calculations and after some digging I found out that the reason was... persistent feeders! I don't know why was that but when I processed feeders for all cubes then the results were good again.
And then I figured out that the primary reason was that we've been using conditional feeders. That's why we also couldn't use "MaximumCubeLoadThreads" in the CFG file.
So my feeling with the persistent feeders is that I can definitely use them but only when not using conditional feeders because the model may return wrong results.
But there may be other solution - use "ForceReevaluationOfFeedersForFedCellsOnDataChange". This parameter is currently set to "F" because there might be some performance issues as the model is quite huge...
I've never played with these CFG settings. Could anyone say/prove that:
- to get correct results and fast startup we can use persistent feeders even if there are conditional feeders, "MaximumCubeLoadThreads" has to be set to "F" and "ForceReevaluationOfFeedersForFedCellsOnDataChange" has to be set to "T"
- we can turn off persistent feeders because there are conditional feeders, "MaximumCubeLoadThreads" has to be set to "F" and "ForceReevaluationOfFeedersForFedCellsOnDataChange" can also be set to "F" but the initial start of the system will be much slower
- we can turn off persistent feeders and use "MaximumCubeLoadThreads" instead but there cannot be any conditional feeders
- etc.
Thank you in advance!
BR
Vladino
first of all - a big THANK YOU to all for your answers!
Now what's behind the question...
I've been using persistent feeders in the past. It was really good to have the model up and running that fast, especially during the planning cycle. But then users have experienced wrong results in calculations and after some digging I found out that the reason was... persistent feeders! I don't know why was that but when I processed feeders for all cubes then the results were good again.
And then I figured out that the primary reason was that we've been using conditional feeders. That's why we also couldn't use "MaximumCubeLoadThreads" in the CFG file.
So my feeling with the persistent feeders is that I can definitely use them but only when not using conditional feeders because the model may return wrong results.
But there may be other solution - use "ForceReevaluationOfFeedersForFedCellsOnDataChange". This parameter is currently set to "F" because there might be some performance issues as the model is quite huge...
I've never played with these CFG settings. Could anyone say/prove that:
- to get correct results and fast startup we can use persistent feeders even if there are conditional feeders, "MaximumCubeLoadThreads" has to be set to "F" and "ForceReevaluationOfFeedersForFedCellsOnDataChange" has to be set to "T"
- we can turn off persistent feeders because there are conditional feeders, "MaximumCubeLoadThreads" has to be set to "F" and "ForceReevaluationOfFeedersForFedCellsOnDataChange" can also be set to "F" but the initial start of the system will be much slower
- we can turn off persistent feeders and use "MaximumCubeLoadThreads" instead but there cannot be any conditional feeders
- etc.
Thank you in advance!
BR
Vladino
-
- MVP
- Posts: 1822
- Joined: Mon Dec 05, 2011 11:51 am
- OLAP Product: Cognos TM1
- Version: PA2.0 and most of the old ones
- Excel Version: All of em
- Location: Manchester, United Kingdom
- Contact:
Re: To use or not to use persistent feeders?
Conditional feeders could give you wrong results regardless of whether you use persistent feeders or not.
E.g.
In the above example (one of the simplest conditional feeders I could think of that we pretty much all use and don't always consider to be conditional); when Value first goes from 0 to 100 it will fire the feeder and look correctly at the account attribute and feed it. When the attribute then changes from account 4 to account 5; nothing tells the source cube to refire the feeder... even the reevaluate fed cells cfg parameter doesn't; as TM1 does not know the attribute is used in other things.
So if you use conditionals you will ALWAYS need to factor in the fact you will need to fire the feeders sometimes yourself... whether its a well planned TI that is actioned from certain other changes etc or just a manual kick now and again... it needs to be done.
E.g.
Code: Select all
['VALUE']=>Db('Cube',Attrs('DimA',!DimA,'Account'), 'Measure');
So if you use conditionals you will ALWAYS need to factor in the fact you will need to fire the feeders sometimes yourself... whether its a well planned TI that is actioned from certain other changes etc or just a manual kick now and again... it needs to be done.
Declan Rodger
-
- MVP
- Posts: 3687
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: To use or not to use persistent feeders?
To reinforce what Declan said. What you describe is NOTHING to do with persistent feeders (other than feeders not being reevaluated on server restart maybe) and just to do with the lookup pointer to the fed cells changing over time which requires a CubeProcessFeeders function via scheduled TI.
This is a general model management issue. (Yes it gets "surfaced" more readily if you have regular server reboots and using persistent feeders but it isn't CAUSED by persistent feeders but by your data changing.)
This is a general model management issue. (Yes it gets "surfaced" more readily if you have regular server reboots and using persistent feeders but it isn't CAUSED by persistent feeders but by your data changing.)
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
-
- Posts: 110
- Joined: Sat Nov 06, 2010 10:10 am
- OLAP Product: Cognos TM1
- Version: 10.2.2
- Excel Version: Excel 2013
Re: To use or not to use persistent feeders?
Understood, makes sense. Unfortunatelly I didn't think of it in this way. :-/declanr wrote:So if you use conditionals you will ALWAYS need to factor in the fact you will need to fire the feeders sometimes yourself... whether its a well planned TI that is actioned from certain other changes etc or just a manual kick now and again... it needs to be done.
But this opens a new question... If I were a TM1 end user / planner I would like to see the results "online" and not to wait for feeders re-processing.
Or do you mean creating a TI process for feeders re-calc and schedule it let's say for every 5 mins?
-
- MVP
- Posts: 1822
- Joined: Mon Dec 05, 2011 11:51 am
- OLAP Product: Cognos TM1
- Version: PA2.0 and most of the old ones
- Excel Version: All of em
- Location: Manchester, United Kingdom
- Contact:
Re: To use or not to use persistent feeders?
That would be overkill; if you needed to process a number of cubes the system would end up being locked more often than not.vladino wrote: Or do you mean creating a TI process for feeders re-calc and schedule it let's say for every 5 mins?
You just need to think about every rule/feeder you put in place and how they correspond with what users will be doing. The feeder I suggested as an example would mean that when the user changes "Value" in the cube; with reevaluate feeders set in the config it will do its own refire but when the attribute is updated a process needs to fire the cube which the rule is in.
This means I would create an admin screen for changing that attribute and an action button on the same page to process the feeders... but have that button move the newly entered attributes from an entry cell to the attribute first; so that it is impossible for them to update the attribute without running it.
And obviously if a process reloaded those attributes from a source system every night; that is a time at which you need to process the feeders.
It seems like a lot of thinking and work to do in one go but when you have it in place; updating it for any rule change you do later is simple.
It does mean that you need to think about all possible repurcussions of every calculatiom and how users and/or processes interact with various bits of data.
Declan Rodger
-
- Posts: 2
- Joined: Wed Dec 06, 2017 9:49 am
- OLAP Product: MS SQL Stackm, IBM Tm1
- Version: 10.2,10.3,11 MSSQL2008,12,16
- Excel Version: O365
Re: To use or not to use persistent feeders?
Hi Everybody,
I have a quick connecting question to the topic.
Does anybody experienced when you save a rule for cube with persistent feeder every cube is refeedered and every single feeder file is regenerated?
Could it be because of chain feeders create dependencies and the TM1 just simply drop by the chain all feeder file and regenerate it?
We have a complex scenario modelling tool at a customer where the longest rule based calculation chain across 17 cube, and because we have several conditional feeders sometimes the source cube rule is dropped and reattached after a metadata change which would require re triggering feeders.
Our customer is reported significant performance decrease, when I checked I saw the rule calculation time is not changed significantly but in every rule drop case the server simply rewrite every feeder file which is create a significant overhead. (We have 30 GB of feeder in total and I see the disk is writing quite sow this files)
I also find out the feeder file someway contains feeders for not rule calculated cells also. For example in every cube we snapshot version to not rule calculated reporting version elements in the version dimension. When I take out the rule from the biggest cube that cube still generated a feeder file without any connecting rule. the cub file is showing 6GB raw data and generated a 1,2 GB feeder file.
Summary up because the system working for 2 years we have dozens of stored version, because of the necessary rule detach and reattach in production mode the feeder file recreations create significant slow in the performance of a few function of the system.
What should we do? I cannot decrease further the conditional feeders because then I would lost significant functionality in the model such as flexible use case management etc.
I have 3 idea:
- Replace the old SATA hard drives to SSD drives?
- switch off persistent feeders, I will lost the quick restart time but i will spare every time when I drop the rules the feeder file saving time to the disk.
- Archive the model and delete the saved versions from the cube ( the problem we will loose historical comparison functions)
Could you please verify or give another ideas?
Many thanks,
Zsolt
I have a quick connecting question to the topic.
Does anybody experienced when you save a rule for cube with persistent feeder every cube is refeedered and every single feeder file is regenerated?
Could it be because of chain feeders create dependencies and the TM1 just simply drop by the chain all feeder file and regenerate it?
We have a complex scenario modelling tool at a customer where the longest rule based calculation chain across 17 cube, and because we have several conditional feeders sometimes the source cube rule is dropped and reattached after a metadata change which would require re triggering feeders.
Our customer is reported significant performance decrease, when I checked I saw the rule calculation time is not changed significantly but in every rule drop case the server simply rewrite every feeder file which is create a significant overhead. (We have 30 GB of feeder in total and I see the disk is writing quite sow this files)
I also find out the feeder file someway contains feeders for not rule calculated cells also. For example in every cube we snapshot version to not rule calculated reporting version elements in the version dimension. When I take out the rule from the biggest cube that cube still generated a feeder file without any connecting rule. the cub file is showing 6GB raw data and generated a 1,2 GB feeder file.
Summary up because the system working for 2 years we have dozens of stored version, because of the necessary rule detach and reattach in production mode the feeder file recreations create significant slow in the performance of a few function of the system.
What should we do? I cannot decrease further the conditional feeders because then I would lost significant functionality in the model such as flexible use case management etc.
I have 3 idea:
- Replace the old SATA hard drives to SSD drives?
- switch off persistent feeders, I will lost the quick restart time but i will spare every time when I drop the rules the feeder file saving time to the disk.
- Archive the model and delete the saved versions from the cube ( the problem we will loose historical comparison functions)
Could you please verify or give another ideas?
Many thanks,
Zsolt
- Steve Rowe
- Site Admin
- Posts: 2444
- Joined: Wed May 14, 2008 4:25 pm
- OLAP Product: TM1
- Version: TM1 v6,v7,v8,v9,v10,v11+PAW
- Excel Version: Nearly all of them
Re: To use or not to use persistent feeders?
IMO this indicates a bug or a failure in your test, can you detail how you performed the test? If you just deleted the .RUX and restarted did you delete the associated .BLB file as well?I also find out the feeder file someway contains feeders for not rule calculated cells also. For example in every cube we snapshot version to not rule calculated reporting version elements in the version dimension. When I take out the rule from the biggest cube that cube still generated a feeder file without any connecting rule. the cub file is showing 6GB raw data and generated a 1,2 GB feeder file.
You should check your feeders as well and ensure that the static versions are excluded from the scope.
An option you don't mention is to consider if a TI job could replace some or all of your rules. Yes you will lose the dynamic real time calcs but you have already lost this anyway since you are having to drop the rules and recompile to deal with metadata changes and feeder conditionality. You might find that a TI job at the base of your calculation could remove all the conditionality from the feeders and the problem goes away.
Technical Director
www.infocat.co.uk
www.infocat.co.uk