9.1 SP3 Load and Process Issues

[jim wood]

Guys,

For some reason since we have upgraded to 9.1 SP3 the load time has been reduced by over 3 hours from 9 to 5. (Don't ask) This isn't an issue really but is related....

We run a scheduled data load at the weekend. This load used to take around 6 hours and is now taking 13!

I think that the new load process in the new version is not loading all feeders properly. (I think this is the case the weekend schedule moves data between cubes via cube views.)

Has anybody had any experiences like this?

(I have also posted this on the old Applix forum)

[mikegrain]

Hi Jim

Has a MaximumCubeLoadThreads parameter appeared in your TM1S.CFG file?

This is new functionality to speed up server start times by multi-threading the load processes and feeder evaluation (no more looking at a quad processor box ticking along at a mere 25%). However, there are a couple of things to bear in mind:

It works best if the value is set to 1 less than the number of processors/cores on your server and it can really trip itself up if you have conditional feeders in any of your cubes.

If you do have MaximumCubeLoadThreads in your TM1S.CFG file I would suggest commenting it out before your next server restart and seeing if it makes a difference.

I don't really have any suggestions as to why the data load is taking so much longer but it could be related to the issue above or it might be a consequence of the 9.1SP3 locking module...

[jim wood]

Hi Mike,

As far as I can see we don't have the multithreading switched on. (We ugraded from 8.4.5 which contains the same functionality.)

Here is copy of our CFG:

[TM1S]
RuleTraceOn=
ODBCCatalogName=
ODBCDateSource=
ODBCUserName=
ODBCPassword=
ReadTM1WriteODBC=
AllowSeparateNandCRules=T
IdleConnectionTimeOut=3600
MaximumViewSize=50
DisableWorksheetView=T
Minimumclientversion=8.0.0
DownTime=
SaveTime=
Language=ENG
NetworkFrame=
Protocol=tcp
PortNumber=12348
AdminHost=tm1prod
DataBaseDirectory="/prod/tgdata/TM1Planning"
ServerName=TM1Planning
IntegratedSecurityMode=1
SecurityPackageName=Kerberos
ServerLogging=F
RunningInBackground=T
UseSSL=F

The only other thing that could come in to play is that we have upgraded the version of Solaris from 8 to 10 (The reason for the TM1 upgrade.),

Jim.

[Neil Watson]

Jim,

We've found a simialr increase in load time at one of our clients when we went to 9.1, it looks like the new locking model is the cause as it's the only thing to change.
One thought / suggestion is that the load was causing the feeders to fire more frequently than before.

To 'fix' our load times there has been a two pronged approach,
1. Tighten up the feeders (always a good idea anyway)
2. Use Batch update which commits all the data at the end of a TI and not each and every item.

HTH Good Luck
Neil

[jim wood]

Is there anyway of amending the locking model?

Jim.

[mikegrain]

According to the "What's New in Applix 9.1" document (it's a hyperlink from within the 9.1SP3 release notes)

Enhanced Locking Mechanism
1. Encapsulation of locking processes to enhance predictability and stability during
concurrent write activity.
2. More granular Object-Level Write Locks to improve user concurrency performance
2.1. Updates will not impact unrelated TM1 objects
3. TI reads/writes managed like any other API call (vs. current Write lock default…
even for reads). No need to control lock status during TI (i.e. LockOn/Off are no
longer relevant)

The key point to note here is 2.1. Updates will not impact unrelated TM1 objects.

In most situations this is great, users can continue to input data whilst a TI process is running, users in a large system are not constantly locking each other out as they try and type in their numbers at month end.

But, this raises one very important question: How does it know what to lock and what to release?

If the locking model is smart enough to know what areas of the model are impacted by an update, why do we need to tell the calculation model exactly the same thing by writing feeders? Could it be that the locking model is only smart because it is using those same feeders?

The downsides to the new locking model are that the model will now need a bigger RAM overhead to hold all those granular locks and TI processes can take a lot longer run because the locking model now needs to manage a lot of flags to allow users to keep working whilst the process runs.

As an example we have a client that recently migrated from 9.0 to 9.1 and, like Jim, they experienced significant slow downs in their data load processes. By tuning the feeders (which were fairly general but worked just fine under 9.0) we brought the load times down 10 minutes to a few seconds. We can only surmise that this is because the locking model is now only setting thousands of flags and not millions and it is setting those flags based on the feeder flags.

So it seems that very tightly written feeders are now more important than ever as there does not appear to be any way to turn off the new locking model short of removing the rules prior to a major load process and reinstating them afterwards. We have found this to be significantly quicker than leaving the rules in place - even when you factor in the additional time for saving them at the end.

Apologies for the long rambling post, whilst it's mostly speculation on my part it does seem to make sense.

[jim wood]

While I like the idea of the new locking function, if what you say is correct I don't like it's impact on scheduled loads. Surely it would make sense to have some kind of override that can triggered from within TI? Maybe add a process to the start of shcedule that switches it off and and one at the end that switches it back on?

After all most scheduled load processes happen over night or out of hours when nobody accesses the data anyway.

Just a thought,

Jim.

PS. We have overfed is ome areas as varaiable feeders were causing data retrieval efficency issues. It sounds like more than ever that it is the frying pan or the fire!