Showing results for 
Search instead for 
Did you mean: 

maxdsize_64_bit value?

Go to solution
Mott Given
Frequent Advisor

maxdsize_64_bit value?

Our maxdsize_64_bit had a value of 0x0000000090000000 - what does this number equal in decimal value(in bytes)?
Its current setting on an N4000 4-cpu 4GB ram system is 589824.
Was this an increase or decrease in its value?

It seems that some of our kernel settings got changed when some patches were installed on ISS. Is ISS known for doing this? The patches for it seem to have changed our kernel drastically, eg. dbc_max_pct went from 5 to 50!

Mott Given
Patrick Wallek
Honored Contributor

Re: maxdsize_64_bit value?

That value = 2,415,919,104 bytes or 2.25 GB.
Honored Contributor

Re: maxdsize_64_bit value?

printf "%d\n" 0x0000000090000000

will give you value in decimal.
There is no substitute to HARDWORK
A. Clay Stephenson
Acclaimed Contributor

Re: maxdsize_64_bit value?

Rather than answering directly, I'll let you do it using bc.


That will then output the decimal (default output base or obase) with the input base (ibase) set to 16.

When finished, enter "quit".

Man bc for details.
If it ain't broke, I can fix that.

Re: maxdsize_64_bit value?

The others answered your question about the maxdsize_64. To expand a little this is the max data stack size (memory) for 64 bit applications. Most database softwares will require you to increase this (plus other) kernel value so the software can utilize a large chuck of your available memory. So if you have 4GB of RAM, and you would like to make 3GB available to shared memory, you would have to change the value to something higher than you currently have. Also just to note, if you use SAM to look/change your kernel values it will make the conversion to number in bytes. But again these changes are usually documented in your database (or other) applications install guide if you have a memory hungry application.

Now as far as the dbc_max_pct value this is defaulted at 50. It seems the patch you loaded set it back to default. This is one of my biggest pet peeves about HP-UX. I learned in a performance tuning class that you can set the bufpages value and this will override your max/min_dbc_pct values to a static size. Off the top of my head the instructor stated that you really dont need more then 400-500MB for FS buffer cache. Obviously you would want to give this some thought if your system is mostly a fileserver. But if you run Sybase (or other RAW devices driven app) you may not need as much. But I feel that on most larger memory systems 50% is too much.

Hope this helps a little...

T. M. Louah
Esteemed Contributor

Re: maxdsize_64_bit value?

for maxdsiz_64bit here is where you should start:

User programs on HP-UX systems are composed of five discrete segments of virtual memory: text (or code), data, stack, shared, and I/O. Each segment occupies an architecturally defined range of the virtual address space that sets the upper limit to their size, but text, data and stack segments may have smaller maxima enforced by the maxtsiz, maxdsiz, and maxssiz tunables.
This tunable defines the maximum size of the static data storage segment for 32-bit and 64-bit processes. The data storage segment contains fixed data storage such as globals, arrays, static variables, local variables in main(), strings, and space allocated using sbrk() and malloc(). In addition, any files memory mapped as private and shared library per-invocation data also resides in the data segment.
When Should the Value of This Tunable Be Raised?
This tunable should be raised if user processes are receiving the ENOMEM error message:

exec(2): data exceeds maxdsiz
exec(2): data exceeds maxdsiz_64bit.

This may or may not cause a process failure depending on the program code.

What Are the Side Effects of Raising the Value?

Raising this tunable by definition allows larger data segments for every process. The maxdsiz and maxssiz tunables limit the amount of swap space that can be reserved or used by each process, but using more virtual address space does not translate directly into using more physical address space because virtual pages can be swapped out.

Note that if swap space on the machine is near capacity, raising this tunable increases the amount of reservable swap per process. This could exhaust the swap space on the system by allowing a process with a memory leak or a malicious program that uses huge amounts of memory to reserve too much swap space...
Please take the time to review some could technical docs on

for the dbc_max_pct, the best metrix is to run :
# sar -b 5 100
ideally you should see that %wcache is 95% or greater that means system is set in an optimal fashion. if the system shows consistently average(s) of 75% or lower you may consider lowering dbc_max_pct, check it out:

Little learning is dangerous!