Tm1 cube outside data folder

[ravi]

Hi All,

Hi All,

We have one of the TM1 cube about 33gb and this is one big cube in entire tm1 model and covers 50% of tm1 memory.
We noticed this cube is not used by our user any more.

We though to move this cube out of data folder and will replace back to data folder when requirement comes by users.

Could you please help/advise, what is would be the best stratergy to achieve this.
Regards,
Ravi

[jim wood]

Take out out of your current service as you have already mentioned. Then move it to seperate instance of its own that you keep down unless asked for. Before bringing it up you could even copy over the most recent version of all the other cubes to keep it in line. Saying that you need to make sure you have a valid license to do this. If you don't have the license and space on production and you have a development server then you could create the service on there,

Jim.

[Darkhorse]

Or unload the cube then copy the cube to the folder you wish to store it in the simply right click delete if you don't wish to bring your server down

[Wim Gielis]

We have one of the TM1 cube about 33gb and this is one big cube in entire tm1 model and covers 50% of tm1 memory.
We noticed this cube is not used by our user any more.

Just a question. What do you do to come to such a "beast" ?
Was the cube performing well? Or do the users prefer to not use it anymore because it didn't perform at all?

[ravi]

Hi,

Thanks for reply....

This cube not in use - but this cube has dependancey one of the base cube...

Example:

"Cube A" (Is the base cube) and "Cube B" ( Dependancy)

When a process run - I see the dependancy per log file like below.
5880 [13c] INFO 2013-08-08 05:54:57.541 TM1.Cube.Dependency Adding cube dependency: cube "Cube B" depends on cube "Cube A"

I believe related process will fail if I move the Cube B out of the data folder ?

Please advise
Regards,
Ravi

[Michel Zijlema]

This cube not in use - but this cube has dependancey one of the base cube...

Example:

"Cube A" (Is the base cube) and "Cube B" ( Dependancy)

When a process run - I see the dependancy per log file like below.
5880 [13c] INFO 2013-08-08 05:54:57.541 TM1.Cube.Dependency Adding cube dependency: cube "Cube B" depends on cube "Cube A"

I believe related process will fail if I move the Cube B out of the data folder ?

Hi Ravi,

You need some understanding of the model when you want to do things like this. If there is a dependency (through rules or TI processes) than moving the cube file out of the data directory will probably break your model...
BTW, like Wim I'm quite curious whether the users are not using the cube because the contained data is uninteresting or because the data is more or less unaccessible because of performance reasons. Did you have a look at tuning options (from skipcheck/feeders and/or dimension reordering to a complete redesign) for this cube?

Michel

[qml]

Wim & Michel - since we are going a little on a tangent anyway - a 33-GiB cube does not have to perform badly and I would not necessarily call it a 'beast'. I have seen much smaller cubes perform badly and I have seen much bigger cubes perform well. It is all a matter of proper design, as you undoubtedly realise, and 33 GiB is nowhere near the practical upper limit for a TM1 cube.

[Michel Zijlema]

Wim & Michel - since we are going a little on a tangent anyway - a 33-GiB cube does not have to perform badly and I would not necessarily call it a 'beast'. I have seen much smaller cubes perform badly and I have seen much bigger cubes perform well. It is all a matter of proper design, as you undoubtedly realise, and 33 GiB is nowhere near the practical upper limit for a TM1 cube.

Hi Kamil,

We agree on that - I've built models with cubes about that size. I was just triggered by the combination of the cube not being in use and the size of it, which could implicate performance problems.

Michel

[Wim Gielis]

Wim & Michel - since we are going a little on a tangent anyway - a 33-GiB cube does not have to perform badly and I would not necessarily call it a 'beast'. I have seen much smaller cubes perform badly and I have seen much bigger cubes perform well. It is all a matter of proper design, as you undoubtedly realise, and 33 GiB is nowhere near the practical upper limit for a TM1 cube.

Hi Kamil,

We agree on that - I've built models with cubes about that size. I was just triggered by the combination of the cube not being in use and the size of it, which could implicate performance problems.

Michel

Me too, and personally I have to admit, I never built a cube of that size.

[ravi]

Hi All,

(1)
I did cube unload for this particular cube. will that cause any issue?. (Since the moving cube from data folder seems to be a not good idea).
Unload cube released lot of memory from RAM now. I am planning to write a IT process when cube memory reach above 1gb or so..........good to go?

(2) Also planning to change:
TM1S.cfg file IBM recommended a parameter addition/change in cfg file for the two of items:
LockPagesInMemory=T http://www-01.ibm.com/support/docview.w ... wg27024038 And
ParallelInteraction=F http://www-01.ibm.com/support/docview.w ... wg21460595
(3)
Weekly tm1 servers bounce to clean-up the feeder’s memory size.

(4)
Email alters generated when Tm1 server reaches memory size of 85% threshold

Please advise:
Regards,

[Michel Zijlema]

(1)
I did cube unload for this particular cube. will that cause any issue?. (Since the moving cube from data folder seems to be a not good idea).
Unload cube released lot of memory from RAM now. I am planning to write a IT process when cube memory reach above 1gb or so..........good to go?

Unloading a cube releases memory within the TM1 memory space but not to the OS. If the cube is still visible (not hidden by security) to the user and the users tries to open a view on the cube, the cube will be loaded into RAM, which can take a while... Same when another cube is using results from this big cube - opening a depending view will load the the big cube leading to a long view opening time.

(2)
Also planning to change:
TM1S.cfg file IBM recommended a parameter addition/change in cfg file for the two of items:
LockPagesInMemory=T http://www-01.ibm.com/support/docview.w ... wg27024038 And
ParallelInteraction=F http://www-01.ibm.com/support/docview.w ... wg21460595

It's not clear to me what you would like to establish by setting these two parameters (I don't see a direct relation to your original question in this thread). Setting these parameters could do exactly the opposite of what you would like to do... Also read this technote on the LockPagesInMemory parameter.

(3)
Weekly tm1 servers bounce to clean-up the feeder’s memory size.

Bouncing the server willl clean-up the calculation caches, but not necessarily the feeder memory, as the feeders will be re-triggered when loading the cubes.

Michel