Oracle on IA64 uses 10x more memory than PA-RISC

[Ryan Kogelheide_1]

Does anyone know anything about a problem with the compiler in 11.23? The Oracle user processes are HUGE compared to PA-RISC. Something to do with the data segment allocations (for Oracle, that means PGA). Oracle says it is not just a bug in the HP compiler, but inherent in the architecture. They say that with optimizations they can reduce the size by up to 25% in the next release of Oracle, but by my estimate, we're seeing 2 to 10 times the memory consumption.

Is this a permanent problem or a bug? Whose fault is it?

[rick jones]

Given that HP's Oracle TCP-C results on 11.23 (BTW, 11.23 could be either PA or IPF these days) IPF are not using 10X the RAM of TPC-C results on PA-RISC, there may be something else going on.

IIRC this may have come-up in comp.sys.hp.hpux - some of it may be differences in how the stack is managed between IPF and PA making it appear that more memory is in use. A search of old comp.sys.hp.hpux postings might be useful.

[Ryan Kogelheide_1]

Hi Rick, thanks for your help on this. My database is definitely showing much larger memory use. Perhaps I am measuring wrong, but if so, then Oracle is as well. Can you tell me how to correctly measure the memory used by a process?

Also, I can't find a good place to search the usenet group you're talking about. Can you suggest one and suggest what I should be searching for?

[rick jones]

groups.google.com is one place to do netnews searches. also, the comp.sys.hp.hpux faq is archived at ftp://rtfm.mit.edu/ under something like pub/usenet/comp.sys.hp.hpux.

As far as measuring memory consumption, glance is probably the easiest/best way to do it. You will want to check which memory regions are private and which are shared. If you do not already have Glance, you can I believe download a timebombed trial version from software.hp.com. Otherwise, if you are handy with a compiler (and have a compiler :) you might write a program to make some pstat() family calls.

Also, if your PA-RISC stuff was 32-bit, there will be at least some increase for going to 64-bit (Or does Oracle ship a 32-bit IPF DB?) because anything of type "long" and pointer is now 8 bytes instead of 4.

Other straws at which to grasp and examine might include:

*) settings of vps_pagesize and vps_ceiling and such

*) the page size attributes of the binaries (chatr)

[Duncan Edmonstone]

Ryan, did you ever get a resolution to this, or is it still an issue for you?

I'm seeing something similar on an IA64/Oracle system.

Thanks

Duncan

[Duncan Edmonstone]

OK - so the whole issue is discussed in some detail in the 9iR2 release notes for IA64 here:

http://download-uk.oracle.com/docs/pdf/B10566_05.pdf

Section 6.1, page 21

Duncan

[Ryan Kogelheide_1]

Sorry for not responding sooner.

We resolved most of the problems by upgrading from 9.2.0.5 to 9.2.0.6.

I didn't get time to go through all the release notes, but I still didn't see why it was so dramatic on IA64 and not PA-RISC.

[Duncan Edmonstone]

OK, I'm still seeing a problem even with 9.2.0.6 and making the 'chatr +pd' chnage suggested in the oracle release notes. Anyone else on IA64 seeing this issue? Anyone just on IA64 willing to post the output of the following?

UNIX95 = ps -eo vsz,comm,args | grep [o]ra | sort -rn

We are seeing vsz sizes of between 128 and 180MB! Running chatr makes no significant difference. Anyone using PGA_AGGREGATE_TARGET to resolve this, what about CURSOR_SPACE_FOR_TIME setting suggested in bthe release notes?

Thanks

Duncan

[Mike Stroyan]

The stack mechanism on HP-UX 11.22 and 11.23 creates a region covering the complete virtual address range covering the maximum stack size. That is specified by the maxssiz and maxssiz_64bit kernel tunables.

The stack region is marked with a lazy swap attribute. That means that it does not use any RAM or swap for addresses until each page is first referenced. The effect is that the VM size reported by glance and top looks really large, but there is no additional resource use besides a few page table entries in the kernel.

There is no known link between the large stack VM size and any performance problem. (But it is linked to a lot of questions. ;-)

You could try changing the maxssiz and maxssiz_64bit kernel tunables to see how it affects the the ps vsz number. Remember that setting the limits too low could break programs. Because of the lazy swap allocation the large limits should not be causing any resource problems.

The ps vsz numbers sum just the total size of the text, data, and stack regions. It does not include the size of shared memory and mmap regions that could be very large for applications like oracle. The numbers from ps don't really represent the whole picture. Newer releases of top include more regions in the 'SIZE' number that otherwise corresponds to the ps vsz number. For a PA-RISC system you would need patch PHCO_26020 for 11.00 or PHCO_25204 for 11.11 to match the sizes reported by an 11.23 top. Those patches started to include additional regions in the 'SIZE' calculation.

[Duncan Edmonstone]

Thanks Mike, I'll take a look at where we have these parameters set and see if we can adjust. However as we *are* seeing a considerable amount of pressure on swap ,my first guess would be its not the stack size thats causing our problem. I will though take a look... Where is the information documented Mike - is it in the 11.23 release notes anywhere?

wish I could assign points for a very lucide response - but noy my thread I'm afraid.

Thanks

Duncan