Currently we are having the below configuration in one of our AIX 6.1 server.
RAM:- 8 GB
Paging space :- 19 GB
CPU processor:- 1
CPU type: 64 bit
But we would like to upgrade the configuration to below to improve the system performance and resolve some memory issues.
RAM:- 32 GB
paging space: 40 GB
CPU processor :-1
Could you please confirm and let us know the below points.?
1.) Is This configuraion is with 1 CPU processor will be possible.?
2.) Can we see any perfomance with 1 CPU core or any impact?
3.) There will be any limitation in CPU core if we upgrade the RAM to 32 GB?
As a workaround this will work for some time, but the issue why you have memory problems might still show up, can just take longer until the RAM is used up. But that depends on what you are running and how the problems shows itself.
Though additional CPU units will not help with memory issues.
So as the others suggested, you should investigate what is the reason for your memory problem.
And as blackrageous asked, there is no need for so much paging space. I would go for a fix Paging Space size of 5GB or 10GB. When your system starts to use it, the performance will usually degrade enormous and so the goal is to avoid that before it happens.
If it the out of memory occurs directly after the application or DB2 is started, you might want to check, to which value the parameter database_memory is set, or maybe one of the other memory parameter for DB2.
When it occurs, just to make sure, use svmon -P | grep -p Pid to determin which is using Paging Space. You will simply see it, when there is not a null in the column "Pgsp" to find the culprit.
So it could be, that you overcommit memory to the database, that you don't even have (in the old setup) as physical RAM available.
Another thing comes to my mind - has your OS been "tuned"? Maybe post the output of vmo -F -L lru_file_repage -L minperm% -L maxperm% -L maxclient% -L maxpin% .
I would not worry about real memory reporting 99% with vmstat, nmon or such like, as AIX keeps real memory even when a process ends just in case the same data is needed later. You need to keep an eye on paging to see if you are really running out of real memory.
lsps -a
You also need to consider if your DB has a real-memory requirement. If you exceed the real memory, you system will start to page. Check vmstat for the pi & po columns to see read and writes to/from disks for paging.
If your DB requires (or is set for) large real memory, then that can be a problem too. This is an allocation that is not eligible for paging. if you run multiple instances, remember that they will each want their own allocation and that you may be exceeding the machine limits there. The settings in the DB startup parameters is not defining how big a machine you have, it's how much you are allocating to that instance - a mistake we have seen here.
May be your team did not performed a stress test thoroughly, you will put the system to its max limits during that test (before you go live).
I guess, the no of users after go-live crossed the actual stress test, you guys under sized the system.
If you say NO and your answer is you did the stress test pushing to max, then my immediate guess is there might be change in code in application, ask them. Why there was no problem before and then sudden spike.
To the best of my experience either one of those should be it.
Ok, your system is definetly actively paging in and out to Paging Space. Also some processes like your java and BIService (Business Intelligence?) are paged out already.
That together with a DB2 on this box, is a bit much maybe for 8 GB.
I assume your box has the default settings - the output of vmo -F -L lru_file_repage -L minperm% -L maxperm% -L maxclient% -L maxpin% is missing.
So with this input it seems, you are simply far from having enough memory. If you are increasing to 40 GB, there will be most probably no paging anymore anyway.