TM1 9.4 MR1
Posted: Wed Mar 11, 2009 4:39 pm
My IT group us pushing for the upgrade to 9.4 because of "SOX Compliance." Is 9.4 MR1 still to buggy to risk?
Discussing all things TM1, Planning Analytics, PAx and PAW
https://www.tm1forum.com/
I note that you're still on 32 bit 9.0... are you going to be OK with the memory usage jump? (Which is admittedly greater in the jump from 9.0 to 9.1, but it ain't gonna get any better when you go to 9.4.) That's what's holding me off at the moment. We're fine on 8.2.12 most of the time... we have the occasional issue, but nothing much to speak of. But on 9.1+, then...Eric wrote:I agree it is a weak argument, but that is the stance they are takingAlso I am not fighting them to much because I would like use a few of the new functionality 9.4 has.
Thanks for the comments about the bugs.
Ah, how long's a piece of string, compadre?Eric wrote:How much of a memory increase are we talking for 9.0 to 9.1?
And then 9.1 to 9.4?
Note the "may" consume more memory part. I think that this comes under the heading of "your guess is as good as ours, try it and see". We're running 9.1 on one box for Web only and 8.2.12 on the other; I've been planning to test what kind of difference is experienced with our model at startup on both systems, but haven't done so yet.Iboglix Release Notes wrote:In TM1 9.1, the TM1 Server delivers greatly improved concurrency and overall stability, as well as better diagnostics and monitoring capabilities. A side-effect of these necessary changes is that the TM1 Server may consume more memory than in previous versions. The amount of additional memory is primarily model-dependent. Customers who in previous versions have observed that they operate close to the memory limits of their hardware, should anticipate adding additional memory and/or modifying their models using documented TM1 memory optimization techniques. Customers who are currently using 32-bit TM1 Server near the 3 GB limit, may need to upgrade to a 64-bit TM1 Server. See the Applix Recommended Practices Repository on the Applix website (http://www.applix.com/rp/tm1_recommended_practices.htm) for articles on TM1 memory optimization and monitoring TM1 Server memory usage. Also, see the documentation on TM1 Counters in the TM1 Operations guide for more information.
I should have added; one of the reasons that I haven't made this a priority is that I'm not sure that startup memory usage is going to be a particularly valid comparison. If a lot of the change comes from changes to the locking model (note that one of the claims is "improved concurrency"), it may well be that you aren't going to see the real differences until you have users pounding the processors with read and write operations. That's what worries me more than anything; there's no realistic way of knowing exactly how bad the memory delta will be until you're actually staring it down in a production environment. You can guess, you can hope, you can extrapolate, you can simulate... but unless you're a long way from using all of your memory in an existing 32 bit environment, I'd be wary about 9.1+.Alan Kirk wrote:Note the "may" consume more memory part. I think that this comes under the heading of "your guess is as good as ours, try it and see". We're running 9.1 on one box for Web only and 8.2.12 on the other; I've been planning to test what kind of difference is experienced with our model at startup on both systems, but haven't done so yet.
Most interesting and useful information. Were you measuring that at startup, or as an average during the session's running time?belair22 wrote:Just to throw in my 2c....
Recently completed a fairly large corporate upgrade (both Server and silent client installs) - TM1 9.0 to 9.4 MR1 .
A fairly hefty TM1 model - Memory usage went up by only 10% - 15%. We have MaximumCubeLoadThreads set to 0 to conserve as much memory as possible.
Didn't someone report that, although MaximumCubeLoadThreads does consume more memory during load, it frees it once the load is complete? If you're 32-bit and near the limit I could see being concerned, but if not, RAM is cheap (and freed RAM is freebelair22 wrote:We have MaximumCubeLoadThreads set to 0 to conserve as much memory as possible.