TM1 Forum

We are trying to load our GL Detail cube for month and receiving the following error:

2012 WARN 2008-11-10 14:46:11,592 TM1.Server.Memory CommonAlloc() outOfMemory Exception <<< MEMORY_ALMOST_FATAL_LEVEL >>> - threadID "2012" - apifunc# "0"

Dimension data is attached.

Thank You, Rick.

Hi Rick,

The theoretical limit is approx 2 billion elements in a dimension. Practically speaking, you don't see many TM1 models with dimensions larger than a few million, and models with dimensions over 100,000 elements I would say are not that common. For one thing, dimensions with this many elements tend not to operate very efficiently in the TM1 Subset Editor and can be very rough to navigate unless you have a good hierarchy structure (even then, 4 million+ elements could be pretty rough).

I'm not sure what your GL Detail Lines dimension contains, but I can tell you from your screenshot that it, alone, is taking up about 1.3 GB of RAM. THat doesn't include any attribute data or data in any cubes that would use this dimension. Unless you're talking about some customer/subscriber/SKU detail I'm not sure how much value you get with a dimension this large.

I suspect from that error message that what you may be running into is a limit on available memory in TM1 - If you are running a 32-bit version of TM1 Server it can only ever use up to 3GB of RAM on a 32-bit OS and 4GB of RAM on a 64-bit OS. If you are running a 64-bit edition of TM1 Server then the RAM limitations are basically limited to what you have installed in your hardware and what your 64-bit OS supports. TM1 support should be able to provide some additional information on what that specific error message means (I didn't see anything in the Operations Manual about it).

Regards,
Mike

Mmmmm.... You have 4.5 million elements (account detail lines) which is very high and sounds as though you have very detailed transactional data in there. TM1, like most OLAP databases, normally operates at a first level of summarisation, is there a good reason why you are maintaining this level of detail in your database? If so, you need to be very careful about optimising database design and, if needed, consider 64 Bit.

Hi Rick,

What exactly is the "GL Detail Lines" dimension?

In the table structure of many GL systems the posting account for GL data might be something like ZZBBCCXXXX where ZZ is a company code, BB a location code, CC a cost centre code and XXXX the chart of accounts code. This is actually a concatenation, from a TM1 design perspective is is much more efficient (and user and analysis friendly) to split this into 4 separate (much smaller) dimensions.

Without any further detail hard to say if this might be your problem or as has already been suggested that the data set is too transactional in nature.

Hi Rick,

I suspect you are trying to load booking transactions into the cube. It is not required and not recommended in a MOLAP system. Better solution is to redesign your cube the way it is suggested in the above two posts and keep your transactions in a relational table (i.e. SQL Server) where you can easily drill down from TM1.

Gábor