More memory usage using 32 bit

[Sathya Sastry]

I have a situation, where I have application built with 32 bit libraries and compile options.
By using +q3p and +q4p I am able to make the process use greater than 3GB, but there is a requirement to increase this more than that.

Any Clues, trick or tips.

Regards,
Sathya.

[Tim Adamson_1]

Hi Sathya,

What version of the OS are you using?


Cheers!

[Sathya Sastry]

It is 11i, running 64bits HP-UX.

[James Murtagh]

Hi,

The +q4p (quadrant 4 private) feature was only introduced on the 64bit 11i kernel so you must be using that. When you say you have more the 3GB already can I assume the binary was linked using the EXEC_MAGIC feature (ld -N)? If so you have to go to a 64bit layout, you have used every trick and space in the 32bit process VM layout. If you haven't used EXEC_MAGIC then, depending on how much text the program and libs use then you might be able to have the bulk of the extra 1GB in quadrant 1. If you don't know you can use odump to check the magic number, see "man magic" for a reference. Also ensure maxdsiz is sized accordingly and you have enough swap for such a large data area.

Regards,

James.

[Mike Stroyan]

This is just a clue that may or may not give you a little more space. Programs linked on 11.00 or later can have their malloc settings changed by setting the _M_SBA_OPTS and _M_ARENA_OPTS environment variables.
The _M_SBA_OPTS setting can be used to cause different treatment for 'small blocks'. Applications that mix allocating and freeing large and small amounts can cause fragmentation of the address space. Larger and larger realloc calls can keep getting additional data space because the previously allocated areas are blocked from growing by smaller areas. The small block allocator can segregate those small allocations into groups, getting them out of the way.
The _M_ARENA_OPTS setting can affect how many separate memory arenas are used for multithreaded processes. The multiple arenas reduce the amount of locking contention between multiple threads calling malloc functions. Reducing the number of arenas might reduce the total memory usage.
These environment variables are documented in "man malloc".

[Jeff Schussele]

Hi Sathya,

The best tip I can give you in this situation is - PORT THAT THING TO 64-BIT.

4 GB is the MAX adressable space in total. That not only includes data, test & stack of that application, but ALL applications *including* the OS.

If you really need *more* than 3 GB for this app you really must recompile this thing for 64-bit.

My $0.02,
Jeff

[A. Clay Stephenson]

If you have 32-bit libraries then , as mentioned, 4GB is the absolute top limit. If only 32-bit libraries are available then one "trick" that you can use is to compile and link a standalone 32-bit application that is launched and managed by a parent 64-bit process. You then make all your requests via pipes (or shared memory or messages) from the 64-bit parent to the 32-bit child. This allows you to link the 32-bit application while at the same time allowing a much larger overall process. It's a bit tedious but it should work. In the past, I've had to do things like this to get very diffent databases to talk to each other.