TM1 9.5.2 Server Sizing

Esuom

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.

gdisoft

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

王山振

KSimon wrote: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 . 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.

西山红叶

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:


Thanks,
Kevin.

龙创天下

KSimon wrote:I am looking for something along the lines of the document that can be downloaded from this link, but for 9.5.2:

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.

cat-hao

KSimon wrote: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:

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

想想111

mattgoff wrote: 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.

jinanday

stephen waters wrote: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

玩美123

mattgoff wrote: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.

lindejink

mattgoff wrote: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.