TM1 Forum

Hi All,

We're running 10.2.2 FP4. Recently I noticed that if the server crashes, the start up time can take hours. Even with a tm1s.log file of only 250kb with 1200+ records contained

Looking online, I found this http://www-01.ibm.com/support/docview.w ... wg21654137 but it depends upon the server coming up.

Has anyone ever encountered this? Any suggestions about speeding the process up would be greatly appreciated.

Thanks

keeponcubing wrote:Hi All,

We're running 10.2.2 FP4. Recently I noticed that if the server crashes, the start up time can take hours. Even with a tm1s.log file of only 250kb with 1200+ records contained

Looking online, I found this http://www-01.ibm.com/support/docview.w ... wg21654137 but it depends upon the server coming up.

Has anyone ever encountered this? Any suggestions about speeding the process up would be greatly appreciated.

Thanks

Hello,

do you use persistent feeders? Perhaps the .feeder files became invalidated during the crash, which means the server must recalculate the feeders upon start up. If the .feeder files are older than the corresponding .cub file, they will become invalided and it could be the case that the crash occurred before writing to disk, to the .cub file.

This IBM link explains more: http://www.ibm.com/support/knowledgecen ... eeder.html

How large is the model when it is fully loaded?

Would be nice to see the last updated lines of your message log. Where exactly are they 'stuck'?

Hi All,

Thanks for all of your responses and sorry for taking a while to get back, been fighting many fires.

@Trevorgoss, Yes we do use persistent feeders but at that point they had all loaded without any errors being generated in the tm1server.log file. They weren't being recreated during the start up process

@bakkone At the time, our model was about 63GB which isn't that overly large

@Karthik1710 the last line would be "TM1.Cube Done loading body for cube }_intDPD_TempCube__BAK_***** *******Link" which would the last cube to be loaded.

We have made some changes to reduce the application size to a more manageable 33GB and removed any old tm1s*date.log files from the log directory. What we did notice was that if the service simply restarted after a crash, it would just hang at the point where the }ApplicationEntries file was being recreated and would fail to restart. if we restarted the host, it would all come up without any issues in the expected time frame. The other weird thing is that we have other applications on the same hosts, granted with less data in them, but none ever showed this kind of behaviour.

One other thing, during the start of a tm1 application does the tm1s.log file get locked? During this entire time, you can open the tm1s.log file without getting the usual error that it's locked by another process.

So we have changed the response of the computer to a crash of that service to restart the host, a bit extreme granted, but it seems to fix the problem at the moment. As to the reason for the crashes, that's with IBM so who know if we will ever find out the reason.