RAM usage exploding with CubeUnload and ViewConstruct

[holger_b]

My goal is to copy "the" important cube from the production environment to both the test and development instances once a week. But unfortunately IT doesn't allow me to stop and restart the services from a TI routine, so I finally came up with the idea of unloading the cube, copying the productive version and reloading it with ViewConstruct.

This works well, but it takes unexpectedly huge amounts of memory, so I only do this at weekends as the services are restarted by IT every Sunday morning anyway. Actually, it would be great to have a solution that works at the push of a button whenever it's needed, but since it requires so much RAM, I'm reluctant to make it available to the power users.

Any ideas on how I could make it work better?

[Steve Rowe]

If the method you have picked for keeping the cubes aligned is not working, have you considered other methods? A couple of methods, there are probably others.

If you have logging enabled you could consider replication.
Export and import of active periods

Cheers,

[ascheevel]

How big is the view in your ViewConstruct? You should be able to construct a small view to trigger the cube load back into memory. Also, when a cube is reloaded to memory, feeders are reprocessed which takes time & memory. The server theoretically should be reusing the garbage memory from the previous unload, but perhaps that isn't happening.

IT won't let you restart a DEV tm1 service, will they know and you get in trouble somehow? If it's not PROD, whatever you can accomplish with TI and ExecuteCommand is fair game imo

[holger_b]

Good idea to open only a very small view, but this still takes 30 GB of RAM even though the cube usually does not take much more than 18 in production. But it works fine to simply unload and copy the cube shortly before the service is anyway restarted, so I will stick to that.

Thank you!
Holger

[gtonkin]

I have noticed similar behaviour when using MTFeeders=T and MTFeeders.AtStartup=T

Are you using these in your TM1s.cfg?

[lotsaram]

Why don't you export data to CSV on production and load the CSV in Test/Dev? It seems to me that this would be a better solution.
- more scope for automation since at the end of the export the process to load the file could be chained by tm1runti or rest call
- presumably the whole history doesn't change each week only the latest time partition, so the data saved to disk should be small compared to the whole cube. This would also mean a much smaller memory impact to the targets.