To use or not to use persistent feeders?

vladino
Posts: 72
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?

Post by vladino » Thu Feb 02, 2017 11:06 pm

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

mvaspal
Community Contributor
Posts: 307
Joined: Wed Nov 03, 2010 9:16 pm
OLAP Product: tm1
Version: 9 5 1 - 10 2 2 - 10.3 PA
Excel Version: From 2007 to 2013
Location: Earth

Re: To use or not to use persistent feeders?

Post by mvaspal » Fri Feb 03, 2017 8:26 am

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

TrevorGoss
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?

Post by TrevorGoss » Fri Feb 03, 2017 9:09 am

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
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.

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.

AnonimusMax
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?

Post by AnonimusMax » Fri Feb 03, 2017 9:31 am

Can PersistentFeeders=T cause a TM1 Crash?

yes from Cognos TM1 version 10.1.1 the PersistentFeeders were turned to T

TrevorGoss
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?

Post by TrevorGoss » Fri Feb 03, 2017 10:31 am

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.

User avatar
Steve Rowe
Site Admin
Posts: 1689
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: 10.2.2., PAW
Excel Version: Nearly all of them

Re: To use or not to use persistent feeders?

Post by Steve Rowe » Fri Feb 03, 2017 3:25 pm

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.

User avatar
tomok
MVP
Posts: 2357
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?

Post by tomok » Fri Feb 03, 2017 5:00 pm

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.
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.
Tom O'Kelley - Manager Finance Systems
American Tower
http://www.onlinecourtreservations.com/

lotsaram
MVP
Posts: 3010
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TM1, CX
Version: TM1 10.2.2 PA 2.0x
Excel Version: 2010 2013 365
Location: Switzerland

Re: To use or not to use persistent feeders?

Post by lotsaram » Fri Feb 03, 2017 5:15 pm

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.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.

Paul Segal
Community Contributor
Posts: 229
Joined: Mon May 12, 2008 8:11 am
OLAP Product: TM1
Version: 10.2.2
Excel Version: 2010

Re: To use or not to use persistent feeders?

Post by Paul Segal » Fri Feb 03, 2017 5:21 pm

+1 for Tom. I have people using the system around the clock, and minimising downtime is key.
Paul

User avatar
Steve Rowe
Site Admin
Posts: 1689
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: 10.2.2., PAW
Excel Version: Nearly all of them

Re: To use or not to use persistent feeders?

Post by Steve Rowe » Fri Feb 03, 2017 5:43 pm

I feel the need to respond! :D

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?

User avatar
Alan Kirk
Site Admin
Posts: 5734
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: 9.5.2 64 bit moving to 10.2.2
Excel Version: 2010
Location: Sydney, Australia
Contact:

Re: To use or not to use persistent feeders?

Post by Alan Kirk » Fri Feb 03, 2017 7:52 pm

I see Steve's point but admit that I feel inclined toward the Lotsaram / Tomok view here.

But just one small thing:
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 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.

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.

User avatar
Alan Kirk
Site Admin
Posts: 5734
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: 9.5.2 64 bit moving to 10.2.2
Excel Version: 2010
Location: Sydney, Australia
Contact:

Re: To use or not to use persistent feeders?

Post by Alan Kirk » Fri Feb 03, 2017 9:29 pm

Steve Rowe wrote:What measures do you put place to delete the .feeder files to prevent over feeding in the longer term?
Ooops, I forgot to respond to this, though I meant to.

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.

TrevorGoss
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?

Post by TrevorGoss » Mon Feb 06, 2017 8:45 am

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:
Using the Persistent Feeders feature will increase your system size on disk only. Memory size is not affected by the use of this parameter.
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:
With PersistentFeeders = load time 70 seconds RAM usage = 6,993,380 K

Without PersistentFeeders = load time 861 seconds RAM usage = 13,569,300 K
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.

So the IBM statement may still stand true, but there is at least a correlation between .feeder files usage and memory.

Trevor.

vladino
Posts: 72
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?

Post by vladino » Mon Feb 06, 2017 9:47 am

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

declanr
MVP
Posts: 1546
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?

Post by declanr » Mon Feb 06, 2017 10:11 am

Conditional feeders could give you wrong results regardless of whether you use persistent feeders or not.

E.g.

Code: Select all

['VALUE']=>Db('Cube',Attrs('DimA',!DimA,'Account'), 'Measure');
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.

lotsaram
MVP
Posts: 3010
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TM1, CX
Version: TM1 10.2.2 PA 2.0x
Excel Version: 2010 2013 365
Location: Switzerland

Re: To use or not to use persistent feeders?

Post by lotsaram » Mon Feb 06, 2017 12:07 pm

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.)
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.

vladino
Posts: 72
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?

Post by vladino » Mon Feb 06, 2017 12:23 pm

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.
Understood, makes sense. Unfortunatelly I didn't think of it in this way. :-/

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?

declanr
MVP
Posts: 1546
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?

Post by declanr » Mon Feb 06, 2017 8:03 pm

vladino wrote: Or do you mean creating a TI process for feeders re-calc and schedule it let's say for every 5 mins?
That would be overkill; if you needed to process a number of cubes the system would end up being locked more often than not.

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.

zsoltm
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?

Post by zsoltm » Wed Dec 06, 2017 12:08 pm

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

User avatar
Steve Rowe
Site Admin
Posts: 1689
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: 10.2.2., PAW
Excel Version: Nearly all of them

Re: To use or not to use persistent feeders?

Post by Steve Rowe » Wed Dec 06, 2017 2:42 pm

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.
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?

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.

Post Reply