I expect that this is to be the length of a piece of string.
Just wondering if there are any general recommendations issued, I could not find anything. We are about to deploy changes which will result in a step increase in RAM usage and we have a handle on the expected increase from our Dev instance (Recent refresh of prod + changes). The question is whether there is any rule of thumb for having x% free.
Any recommendations on available RAM
-
gtonkin
- MVP
- Posts: 1254
- 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: Any recommendations on available RAM
I'll get the ball rolling...
Let's ignore the organic growth in cubes, dimension etc. and how that would scale and factor into your answer.
In recent months I think where we get pretty close to the edge sometimes in with chores.
At some clients we have seen that the chores execute and memory grows then is handed over to garbage where it may or may not be recycled later.
I would start by analysing what is happening here so that you know what kind of buffer you need.
You also want to review chores that may have multiple processes and see if you can enable multi-commit.
With single-commit you are effectively keeping all changes in memory until the end of the last process is committed and no rollback is initiated.
Committing where you can obviously frees up memory and commits to the cubes reducing the size of the transaction that may need to be rolled back and reducing locks etc. too.
I have some ideas on forecasting cube and memory growth but let's see what others have on the above and the latter.
This could get to be an interesting topic with many points of view.
Let's ignore the organic growth in cubes, dimension etc. and how that would scale and factor into your answer.
In recent months I think where we get pretty close to the edge sometimes in with chores.
At some clients we have seen that the chores execute and memory grows then is handed over to garbage where it may or may not be recycled later.
I would start by analysing what is happening here so that you know what kind of buffer you need.
You also want to review chores that may have multiple processes and see if you can enable multi-commit.
With single-commit you are effectively keeping all changes in memory until the end of the last process is committed and no rollback is initiated.
Committing where you can obviously frees up memory and commits to the cubes reducing the size of the transaction that may need to be rolled back and reducing locks etc. too.
I have some ideas on forecasting cube and memory growth but let's see what others have on the above and the latter.
This could get to be an interesting topic with many points of view.