topic Re: P0 address space in Operating System - OpenVMS

P0 address space

Wim Van den Wyngaert — Mon, 23 Feb 2009 10:21:14 GMT

FREP0VA : First free page at end of program region (P0 space).

I find a process for which it's at %X38ae2000.
Thus almost the limit of 1 GB.
It's a Sybase db server on 7.3.

What does it exactly means in "VMS for dummies" words ?
Can it increase or is it static ?
Can it be almost 1 GB when a program starts ?

Wim

Re: P0 address space

Volker Halle — Mon, 23 Feb 2009 12:09:23 GMT

Wim,

the per-process P0 address space ranges from virtual addresses %x00000000 to %x3FFFFFFF. The value returned for F$GETJPI(,"FREP0VA") is the virtual address of the first free page in P0 address space (from the process header field PHD$L_FREP0VA) above the P0 space currently used by the image.

$ ANAL/SYS
SDA> SET PROC/IND=
SDA> SHOW PROC/PHD ! shows this as...
...
First free P0 VA 00000000.00332000
...
SDA> SHOW PROC/PAGE 332000

will show a 'null page'

The FREP0VA value can increase, if the image running in this process expands it's P0 address space. If the image tries to expand P0 space beyond the architectural limit of 1 GB, it will get: VASFULL, virtual address space is full.

Depending on the size and attributes of the image and the number and size of shareable images activated, sections mapped etc. this value could be near 1 GB after image startup, but that is unlikely. Look for image virtual address space layout with SDA> SHOW PROC/IMAGE.

Volker.

Re: P0 address space

Wim Van den Wyngaert — Mon, 23 Feb 2009 12:30:14 GMT

Volker,

It stays on the same value. But other processes running the same exe with the same user name on the same node have lower values (but still 0.5 GB). Only their quotas are different. Is the db cache mapped in P0 ?

Show proc/ima says 1017 pages allocated for 14 images.

Wim

Re: P0 address space

Volker Halle — Mon, 23 Feb 2009 12:48:22 GMT

Wim,

I'm not running Sybase, so I can't check. There was some ITRC discussion 3 years ago about the 1 GB limit in Sybase:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1082602

Maybe the DB is mapped via global sections ?

Volker.

Re: P0 address space

Hein van den Heuvel — Mon, 23 Feb 2009 12:52:44 GMT

Hi Wim,

Is there an actual problem, or just curious and cautious after the recent VASFUL topic here in teh forum ( http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1316112 )

I do not know Sybase, but I suspect Sybase mapped some global section into high memory to share with absolute addressing instead of proper relative addressing. That was a common technique folks use back in OpenVMS V4, V5 days.
Oracle used to do that as well.
INSTALL may be able to see the sections.
ANAL/SYSTE ... SET PROC
Then , as Volker indicates, use SHOW PROC/IMAGE to get a lay of the land, and SHOW PROC/PAGE and SHOW PROC/PROCESS_SECTION to drill down on details.

Hein.

Re: P0 address space

Wim Van den Wyngaert — Mon, 23 Feb 2009 12:59:04 GMT

Shame on me (or better, my memory). It seems that the db is mapped via p0. Thanks Volker.

I will exclude dataserver from the monitoring.

Wim

Re: P0 address space

Hein van den Heuvel — Mon, 23 Feb 2009 12:59:08 GMT

Wim,

You may want to check the SYBASE scripts for INSTALL, STARTUP or LINK for variables/logical like "_BASE" or "_ADDRESS".
If that does not give something 'obvious', then look for strings in the images.

Please find attached a little MACRO tool that can be used to hunt through binary data files like oobject or images to look for 'words'. It is much similar to the Unix tool 'strings', but I'd like to think it does a better job at avoiding false positives.

Hein.

Re: P0 address space

Wim Van den Wyngaert — Mon, 23 Feb 2009 13:06:25 GMT

Hein,

Dataserver is never relinked. It's not even installed. No successwith the search.

Wim

Re: P0 address space

John Gillings — Mon, 23 Feb 2009 23:58:18 GMT

Wim,

> Can it increase or is it static ?

FREP0VA can increase or (in rare cases) decrease over time. P0 expands with $EXPREG and (may) contract with $DELTVA, but only if the VA being deleted is at the end of the region. In practice contraction is rare. Most of the time FREP0VA will be monotonic increasing, and hopefully asymptotic to a reasonable maximum.

>Can it be almost 1 GB when a program starts ?

Certainly. It can be any value up to the maximum PHD$Q_P0_REGION_SIZE (architecturally set at %X40000000). For example, a process with a large static allocation could start with a large initial value.

In practice, most observed expansions are probably allocations from heap memory, malloc or LIB$GET_VM. If malloc cannot satisfy the request from its local cache, it will call LIB$VM_MALLOC or LIB$GET_VM, which may need to call LIB$GET_VM_PAGE to expand the heap, which may need to call $EXPREG to expand the region in which the heap is defined (by default P0). If $EXPREG fails, it will return SS$_VASFULL.

There is no simple way I know of to move the default heap out of P0 space. You need to explicitly code 64 bit pointers and allocations from P2 space.

In your case %X38AE2000 is rather too close to the limit for my liking, but if FREP0VA isn't increasing over time, it's not a problem. If it were code under your direct control, I'd be recommending moving some of the data structures into P2 space.

Re: P0 address space

Hein van den Heuvel — Tue, 24 Feb 2009 14:04:47 GMT

On th efailign memory... for grins:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1082602

Just for curiosity, what is the 'total memory' setting for the server running close to 1GB?
If you have the time, you may want to try to bring up a sybase instance with say 10MB for the "total memory" parameter with sp_configure, one with 100MB. Observe the FREP0VA for each, and the current one, and put in a little table.

Thanks,
Hein.

Re: P0 address space

Wim Van den Wyngaert — Tue, 24 Feb 2009 14:12:25 GMT

Hein,

No longer have permission to play with Sybase (SOX). Total memory of the server is 460800 so close to 900 MB. As expected.

Note that the thread was during the end of year so I must have missed it (or was too drunk).

Wim