1745842 Members
4370 Online
108723 Solutions
New Discussion юеВ

Kernel Parameter Change

 
SOLVED
Go to solution
ricky2
Frequent Advisor

Kernel Parameter Change

Hello,

On one our HPUX server,The application team recommends me to change the kernel paramter maxdsiz value to -1 ie it will disable all the limits that allow the system to allocate the memory as it wants.
currently this parameter is set to 2GB and this value is the system maximum allowed for that kernel parameter.
So I would like to know that by changing this parameter to -1 will be useful as the parameter is already set to maximum system value that can be provided ie 2GB.

Rgds,
Ricky
5 REPLIES 5
A. Clay Stephenson
Acclaimed Contributor

Re: Kernel Parameter Change

You need to think about the purpose of this limit. It is there to prevent a given process from hogging all the available memory and thus bringing essentially all activity to a halt. I notice that you mention maxdsiz (as opposed to maxdsiz_64bit) so that this limit applies to 32-bit processes. You can set the value beyond 2GiB but I would not set the value to unlimited. One minor programming error could bring the box to its knees.

If this is, in fact, a 64_bit process then you can set maxdsiz_64bit much, much larger. The prudent approach would be to ask the application developers what is the maximum anticipated dynamic memory allocation and set maxdsiz accordingly.
If it ain't broke, I can fix that.
Don Morris_1
Honored Contributor

Re: Kernel Parameter Change

-1 is an illegal value for maxdsiz, you can't set it to that. There is no way to disable the system checks for data size (all you can do is set them so high you're unlikely to hit them).
Bill Hassell
Honored Contributor
Solution

Re: Kernel Parameter Change

As mentioned, maxdsiz can't be -1 (that's an option in a different flavor of Unix) but note that maxdsiz is *only* for 32bit programs and these programs have extreme limits on the memory they can use. A basic program is limited to about 960 megs before it reaches a mapping limit that you cannot change in the kernel. If you compile your program as an EXEC_MAGIC excutable, then the second (data) and first quadrant (text) can be combined for a map that allows about 1750 megs maximum.

Now with (a lot of) patches for 11.00 and later, you can change an EXEC_MAGIC executable to add quadrant 3 (up to 2700 megs) and (in 11.11 or later) quadrant 4 (up to 3700 megs). If you are running 11.23, there is a new 32bit executable model (calledd mpas) that you can use in place of all the EXEC_MAGIC, q3p and q4p options. Still, the limit will be about 3700 megs.

Depending on the version of HP-UX you have and the (lack of) patches for SAM, you should be able to set maxdsize to about 3800 megs. If not, try building the kernel manually and setting maxdsiz to 3800 megs. NOTE: maxdsiz_64 *must* be larger than maxdsiz (unless you are running a 32bit version of HP-UX).

Now *ALL* of these limitations totally disappear if you write your applications as 64bit programs. In that case, you would then set maxdsiz_64 to a large value (20Gb? 200Gb?) and let your programmers go wild with malloc calls to grab all that RAM (and swap space).

NOTE: your application programmers need to read the memory mapping details about 32bit programs to get the details needed. I have attached a simple program that can be compiled 5 different ways to demonstrate the maximum memory that can be obtained. Thye comments show the compiler and chatr options.


Bill Hassell, sysadmin
Steven E. Protter
Exalted Contributor

Re: Kernel Parameter Change

Shalom Ricky,

Your application team are not systems administrators. They need to estimate their memory requirements and let you set your system up appropriately.

Here is a tuning document that actually contains some relavency on the topic:

http://www2.itrc.hp.com/service/cki/search.do?searchString=UPERFKBAN00000726&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&hpweb_printable=true&searchCrit=allwords&search.x=28&admit=-1335382922+1157656691296+28353475&mode=id&category=c0&search.y=8
The link is problematic today, please be patient with it.

Summary: Don't do it!

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
ricky2
Frequent Advisor

Re: Kernel Parameter Change

Thanks all for your reply and Ive decided not to go with the change of maxdisiz value as it has been already allocated with the maximum value.

Another paramter just recommended for the change is the o_sync_is_o_dsync which has the current value of "0" which is the default and they recommend me to change this value for "1" and I read there is a risk added by changing it to "1"
"Setting o_sync_is_o_dsync to 1 allows the system to convert any open() or fcntl() calls containing an O_SYNC flag into the same call but using the O_DSYNC flag instead. This means that the function returns to the calling process before the file attributes are updated on the disk, thus introducing the risk that this information might not be on the disk if a system failure occurs."

I didnt understand much about the description So can anyone explain me the exact risk involved in changing this parameter "o_sync_is_o_dsync" to 1?and please let me know If I can go ahead with it?

Rgds,
Ricky