Hi All,
We are on PA 2.0.9.15 version and have a server with 200 GB HD and 128 GB RAM with 8 cores (max PVU license for processor.) Lately we are seeing about 80% of RAM used want to add more models to the server and want to know the best approach.
Our IT says the server is huge on RAM and can't add more. Are there any limitations on adding RAM? Can you let me know the size of RAM you have on the server? Adding RAM is the easiest and have to convince our IT hardware that our server is not the biggest.
Can you let me know if ours is big and what big can be.
Thanks,
Paul.
RAM and PVU licensing
- gtonkin
- MVP
- Posts: 1202
- Joined: Thu May 06, 2010 3:03 pm
- OLAP Product: TM1
- Version: Latest and greatest
- Excel Version: Office 365 64-bit
- Location: JHB, South Africa
- Contact:
Re: RAM and PVU licensing
HI Paul,
Some of use were chatting recently and there are servers out there with 2TB of RAM.
128GB of RAM is by no means big.
However, saying this, if I were IT I probably would have asked you if you have optimised usage as far as you can.
Have you looked at what usage the cubes show using Performance Monitor and }StatsbyCube? Add a new numeric member called: Memory per Populated Cell and then the rule below.
I then sort my cubes from highest to lowest on Total Memory Used and then look at the value in the Memory per Populated Cell.
Typically anything over 40 may be a concern but there are many factors that can increase the value so some consideration needs to be given to the following:
- Number of dimensions. The "address" of each cell gets longer with each dimension added to the cube. The pointer to each member in each dimension will require a few bytes and the sum of these adds up.
- Number of members in a dimension. As a dimension gets larger the pointer to each member will get more complex and thus require more bytes.
- String data in the cube will skew the values as string require more memory to store the data for each string related cell.
Hubert's video on How TM1 actually works should give some more insights into my rough understanding of the above.
Once you have identified a candidate consuming what looks like too much memory per cell, you could then look at reordering the dimensions.
There are various articles here on this topic but armed with some of what Hubert has shared, knowledge of how your model works, is populated in terms of small to big dimensions and sparse to dense, you should be more informed to try and reduce memory consumption.
If you think manual reordering will be pure guesswork, Marius Wirtz has you covered with OptimusPY. This will at least take some of the guesswork away from you by simulating some scenarios based on a provided cube view and process. The bonus is you get a view of not only the new memory/savings but the performance too. No point saving a gig or two and have queries take double the time.
The other thing you could look at is the memory consumed by feeders as you may have overfeeding.
There is a debug utility which can dump a bunch of information including information on your feeders.
This is undocumented etc. so caution etc. and use in Dev only.
The 0 after the 123, includes (0) or suppresses (1) control objects.
The 1 after the 0, is the flag to include the extra feeder information.
Hope this helps from a validation of existing resources point of view to give you some evidence if required.
Some of use were chatting recently and there are servers out there with 2TB of RAM.
128GB of RAM is by no means big.
However, saying this, if I were IT I probably would have asked you if you have optimised usage as far as you can.
Have you looked at what usage the cubes show using Performance Monitor and }StatsbyCube? Add a new numeric member called: Memory per Populated Cell and then the rule below.
Code: Select all
['Memory per Populated Cell']=N:
['Memory Used for Input Data'] \
( ['Number of Populated Numeric Cells'] +
['Number of Populated String Cells'] );
Typically anything over 40 may be a concern but there are many factors that can increase the value so some consideration needs to be given to the following:
- Number of dimensions. The "address" of each cell gets longer with each dimension added to the cube. The pointer to each member in each dimension will require a few bytes and the sum of these adds up.
- Number of members in a dimension. As a dimension gets larger the pointer to each member will get more complex and thus require more bytes.
- String data in the cube will skew the values as string require more memory to store the data for each string related cell.
Hubert's video on How TM1 actually works should give some more insights into my rough understanding of the above.
Once you have identified a candidate consuming what looks like too much memory per cell, you could then look at reordering the dimensions.
There are various articles here on this topic but armed with some of what Hubert has shared, knowledge of how your model works, is populated in terms of small to big dimensions and sparse to dense, you should be more informed to try and reduce memory consumption.
If you think manual reordering will be pure guesswork, Marius Wirtz has you covered with OptimusPY. This will at least take some of the guesswork away from you by simulating some scenarios based on a provided cube view and process. The bonus is you get a view of not only the new memory/savings but the performance too. No point saving a gig or two and have queries take double the time.
The other thing you could look at is the memory consumed by feeders as you may have overfeeding.
There is a debug utility which can dump a bunch of information including information on your feeders.
This is undocumented etc. so caution etc. and use in Dev only.
Code: Select all
DebugUtility( 123, 0, 1, pPath|'\Model_Information.txt', '', '' );
The 0 after the 123, includes (0) or suppresses (1) control objects.
The 1 after the 0, is the flag to include the extra feeder information.
Hope this helps from a validation of existing resources point of view to give you some evidence if required.
-
- Posts: 124
- Joined: Tue Jun 13, 2017 3:20 pm
- OLAP Product: TM1
- Version: 10.2.2
- Excel Version: 2010
Re: RAM and PVU licensing
Thanks Gtonkin.
Is the 2 TB machine on Cloud?
We have reordered our dimensions and got it to an ideal memory position. We have to add more applications and will eventually run into that situation.
Thanks,
Paul.
Is the 2 TB machine on Cloud?
We have reordered our dimensions and got it to an ideal memory position. We have to add more applications and will eventually run into that situation.
Thanks,
Paul.
- gtonkin
- MVP
- Posts: 1202
- Joined: Thu May 06, 2010 3:03 pm
- OLAP Product: TM1
- Version: Latest and greatest
- Excel Version: Office 365 64-bit
- Location: JHB, South Africa
- Contact:
Re: RAM and PVU licensing
AFAIK, the 2TB was on-premise - would shudder to think what 2TB would cost on cloud, especially with the new PA aaS offering where you buy memory in 16Gb chunks - 125 of them required at around $10k each.
Sure the premium offering would have pricing benefits but cannot see that hosting on cloud with this requirement would ever make sense at this kind of cost.
Sure the premium offering would have pricing benefits but cannot see that hosting on cloud with this requirement would ever make sense at this kind of cost.
-
- Posts: 124
- Joined: Tue Jun 13, 2017 3:20 pm
- OLAP Product: TM1
- Version: 10.2.2
- Excel Version: 2010
Re: RAM and PVU licensing
Thanks again.
-
- MVP
- Posts: 3654
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: RAM and PVU licensing
+100 for George’s 1st post.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
-
- Regular Participant
- Posts: 159
- Joined: Fri Aug 12, 2016 10:02 am
- OLAP Product: tm1
- Version: 10.2.0 - 10.3.0
- Excel Version: 2010
Re: RAM and PVU licensing
Hello yes we keep 20-25% RAM free on prod server(local) bacause if you get some memory leak server may crash realy qick and get all you model on this server. ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)