Shared memory access with 64-bit HP-UX 11.0

[Neil Armstrong]

Hiya,

We're in the process of upgrading our Informix environment to 64-bit to gain access to more shared memory (large shared OLTP/batch database engine).
We're currently running Informix 9.21 32-bit, moving to 9.30 64-bit, running on a V2500 with HP-UX 11.0 64-bit. Most applications will remain 32-bit.

Previously with our 32-bit Informix environment, we enabled SHMEM_MAGIC to gain 2.75GB of shared memory. This caused a few issues (mostly fragmentation within quadrant 4), which were identified using the 'memwin_stats' and 'shminfo' tools.

Now that we'll be addressing more shared memory, are there any 64-bit specific tools available to drill into this information? Obviously the old 32-bit 4GB memory window and 4 quadrants aren't used - but are quadrants/windows used by 64-bit applications?
We've had a peculiar issue during 64-bit database testing with a shared memory pointer becoming NULL, causing the database to panic and shutdown - just wondering if there's anything to help identify why this might have happened (apart from 'ipcs').

cheers,
neil.
vodafone new zealand

[James Murtagh · Accepted solution]

Hi Neil,

Memory windows are not implemented for 64bit Apps as there is no requirement for it at present. No current application uses more than a 4TB contiguous address space. Quadrants are still used in 64bit HPUX. However, the order has been changed. Quadrant 1 is now a shared region whereas on a 32bit kernel this was the text quadrant. This was done so 32bit and 64bit processes could share the same objects.

You can use shminfo with the "-W" flag to report on 64bit address space. W stands for Wide mode (64bit) as opposed to Narrow Mode (32bit).

On HP-UX (PA-RISC) processes share memory at
the same virtual address. This allows us to maximise use of PA-RISC's
virtually indexed cache. It is this restriction that leads to
fragmentation issues in quadrant 3 and quadrant 4 with large memory
systems running 32 bit applications.

For 64 bit applications fragmentation of virtual address space
shouldn't be a problem.

In terms of the null pointer I'm not sure. I take it the server never paniced? Also, did Informix look into this?

Cheers,

James.

[Neil Armstrong]

Hi,

Thanks for the info - i'll give the -W option a go.

The server did not panic, only the database...Informix are looking at that dump but can't offer any explanations at this time.

Are you sure though that Q1 becomes the shared area for 64-bit kernels? Our HP-UX 11.0 installations have all been 64-bit (albiet with 32-bit databases and applications on top), and it has always been Q4 that has fragmented when loading shared libraries (seen via shminfo).

cheers,
neil.

[James Murtagh]

Hi Neil,

The way it works is that 32bit process address range is in the first 4 GB of quadrant 1 on a 64 bit OS. As quadrant 1 is now the shared(2) quadrant for 64 bit processes, 32 & 64 bit processes can share objects within the 2 - 3.75GB address range. This is termed mixed mode access.

So when you are running 32 bit applications on a 64 bit kernel, looking at the 32 bit processes view of memory, or the global view of 32 bit memory addresses, you will still see the fragmentation in quadrant 4.

For more detailed information, see the HPUX 11.x Memory Management White Paper.

Cheers,

James.