TM1 Forum

Hi guys,

We have one instance of Tm1 (v 10.1.1) and there is often a problem when saving a rule for the largest cube (a fixed cost cube which integrates with quite a few other modules). When I look at the log it doesn't give us any errors to go on. Trying to kill the process using TM1top.exe or the Operations console fails (the process remains). Trying to stop the service fails at "stopping".... my only way out of this is to kill the process in the windows task explorer which I don't like doing as it can corrupt the database so my question is:

Other cube rules save OK and quickly.
The hardware is quite good: 132GB RAM, 16 cores for CPU, sitting in SCSI discs in a fibre channel SAN and gigabit Ethernet links so this is OK.

Where else can I look to see what might be holding up this process of saving a rule file (taking over 45 minutes for a cube file of 98MB) and what options would you suggest to 'restart' the TM1 instance in whatever way you think is the least destructive?
thanks.

I doubt that there is a "problem" as such, its most likely that the rule is just feeding a lot of calculations.
Are there significant feeders in the rule? Or have you not turned skipcheck on?

It might be possible that some of your rules aren't completely efficient or maybe even some could be replaced with TI etc, that would be the first place I would look.

And yes it is worth noting that once you start saving a rule, TM1Top can't kill the process you just have to wait it out or stop the service (or have the service fall over itself as a result of the rule save.)

Could you post the contents of the rule file so that people can see if their is anything particularly suspect?

Thanks Declan,

Yes skipcheck is turned on. Funny thing is this same cube in another (identical) instance in a QA environment saved in about 15 minutes but in Dev it failed after 45 mins (that's when I pulled the pin and killed the process). Your suggestions are appreciated but due to a confidentiality clause I'm not able to post the rule as it's the clients intellectual property. Would be great to get the community's feedback on that but in this instance I'm not able give this info out.
thanks for your feedback though Declan.

JamiseBondi wrote:Funny thing is this same cube in another (identical) instance in a QA environment saved in about 15 minutes but in Dev it failed after 45 mins (that's when I pulled the pin and killed the process).

Did the rule save actually fail or was it still processing while you killed it?

When you say that the 2 environments are identical, do you just mean that the structures are identical or do they also have the exact same data in the cells?
Obviously an empty cell doesn't trigger feeders.

My record for saving a rule is 7 hours! I managed to get this down eventually by optimizing some rules, but at the peak of development, it was an overnight proposition.

Some feeders (especially conditional) are just complicated and process slowly.

Is your dev environment a less powerful server, or a VM? That can certainly make a different to the rule saving time, as it triggers off a lot of processing and memory writes. Perhaps you should try waiting overnight and see if the rule does save successfully.

If it does, it might just be a matter of optimizing as much as you can.

To further Declan's point rule save time isn't just a factor of the contents of the rule file or the server hardware, by far the biggest component in saving a rule is feeder evaluation and processing time which is driven by the DATA in the cube. If cube data is different then it is quite normal for rule save time to be very different also.