TM1 Forum

All,

I was shuffling through one of my data directories today and noticed a load of .FEEDER files; which I though a bit strange as I almost never use PersistentFeeders (certainly not while developing - as is the case on this instance.)

Had a look in the CFG file and it had a line:
UsePersistentFeeders = F

Which I know is stupid since the actual parameter should be PersistentFeeders = F


Anyhows I reckon that in the old versions 9.5.x etc it used to assume Persistent Feeders were turned off unless you explicitly state otherwise.

Version 10.1.1 I found:

No mention OR UsePersistentFeeders = F - Resulted in .FEEDER files being created

PersistentFeeders = F - No Feeder files created




So to the question/s:

Has it always been the case that persistentfeeders is turned on when not stated in the CFG file? (I thought not)
Can anyone else confirm this is happening to them in 10.1 or 10.1.1?


Cheers,
Declan

Well no more stupid than PersistingOfFeeders=F as was claimed in the documentation when the feature was first released.

In 9.5.1.x and 9.5.2.x unless PersistentFeeders=T then the default behavior is the old way and no .feeder files are created. If this has flipped in 10.1.x then I wasn't aware of it. I haven't yet installed 10.1.1 but just tested on 10.1 FP1 (not to be confused) and the default behavior is the same, i.e. if PersistentFeeders=T is omitted then no .feeder files are generated.

What has changed is that in the 10.1.x default tm1.cfg files that are installed with the sample databases the default setting is now true.
E.g.
#PersistentFeeders
# Turn on Persistent Feeders to make TM1 models load faster
# Type: Optional, Static
PersistentFeeders=T

So possibly you copied the config file from a sample and hence the change?

Overall the sample tm1s.cfg files are I just noticed much more detailed and comprehensive in 10.1 than they have been in the past. This at least is welcome and overdue.

Below is my full CFG file and this DOES create .FEEDER Files:

[TM1S]
ServerLogging=F
SecurityPackageName=Kerberos
IntegratedSecurityMode=1
UseSSL=T
ServerName=ds
DataBaseDirectory=C:\TM1Servers\ds\data
LoggingDirectory=C:\TM1Servers\ds\logs
AdminHost=
PortNumber=12275
ClientMessagePortNumber=
Language=ENG
GroupsCreationLimit=500
SaveTime=
DownTime=
ProgressMessage=True
DisableSandboxing=F
AllowSeparateNandCRules=T
AdvancedRulesEditor = T
UsePersistentFeeders=F
MaximumViewSize=200
AuditLogOn=F
AuditLogMaxFileSize=100 MB
AuditLogUpdateInterval=60
DefaultMeasuresDimension=T
ServerCAMURI=http://localhost:9510/p2pd/servlet/dispatch
ClientCAMURI=http://localhost/cognos8/cgi-bin/cognosisapi.dll
CAMPortalVariableFile= portal\variables_TM1.xml
#ForceReevaluationOfFeedersForFedCellsOnDataChange=T
DistributedPlanningOutputDir=tunit

Think I've spotted it

UsePersistentFeeders=F

So yes, it does appear that the default it True. Bad idea.

David Usherwood wrote:Think I've spotted it

UsePersistentFeeders=F

So yes, it does appear that the default it True. Bad idea.

Yeah as I mentioned in my OP I realised straight away that it was the wrong parameter and when I changed it to "PersistentFeeders = F" instead of "UsePersistentFeeders = F" everything worked as expected. It was just more the fact of - Why on earth have they made this standard set at True in 10.1.1 but not in previous versions?

I was sort of hoping I was just being blind and there was some other config parameter that I hadn't noticed which was switching it on!

Hopefully since it now appears to be set as standard I hope that means that IBM have actually made them work properly without you manually having to delete the files now and again... I somehow doubt it though...

I can confirm that the behaviour does seem to have changed.

Just started a server that I last started under 9.5.2, no mention of anything to do with PersistentFeeders in the tm1s.cfg and I now have lots of .feeder files.

Thought I would check the 10.1.1 doco just in case IBM had just forgotten to publicise the change:

IBM doco wrote:To improve reload time of cubes with feeders, set the PersistentFeeders
configuration parameter to true (T) to store the calculated feeders to a .feeders file.
...
When this parameter is set to T and the server...

Both of which suggest to me that the default should still be F.

But looking at the log files shows:

tm1server.log wrote: 7556 [] INFO 2012-09-25 01:34:24.036 TM1.Server TM1 Build Number: 10.1.10000.26473
7556 [] INFO 2012-09-25 01:34:24.057 TM1.Server Using Persistent Feeders

As already noted, forcing PersistentFeeders=F in the tm1s.cfg does act as expected.

Hi there,

I had recently setup Cognos Express 10.1 for migrating our 9.0. I heard Persistent Feeder is a new feature which give faster startup time. However, I noted my started up time unchanged, and I do not see any .FEEDER file created in my data directory. Is there anything I missed out? Must I explicitly put PersistentFeeder=T in the cfg file?

Please give me some advise.

Thank you.

Beek

beek wrote:Must I explicitly put PersistentFeeder=T in the cfg file?
Beek

From my experience for 10.1 the answer is yes

thanks

ET

Thanks ET, you are right. I just did and it works. I noticed some people here choose not to on this setting. Can I know why ? Coz from what I see, since it can improve the startup time, why not ?

I noticed some people here choose not to on this setting. Can I know why ? Coz from what I see, since it can improve the startup time, why not ?

I guess it comes down to the complexity of the feeders. Official IBM guidelines states:

Any installation with server load times of over 5 minutes can probably improve their performance using this parameter..
For installations with many complex feeder calculations persisting feeders and then re-loading them at server startup will improve performance. For simple feeders, the time taken to read feeders from disk may exceed the time to re-calculate the feeders but most installations will benefit

So I guess here is your answer.

But you have to be careful when developing model with PF's, because feeders are never deleted from the memory and changes to the rules/feeers will only add extra changes to the .feeder files, hence why there is an occasional need to call DeleteAllPersistentFeeders function and restart the server...

Persistent Feeders have problems with multiple DB folders defined in cfg. That's a known issue starting with 9.5.x through 10.1.1, the same is valid for a bunch of other TM1 functions (TI's, audit logs etc. either don't work or come back with weird errors in message log).
I have seen at least a couple of them on the fix list of 10.2, but not retestet yet.

Gabor wrote:Persistent Feeders have problems with multiple DB folders defined in cfg. That's a known issue starting with 9.5.x through 10.1.1, the same is valid for a bunch of other TM1 functions (TI's, audit logs etc. either don't work or come back with weird errors in message log).
I have seen at least a couple of them on the fix list of 10.2, but not retestet yet.

And that too

Thanks ET & Gabor. For my environment, in CX9.0 it is taking 5hours to start up the environment (some of the cube is very heavy, it took 2hrs to fully loaded the feeder). and we only have 1 DB directory, hence, I think for our case, it might be good to use the PersistentFeeder?
Anyway, I had not really tried out using PersistentFeeder to load the environment yet, hence can't say how much it help in this. I will try out later in the evening, and update the new startup time here.

1st startup will take longer, subsequent starts are much faster then. I saw 50 min to go up to 75 min first and then down to 3 min.
Another idea, feeding is not equal to feeding. Apart from the feeder volume in source cube, it also depends on the destination cube and how far dim order is optimized there.
You may try to use the manual dim order optimization feature to try minimizing the amount of RAM after feeding. If you can get it down by lets say 80%, your feeder time will go down by a similar percentage.

Yes, you are right. Only the subsequent startup will be faster. For my case, from 5hours, it cut down to 30mins, and the data directory, the size increased by 3~4 times of the original size.