x64 tm1 service teminated unexpectedly!!

[shockwave]

HI All,

Our server went down unexpectidly and wondered if it was a cooincent that while running a virus scan on my pc while being remotedly logged into the windows box the virus scanner rebooted my pc without warning and closed down the window. At the same time or around abouts the same time the server tm1 service terminated. Is this just a coincendent or can this sort of thing actually happen??

Thanks again

Shock

[Alan Kirk]

Our server went down unexpectidly and wondered if it was a cooincent that while running a virus scan on my pc while being remotedly logged into the windows box the virus scanner rebooted my pc without warning and closed down the window. At the same time or around abouts the same time the server tm1 service terminated. Is this just a coincendent or can this sort of thing actually happen??

I can't see a crash on your PC triggering a termination of the TM1 service on a remote server.

However... it may be possible that the virus scanning schedule on the server is similar to your own, and that it was the virus scan that triggered the shut-down. The usual cause of this is when the virus scanner grabs hold of a file that TM1 needs to write to, such as the tm1s.log file. If TM1 can't write to that file, it will fall on its own sword.

I'd be taking a look at the server's logs to see whether you can find a reason for the service's termination. If it is that the service was unable to write to a file, you'll need to get such files excluded from the scan.

[shockwave]

Thanks Alan. The only thing I can see in

computermanagement > system tools > Event Viewer > system

is a description "The TM1 server x64 / tm1 production service terminated unexpectedly"

Will the TM1 log files tell me anything. Is there anyway a user when reading a cube can somehow jam
the service and cause the server to hang and then crash. Is there some document that indicates when
tm1 server crashes can happen when say x event occurs?

Thanks again for your helpful advice.

Regards

Shock

[Alan Kirk]

Thanks Alan. The only thing I can see in

computermanagement > system tools > Event Viewer > system

is a description "The TM1 server x64 / tm1 production service terminated unexpectedly"

Will the TM1 log files tell me anything. Is there anyway a user when reading a cube can somehow jam
the service and cause the server to hang and then crash. Is there some document that indicates when
tm1 server crashes can happen when say x event occurs?

Yup, it was actually the TM1 service's logs rather than the Windows server's logs that I was referring to in this case. In 9.4, for example, in addition to the tm1s.log (which is the transaction log) you also have tm1server.log. The names of the log files can vary according to version, but I'd take a look at all of the ones that are available (aside from the transaction log, which is, after all, just the transaction log). The amount of information will vary as well, though if the server DID fall over as a result of being unable to write to the transaction log (or some other file) IIRC you should see that recorded in there. That was a problem that we had before we had IT configure the then-virus scanner to exclude the log files folder, and I'm pretty certain that the error was written into the log whenever the application terminated as a result.

Is there anyway a user when reading a cube can somehow jam
the service and cause the server to hang and then crash. Is there some document that indicates when
tm1 server crashes can happen when say x event occurs?

I'm not sure how likely that is since you're on 64 bit, though of course no server has an infinite amount of memory. However crashes of that type are normally the domain of us 32 bitters, and yes, it has been known to happen. Not quite the same thing, but when we were trying to re-order a cube in a test environment (on 9.4) I got this error in the tm1server.log:

Code: Select all

9732   ERROR   2009-05-11 05:31:56.040   TM1.Server.Memory   CommonAlloc - alloc (size = 131072) failed: Not enough storage is available to process this command.

9732   WARN   2009-05-11 05:31:56.553   TM1.Server.Memory   CommonAlloc() outOfMemory Exception <<< MEMORY_ALMOST_FATAL_LEVEL >>> - threadID "9732" -  apifunc# "202"
9732   ERROR   2009-05-11 05:32:10.672   TM1.API   Request denied.  Insufficient memory.

Of course that doesn't tell you who or what... (in this case the log just confirmed what we already knew), but if it gets to be a recurring problem I'd be looking at using TM1 Top (writing out to a log file so you don't have to be monitoring it constantly) to see whether you can pick up on a pattern.

[jim wood]

In th event viewer details does it mention anything like "Unable to access memory flag" or resource? It may also say something like acess to blah...blah... denied. Messages lke this would tend to backup Alans theory. It's also worth checking to see if anything else was running on the server that could have caused a resource conflict,

Jim.

[RLReyes]

We've encountered this issue of the TM1 service terminated unexpectedly 3 times within the last 24 hours. We've ruled out antivirus & backup. No log entry on the TM1server.log file. It also didn't create a DMP/TMP file(s).

Our x64 tm1 server does have 32GB of ram using Server2003 R2.

Any ideas...

Thanks

[laenen]

1. Go to the data directory and open up your TM1s-log.properties files and change INFO to DEBUG and save the file
2. Download ADPlus from Microsoft and run it in the background to capture the dump info
3. If you haven't done it -- Turn on Dr Watson to capture crash info

[RLReyes]

Opened a support ticket with IBM. They had me add additional logging in the tm1s-log.properties since no dump files were present...
log4j.logger.TM1.Commit=DEBUG
log4j.logger.TM1.API=DEBUG
log4j.logger.TM1.API.Parameters=INFO
log4j.logger.TM1.Chore=DEBUG
log4j.logger.TM1.Process=DEBUG
log4j.logger.TM1.Process.Functions.Parameters=INFO

Having these additional commands does capture a lot more information. The server log does get large but you can control the size in the tm1s-log.properties.