TM1 9.5.2 Server Sizing

[KSimon]

Hi All,

I am looking for advice on how to properly quantify the hardware requirements for TM1. We have a customer with an existing TM1 environment and models, and they will be migrating to TM1 9.5.2 and onto a new hardware.

How can we correctly size the hardware requirement (particular RAM and CPU/Cores) needed for their models, number of users etc? Is there a spreadsheet or some type of formula that we can apply?

Thanks so much,
Kevin.

[Martin Ryan]

Have you consulted the IBM site? https://www-304.ibm.com/support/docview ... wg27020888

[Alan Kirk]

How can we correctly size the hardware requirement (particular RAM and CPU/Cores) needed for their models, number of users etc? Is there a spreadsheet or some type of formula that we can apply?

No, there isn't. Certainly you won't find any reference to it in the FAQ thread. Especially the bit of the FAQ thread which reads:

Note particularly the TM1 Server Administration document, which gives an outline of the resources needed to create a TM1 model.

(Which, admittedly, is for 9.1 but the specs haven't changed too much since then...)

Because that's certainly a question that's never come up before.

[KSimon]

Hi Martin,

Thanks for the reply. That's not exactly what I am looking for - it shows the supported environments and provides minimum hardware requirements, but doesn't provide information on what the recommended hardware configuration should be based on the size of models, number of users etc.

I am looking for something along the lines of the document that can be downloaded from this link, but for 9.5.2:
http://www.ibm.com/developerworks/data/ ... ge205.html

Thanks,
Kevin.

[Alan Kirk]

I am looking for something along the lines of the document that can be downloaded from this link, but for 9.5.2:
http://www.ibm.com/developerworks/data/ ... ge205.html

As I indicated, there isn't one. However the major memory bump occurred between 9.0 and 9.1 when the locking model was revamped, which means that the specs for 9.5 shouldn't be too far removed from the ones given.

[mattgoff]

It ... doesn't provide information on what the recommended hardware configuration should be based on the size of models, number of users etc.

I am looking for something along the lines of the document that can be downloaded from this link, but for 9.5.2: http://www.ibm.com/developerworks/data/ ... ge205.html

Those documents will always be of limited usefulness because TM1 performance is extremely dependent on your specific model design (esp. rules and resultant dependencies) and usage (esp. readers vs. writers, simultaneous users, although we'll see if both of these are mitigated in 9.5.2). These would be my recommendations:

Users are assigned to a single core (or thread, in the case of hyperthreading), so I'd figure out how many simultaneous users you will have max and get somewhere between 0.25x to 1x that number of cores, depending on your budget. Cores are getting cheap, so I would go towards the higher ratios. Processor speed is, in my experience, not particularly relevant except maybe at start-up, but even then there is a lot that is I/O bound and persistent feeders helps reduce subsequent start time. So, feel free to go lower there. This may seem counterintuitive (more cores, lower speeds), but the biggest problem I see is blocking, not single-query performance.

Get lots of fast RAM or at least leave yourself room to grow. Just enabling MaximumCubeLoadThreads pumps up RAM needs for a while after start, and Parallel Interaction supposedly averages a ~30% RAM usage bump too. Again, RAM is cheap, but it's also easy to add later, so the key thing is to leave yourself some empty slots for the future. As you expand your model, this will likely be the bottleneck too.

Matt

[stephen waters]

I'd figure out how many simultaneous users you will have max and get somewhere between 0.25x to 1x that number of cores, depending on your budget. Cores are getting cheap, so I would go towards the higher ratios. Matt

Cores may be getting cheap but remember that TM1 is now licensed on a PVU basis. So, upgrading to a box with more cores could lead to extra licensing costs which are much higher than the cost of the physical cores. Make sure you include it in your budget !
I have heard of a TM1 customer who is being investigated by the IBM compliance department for not purchasing extra PVU licenses so it is not just an academic discussion.

On a more technical note, many of the applications we implement have complex calculations and not many concurrent users. Since TM1 calculation is pretty much single threaded, in these cases the extra cores dont reallly help anyway.

[mattgoff]

Cores may be getting cheap but remember that TM1 is now licensed on a PVU basis. So, upgrading to a box with more cores could lead to extra licensing costs which are much higher than the cost of the physical cores. Make sure you include it in your budget !

Wow, I guess I'm not one but now two licensing schemes behind-- we're still clinging to our concurrent user license! Frankly, that seems the fairest license to me. PVU is worst of all as it provides a backwards incentive for Cognos to make the product require more cores....

Matt

[KSimon]

Users are assigned to a single core (or thread, in the case of hyperthreading), so I'd figure out how many simultaneous users you will have max and get somewhere between 0.25x to 1x that number of cores, depending on your budget. Cores are getting cheap, so I would go towards the higher ratios. Processor speed is, in my experience, not particularly relevant except maybe at start-up, but even then there is a lot that is I/O bound and persistent feeders helps reduce subsequent start time. So, feel free to go lower there. This may seem counterintuitive (more cores, lower speeds), but the biggest problem I see is blocking, not single-query performance.

Get lots of fast RAM or at least leave yourself room to grow. Just enabling MaximumCubeLoadThreads pumps up RAM needs for a while after start, and Parallel Interaction supposedly averages a ~30% RAM usage bump too. Again, RAM is cheap, but it's also easy to add later, so the key thing is to leave yourself some empty slots for the future. As you expand your model, this will likely be the bottleneck too.

Thanks Matt - that is really useful.

[KSimon]

Wow, I guess I'm not one but now two licensing schemes behind-- we're still clinging to our concurrent user license! Frankly, that seems the fairest license to me. PVU is worst of all as it provides a backwards incentive for Cognos to make the product require more cores....

Hi Matt,

This exercise is for a migration from legacy (concurrent) licensing to the new licensing model (PVU's and Named Users). We are trying to figure out the correct hardware configuration so that the customer only has to buy the appropriate amount of PVU's required to run their existing models (as previously mentioned, PVU licenses can be expensive!). If we buy too few PVU's, TM1 will run like a dog, but if we buy too many it is money wasted - the question is how do we find the "right" hardware based on their currenct TM1 environment.

One thing to be wary of - the server on the legacy licensing model is licensed according to processor (and not PVU's), HOWEVER, in terms of this licensing model each processor is allowed a maximum of 2 cores. So as an example, if you run TM1 on a server that has one processor with 8 cores and you only have one processor license, you are not compliant.

Cheers,
Kevin.

[Alan Kirk]

Wow, I guess I'm not one but now two licensing schemes behind-- we're still clinging to our concurrent user license! Frankly, that seems the fairest license to me. PVU is worst of all as it provides a backwards incentive for Cognos to make the product require more cores....

One thing to be wary of - the server on the legacy licensing model is licensed according to processor (and not PVU's), HOWEVER, in terms of this licensing model each processor is allowed a maximum of 2 cores. So as an example, if you run TM1 on a server that has one processor with 8 cores and you only have one processor license, you are not compliant.

More likely a legacy licencing model rather than the legacy licencing model. TM1 licencing is rightly regarded as a black art, and IBM continues the tradition of having an appalling lack of transparency and consistency in that regard. Apparently (or so I was told by my former IBM rep) there has always been some kind of server limitations on 64 bit licences... though what those restrictions were was somewhat fluid. On my pre-existing 32 bit licence we don't have any actual hardware restrictions at all... or at least not licencing ones, though the fact that it's 32 bit is enough of a restriction in itself.

I can't help but get the feeling that a PVU licencing model is nothing but a blatant rip-off. Does it cost more to develop? Well, granted it costs more to develop parallel interaction code, although that's academic from the user point of view when it doesn't work properly. Does it cost more to support? Unlikely. The mindset appears to be "if they can afford a fast box, they can afford to pay us more".

However that's the other issue which makes this a "how long is a piece of string" question; if IBM finally does sort out its issues with parallel processing, it may make the "sweet spot" server point shift in due course.

[stephen waters]

Wow, I guess I'm not one but now two licensing schemes behind-- we're still clinging to our concurrent user license! Frankly, that seems the fairest license to me. PVU is worst of all as it provides a backwards incentive for Cognos to make the product require more cores....

Matt

Matt, Old Applix licenses had no restriction on processors, then went through a phase of having a maximum number of cores (ie "Open Access" licensing). So, if they work for you, hang on to those concurrent licenses and be prepared to stand your ground against IBM when they argue otherwise.

To be fair I think the TM1 development team are want to improve performance but the emphasis seems to be on high concurrent input rather than improving calculation\reporting time, eg multi threaded calcs or being more granular with discarding cached results. Probably due to TM1 replacing Cohgnos Planning.

[mattgoff]

This exercise is for a migration from legacy (concurrent) licensing to the new licensing model (PVU's and Named Users). We are trying to figure out the correct hardware configuration so that the customer only has to buy the appropriate amount of PVU's required to run their existing models (as previously mentioned, PVU licenses can be expensive!). If we buy too few PVU's, TM1 will run like a dog, but if we buy too many it is money wasted - the question is how do we find the "right" hardware based on their currenct TM1 environment.

Do you have to change your license? IBM wanted us to do so a long time ago when they switched from concurrent to named user, but we declined. It should be in your rights to do so, but of course that would depend on your original agreement.

One thing to be wary of - the server on the legacy licensing model is licensed according to processor (and not PVU's), HOWEVER, in terms of this licensing model each processor is allowed a maximum of 2 cores. So as an example, if you run TM1 on a server that has one processor with 8 cores and you only have one processor license, you are not compliant.

There is no mention of processors or cores in our license. We bought TM1 in 2006 when it was still Applix. The only restrictions in our license are # of servers and # of concurrent users on each server. We'll stay on this license forever, if I have my way, but there is a risk that we will outgrow x86 (we have two x64 licenses and seven x86, each with various numbers of permitted concurrent users). As it, I will not be able to enable ParallelInteraction on the x86 servers. Luckily, all of the sites running them are small and don't really need that capability.

Matt

[mattgoff]

To be fair I think the TM1 development team are want to improve performance but the emphasis seems to be on high concurrent input rather than improving calculation\reporting time, eg multi threaded calcs or being more granular with discarding cached results. Probably due to TM1 replacing Cohgnos Planning.

Yes, my comment was a bit tongue-in-cheek, but I dislike systems where the intrinsic motivations are counterproductive (except maybe to IBM's bottom line). As if server sizing wasn't hard enough, now licence cost is in play (and quite possibly the biggest factor, cost-wise).

I'm getting used to development going a different way than we would prefer. Since Cognos bought Applix, there has definitely been a redirection of the development team away from core TM1 features and to integration with Cognos products and adding more GUI/wizards. I can see why both happen-- of course they want integrated products to help cross-sell and no doubt their new user surveys indicate that TM1 has a steep learning curve. Chalk the latter up to sales pitching TM1 as a tool "anyone in Finance can build" which is ridiculous beyond the most basic implementations (or if the company is lucky enough to have an ex-programmer in the Finance org ).

I have yet to test ParallelInteraction in production (next week!), but that is one exception to the above gripe. If it works as advertised, it should fix the locking model that has been broken since we bought the product.

Matt

[mattgoff]

Apparently (or so I was told by my former IBM rep) there has always been some kind of server limitations on 64 bit licences... though what those restrictions were was somewhat fluid.

I just read through the entirety of our Software License Agreement from 2006 and there is no mention of any restriction other than # of servers and # of concurrent users on each server. So, it would seem that your rep was mistaken (phew!). I suppose my only hope on the x86 licenses is that Cognos goes all x64 and they have to give it to me for free... although they'll probably compile a special x86 version forever for me out of spite.

BTW, sorry to hijack the thread, Kevin.

Matt

[Alan Kirk]

Apparently (or so I was told by my former IBM rep) there has always been some kind of server limitations on 64 bit licences... though what those restrictions were was somewhat fluid.

I just read through the entirety of our Software License Agreement from 2006 and there is no mention of any restriction other than # of servers and # of concurrent users on each server. So, it would seem that your rep was mistaken (phew!).

Not necessarily... it's entirely possible that different rules applied in Australia. Applix, like IBM, was also less than transparent with this.

I suppose my only hope on the x86 licenses is that Cognos goes all x64 and they have to give it to me for free... although they'll probably compile a special x86 version forever for me out of spite.

Actually I foresee two names on that particular licence, my copy being pinned just under my photograph on the dartboard in Iboglix headquarters.

BTW, sorry to hijack the thread, Kevin.

Actually I don't think this is really threadjacking, because as Stephen pointed out the licence restrictions and costs relating thereto necessarily form part of the decision process. It shouldn't be that way... the thing should cost what it costs and that's it... but unfortunately it is.

[conflax]

Users are assigned to a single core (or thread, in the case of hyperthreading), so I'd figure out how many simultaneous users you will have max and get somewhere between 0.25x to 1x that number of cores, depending on your budget. Cores are getting cheap, so I would go towards the higher ratios. Processor speed is, in my experience, not particularly relevant except maybe at start-up, but even then there is a lot that is I/O bound and persistent feeders helps reduce subsequent start time. So, feel free to go lower there. This may seem counterintuitive (more cores, lower speeds), but the biggest problem I see is blocking, not single-query performance.

Hi,

I realise this is an old thread but relevant to me as we're looking at hardware requirements for an instance of 9.5.2. I need to keep PVU costs to a minimum so have a 4cores maximum, with 4-5 concurrent users out of a total of maybe 50, and some heavy reliance on rules for forecasting in an FS environment. RAM is not a problem, but we can't virtualise due to current architecture (don't ask me why as I don't know). Does anyone have any other experience of whether clockspeed affects performance as I have heard the opposite to Matt's comments above, ie. very relevant.

I am being offered a 1.8GHz 4core, but am worried this is not enough.

Any thoughts?

Thanks

[Steve Rowe]

I'd be looking at faster processors for sure. 1.8 is really really slow.

I was recently performance testing TIs on two different boxes and % difference in the processor speed translated pretty much straight through to the performance side.

My testing was between a 2.4 GHz with many cores and 3 GHz with few cores and the 20% difference in raw processor speed seemed to translate to about 30% difference in the TI run times. No idea where the extra 10% drop off came from. There was no other activity on either TM1 instance.

To me the 2.4 box feels soggy when doing single threaded type tasks (like rule calculation) so 1.8 would probably be horrid....

Cheers,

[conflax]

Not great - but exactly the answer I was expecting

Thanks for the confirmation

[conflax]

Hi,
Quick update and a question.

I have found an PVU and speed compromise in a 3.3ghz quad core, with 48GB RAM.

WIth 60 users and accepting that some of the performance will be down to rules efficiency - is it a problem that the 48GB is the max RAM in this box when RAM is so important? It feels like enough to me, I have been recommended 32......