System Lockup on TI load

[highlnder8]

I'm on version 9.4.1 and we are having an issue where the entire system is unavailable when a TI process is running. Users can't log in, reports just feeze mid-refresh and everybody waits until the process is completed.

I'm just wondering if this is due to something in our install, or if this is a "feature" for 9.4.1. And if it's a feature, is there a way to work around it? If it's an intall issue, where should we look to make a fix?

Thanks all!!

[rkaif]

What is your server Hardware specs? Do you have multi-processors/cores?

And also check your TM1S.CFG file if it has the MaximumCubeLoadThreads switch added to it. Its value should be Number of available processors -1

[laenen]

There could be several reasons. For example, EnableBulkLoadMode in your TI process locks out users.

If you haven't done so already, I think you might want to put logging on TM1top, tm1 processes, tm1 admin and tm1 server.

[jstrygner]

And also check your TM1S.CFG file if it has the MaximumCubeLoadThreads switch added to it.

I think this one has nothing to do with the TI blocking the server.
IMHO it is used only while model is being loaded to RAM during server startup.

[highlnder8]

And also check your TM1S.CFG file if it has the MaximumCubeLoadThreads switch added to it.

I think this one has nothing to do with the TI blocking the server.
IMHO it is used only while model is being loaded to RAM during server startup.

Agreed. We have this in our TM1S.CFG file set to 7, since we are running 2 Quad-core processors. It speeds up the load at startup, but is doing NOTHING for us in terms of our overall performance. Everything seems to be running through only one processor, when I looked at the system performance specs. Is this normal?

Also, we are only using 25 of the 64GB of RAM on our server.

Finally, we do not have BulkLoad enabled for any of our processes, in an effort to try to accomodate multiple users, but I'm wondering if we should since they are all effectively locked out anyway.

[tomok]

Agreed. We have this in our TM1S.CFG file set to 7, since we are running 2 Quad-core processors. It speeds up the load at startup, but is doing NOTHING for us in terms of our overall performance. Everything seems to be running through only one processor, when I looked at the system performance specs. Is this normal?

Yes, it is normal. The MaximumCubeLoadThreads parameter only controls how many processors are used upon the TM1 service startup. After that the use of the processors should be multi-threaded, meaning each client get's a processor assigned to their query until it is finished, then it is released back to the pool. However, regardless of what IBM says to the contrary, it has been my observation that TI processes are not multi-threaded and while one is running, the server becomes unresponsive to the clients. If I have TI processes running during normal working hours, meaning clients on the prowl for queries, I make sure they are of the variety that run in less then a minute. Any that take longer than that should be run after hours.

[jstrygner]

it has been my observation that TI processes are not multi-threaded and while one is running, the server becomes unresponsive to the clients.

From my observation:
- one TI process is always single-threaded,
- if second TI process gets run (but you need to do it from a different client instance) it goes paralelly on a different core (if such a core is available),
- sometimes one process needs to wait for another if they write to the same cube, so you don't save time here, although you use two cores,
- the same concerns users - they need to wait for a cube data if TI writes to such a cube, but if TI writes to a different cube that user is using (s)he should not need to wait for data because of TI running (of course sometimes user uses a cube that has some rules based on cube where TI writes, in such a case user also needs to wait till TI finishes its job).

HTH (and Hope I Am Not Wrong)

[Gregor Koch]

Hi
I can confirm jstrygner's observation for version 9.4.1, and I think they are pretty much spot on. Something I would add to the list is that meta data changes and usage of public dynamic subsets (this does not complete the list) also can lock users.
Also, because you mentioned it, I have just tested to connect to a server that is running a process and that works just fine as well.

So it really depends on what your process is doing and the dependencies of your cubes. A more detailed description of your TI Process would help there.

Cheers