TM1 Forum

Hello to all,

I have noticed that one of our TM1 snapshot servers on windows takes up a lot more RAM than the source of the snapshot, which is the live version.

Our snapshots are used rarely, and no inputs will go into them, as they are used for historical reports.

The other major difference is a setting within the cfg file. With our snapshots we do not use PersistentFeeders, this is because we want to save disk space.

When I turned on PersistentFeeders for this snapshot, the server consumed roughly half the memory it consumed without this cfg setting.

I ran the following test:

With PersistentFeeders = load time 70 seconds RAM usage = 6,993,380 K

Without PersistentFeeders = load time 861 seconds RAM usage = 13,569,300 K

Why would this be? Is it because the longer the load time, the more RAM is needed? And if so, why? Is this the behaviour of the TM1 memory manager, windows architecture, or a mixture of both?

Thanks.

Trevor.

I wonder if you have multi-threaded load on as well? That's the obvious cfg for significant differences in launch RAM and I suspect with persistent feeders on the multi-threaded load is disregarded. Do you have a lot of RAM in garbage with the larger instance?

Steve Rowe wrote:I wonder if you have multi-threaded load on as well? That's the obvious cfg for significant differences in launch RAM and I suspect with persistent feeders on the multi-threaded load is disregarded. Do you have a lot of RAM in garbage with the larger instance?

Hello Steve, we do use multi-threaded load, I am of the mind that the speed of load up with persistent feeders makes multi threaded loading less important. I have done testing with server load times with/without the multi thread load parameter but with persistent feeders. Without multi threaded loading, the server load times is about double that of the server load time with multi threading, but because of persistent feeders, it is a matter of seconds.

We do see more RAM in garbage and I think that would be down to the Multi threaded load?

Thanks.

That would be my guess, with MTL + PF the RAM impact of MTL is marginal since the engine is not doing "double" work to calculate the feeders.

With PersistentFeeders + MTL = load time 70 seconds RAM usage = 6,993,380 K

Without PersistentFeeders + MTL = load time 861 seconds RAM usage = 13,569,300 K

The above is roughly what I would expect with MTL=2, PF mitigates the impact of MTL (really makes it redundant).

Steve Rowe wrote: The above is roughly what I would expect with MTL=2, PF mitigates the impact of MTL (really makes it redundant).

What if MTL=11? or 7? would that make any difference?

Thanks

TrevorGoss wrote:

Steve Rowe wrote: The above is roughly what I would expect with MTL=2, PF mitigates the impact of MTL (really makes it redundant).

What if MTL=11? or 7? would that make any difference?

Thanks

Yes. it does. The more processors you use in the MTL then the more RAM is "consumed". Keep in mind, however, that a good chuck of it is going to be garbage memory. That means the memory is taken from the OS and allocated to TM1, but the amount of memory actually consumed by your model will be the same regardless of load type. The leftover memory will be used by TM1 for caching, etc., as the model is used.

tomok wrote:

TrevorGoss wrote:

Steve Rowe wrote: The above is roughly what I would expect with MTL=2, PF mitigates the impact of MTL (really makes it redundant).

What if MTL=11? or 7? would that make any difference?

Thanks

Yes. it does. The more processors you use in the MTL then the more RAM is "consumed". Keep in mind, however, that a good chuck of it is going to be garbage memory. That means the memory is taken from the OS and allocated to TM1, but the amount of memory actually consumed by your model will be the same regardless of load type. The leftover memory will be used by TM1 for caching, etc., as the model is used.

Hello Tom, thanks for your response.

but the amount of memory actually consumed by your model will be the same regardless of load type.

Why would the turning on/off the PersistentFeeders cfg parameter (and deleting the .feeder files) affect RAM consumption? Is this statement true: "The longer the load time more RAM is consumed" and why would it be true? This is with MTL=0

Thanks.

Most of the time taken on server start up is the instance populating the feeder flags. The calculation of where the feeder flags go and holding of them both consume RAM and time. With PF on this work doesn't need to be done.

RAM and time taken are both measures of the amount of the work the instance does on launch, most of the work done at launch is feeder related.

Steve Rowe wrote:Most of the time taken on server start up is the instance populating the feeder flags. The calculation of where the feeder flags go and holding of them both consume RAM and time. With PF on this work doesn't need to be done.

RAM and time taken are both measures of the amount of the work the instance does on launch, most of the work done at launch is feeder related.

That makes sense as to why almost double the amount of RAM was in use when PF was off.

Thanks Steve.

It's my understanding that MTL consumes more memory when calculating feeder flags because there is some overlap in the work each thread does. You still save time by parallelizing the calculations, but there are some times where two different threads will calculate the same (overlapping) feeder flags. One example would be if feeder statements on two different cubes point to overlapping areas on a third cube. This is wasted time and requires additional memory to store. Once the MTL feeder calculations are finished the work each MTL thread did is merged together, but all that extra memory used for overlapping calculations is never returned back to the OS (but is available for TM1 to re-use internally as usual).

Hello Brian

BrianL wrote:It's my understanding that MTL consumes more memory when calculating feeder flags because there is some overlap in the work each thread does. You still save time by parallelizing the calculations, but there are some times where two different threads will calculate the same (overlapping) feeder flags. One example would be if feeder statements on two different cubes point to overlapping areas on a third cube. This is wasted time and requires additional memory to store. Once the MTL feeder calculations are finished the work each MTL thread did is merged together, but all that extra memory used for overlapping calculations is never returned back to the OS (but is available for TM1 to re-use internally as usual).

is any of the above valid if the model is using PersistentFeeders? Because it is my understanding that the .feeder files would contain the coordinates for each feeder flag, these files would get loaded straight away so there would be no need to calculate them on start up.

It does seem as if MTL is more or less redundant when PF is used.

Thanks.

That's exactly right.

PersistentFeeders saves all the coordinates for the feeder flags in the .feeder files. At startup these files are directly loaded instead of running the feeder calculations.

That's why you would see both an improvement in startup time and memory consumption.

BrianL wrote:That's exactly right.

PersistentFeeders saves all the coordinates for the feeder flags in the .feeder files. At startup these files are directly loaded instead of running the feeder calculations.

That's why you would see both an improvement in startup time and memory consumption.

Thought so, thanks Brian.

Trevor.

I agree with Brian and I also think that although MTL also influences the memory consumption, the persistent feeders setting itself can have an impact on memory consumption, independently from the MTL; for example if two cells feed a third cell, then both feeders are fired without PF, while if you have a .feeder file, only the feeder flags are loaded.

I would have a question on PF, if already it came up: what are your experiences with 10.2.2, fp3 or fp4? How reliable are they? I remember in 10.1.1 we had to switch them off because we found some bugs (do not remember what kind of bugs exactly though). Did anyone find any issues with feeders and data calculation while having PF on?


Thanks!

mvaspal wrote:
I would have a question on PF, if already it came up: what are your experiences with 10.2.2, fp3 or fp4? How reliable are they? I remember in 10.1.1 we had to switch them off because we found some bugs (do not remember what kind of bugs exactly though). Did anyone find any issues with feeders and data calculation while having PF on?

Thanks!

We use 10.2.1 but we still came across an issue in with PF is used, it was covered in this post: http://www.tm1forum.com/viewtopic.php?f ... aveDataAll

Basically, we had to be careful using SaveDataAll before deletingAllPersistentFeeders() feeders because the SaveDataAll will write out both the .cub and the .feeder files for any cubes that have changed data.