AIX Real Memory Allocation, % Comp memory and Non Comp or Client Memory


I need to allocate 85% of my real memory to be utilized by %Comp Processes and remaining 15% by non comp (Client) processes. Currently there are issues with memory allocation.

Can someone please tell me how to do that?

Extra information- if it helps in helping me set that up
i already have to test servers which have that setting of 85% Comp and 15% Client on them already.

Who is Participating?
I guess you're talking abaout a database server doing asynchronous I/O or using raw devices?
Else such a setting would cost a bit too much filesystem cache, I think.
What are your "memory issues"?
Anyway, the command to use here is "vmo" (Virtual Memory Options).
To check your current settings issue
vmo -a  ( vmo -F -a under AIX 6)
and examine maxclient%, maxperm% and minperm%.
To achieve your desired settings, issue
vmo -o minperm%=10
vmo -o maxperm%=15
vmo -o maxclient%=15

To make these settings permanent across reboots add the "-p" flag -
vmo -p -o minperm%=10
vmo -p -o maxperm%=15
vmo -p -o maxclient%=15

PERM memory is used for file pages, CLIENT memory is essentially the same (with some specifics for JFS2 and NFS, which can be ignored here). The remainder is in a way "reserved" for working storage pages (%Comp).
These settings will be applied immediately, but since AIX is somewhat "conservative" in its memory management it will need some time to adjust its memory usage.
Also, the values will not really be taken "seriously". If not needed for COMP, AIX will use more memory for PERM than is set with maxperm%.
To avoid this, and to speed up memory adjustment, you could additionally set strict_maxclient = 1 and strict_maxperm = 1.
I don't recommend this, because it will cause very high page in/page out activity for a while, and will withdraw all flexibility in memory management (with the strict settings there will never be more than maxperm% file pages, regardless of whether the rest is really needed for COMP or not).
assistunixAuthor Commented:
While googling i found some information that may be related to my question

"OS automatically manages the size of Comp and Non-comp space. It decides the value depending on vmstat parameters (minperm, maxperm and numperm). numperm is the real-time value. numperm should always be in between minperm and maxperm. "

I believe that i have to change vmstat parameters to allow %COMP memory to use 85% of the memory and non comp client to use 15%.   Can someone confirm that?

Also if what stated above is correct, how would i go about changing the vmstat parameters and WHAT parameters do i have to change for my task?  (minperm? maxperm? numperm? are there any other parameters that need to be changed as well such minclient or maxpin?

Real Memory is size is 10240MB.
See my comment.
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

numperm is a calculated value and cannot be changed.
minclient does not exist.
maxpin% is by default 80% and suitable for ALL normal situations (maybe except for benchmarking).
assistunixAuthor Commented:
Hi thank you for your quick response and sorry for my comment, i wrote my comment before your reply and sent it after your reply.

So just to reiterate, to allocate 85% memory to %comp and 15% memory to non comp(client)

i need to change  three parameters
vmo -o minperm%=10
vmo -o maxperm%=15
vmo -o maxclient%=15

can you explain the- 10,15,15 value meaning?

also you said vmo -p -o minperm%=10  is for permanent change across reboots,
does that mean that vmo -o minperm%=10  is temporary only for current session and will revert back to old setting after a reboot?

Thanks again.
assistunixAuthor Commented:
it is AIX 6.1
assistunixAuthor Commented:
My Current setting are
with AIX 6.1 the query should contain the "-F" flag to display the so-called "restricted parameters" along with the non-restricted ones. Not needed with "-o".
>> can you explain the- 10,15,15 value meaning? <<

100% minus (desired value of 85% for COMP) = 15%
Thus we set maxperm% to 15. Since maxclient% is essentially the same as maxperm% we set it to 15 as well.
minperm% should be lower than maxperm%, thus we set it to 10. This value will probably not have any real influence, because with a setting of maxperm% to as low as 15 PERM will always be near 15%, I guess.
>> does that mean that vmo -o minperm%=10  is temporary only for current session and will revert back to old setting after a reboot? <<
Exactly! "-p" will create an entry in /etc/tunables/nextboot, a file which is read and executed at ... nextboot.

"man vmo" gives some good explanation, "vmo -h tunable" gives help for the specified parameter tunable, and here is the "official" IBM guide -
>> My Current settings are  minperm%=3 <<
You can leave this value as is. It's not really important.

assistunixAuthor Commented:
Thank you for that.

Coming back to the memory issue that started this question.

The memory issue that we are facing is that a component which requires about 7.5gb memory on an AIX server with 10gb real memory is getting this error

/rv/src/8_1_2/rvd/router.c:2814: Memory Allocation failed.

can you please advise on how to resolve and get around this issue.?
i thought that changing the comp memory would work but i am not sure if that is the ideal way to do so or not.

What would you suggest to would be the best way to deal with this error and resolve it?

Thank you again.

I think this isn't related to maxperm% or the like.
It could have to do with user limits.
Edit /etc/security/limits (as root) and add a stanza for the user normally running the failing program (if it's not already there) and add values of  "-1" for data, rss, data_hard and rss_hard, like this (assuming your user is myuser) -
        data = -1
        rss = -1  
        data_hard = -1
        rss_hard = -1  
Recycle the process in question, or if the user is logged in when starting it, have them logout and re-login.
If this doesn't help - is the program in question 32-bit?
If so, we might have to manipulate the LDR_CNTRL variable.
But please try the "limits" approach first.
assistunixAuthor Commented:
Thank you very much. :) for your assistance.

For now the issue has been routed back to application team, but if it comes back i will surely try the /etc/security/limits method.

All in all, thank you once again.

Your rank truly justifies you. Genius.!!!
Thank you for the points and the nice compliment.
You're always welcome!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.