02-14-2005 09:16 PM
Is this a permanent problem or a bug? Whose fault is it?
02-16-2005 03:28 AM
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.
02-24-2005 10:08 PM
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?
02-25-2005 04:38 AM
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)
06-09-2005 12:00 AM
I'm seeing something similar on an IA64/Oracle system.
06-09-2005 12:58 AM
Section 6.1, page 21
06-13-2005 02:01 AM
We resolved most of the problems by upgrading from 188.8.131.52 to 184.108.40.206.
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.
07-14-2005 01:04 AM
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?
07-18-2005 03:54 AM
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.
07-18-2005 05:04 PM
wish I could assign points for a very lucide response - but noy my thread I'm afraid.
07-19-2005 06:31 AM
We do see significantly less memory use after 9206, so I'm not sure why you're still seeing problems. I'll try to do some diags tomorrow and post it here.
07-19-2005 11:08 PM
There is no mention of the change in apparent stack VM size in the official documentation. It seems that the difference was expected to be too subtle to notice. Of course, folks looking at ps vsz or other VM size metrics do tend to notice it.