VMS V7.3-2 WSQUOTA maximum value

[John Abbott_2]

Hi,

I'm trying to up the size of memory caching used by our database. To do this, I need to increase the number of pages it can lock into it's working set.

Here's what we have...
Alpha 8GB memory
VMS V7.3-2 (all but DEC '05 patches)
WSMAX 4194304 pagelets, 262144 pages
UAF values
WSDEFAULT 2048
WSQUOTA and WSEXTENT 2097152
PGFLQUOTA 4194304

The process is created via a $ RUN/DETACH/AUTHORIZE.

A $ SHOW WORK for the PID reveals

Working set (pagelets) /QUOTA=1048576 /EXTENT=4194304 (Authorized the same with adjustments enabled)

I do not appear to be able to increase the process wsquota above 1048576, even if I login to the account interactively & do a $ SET WORK/QUOTA=

Have I hit a hard limit ? I've been looking through the 7.3-2 manuals... The Performance Management manual appears to suggest I should be able to at least set it to WSMAX.

Any ideas ?

PS. PQL_MWSEXTENT = WSMAX :-)

Many thanks
John.

[John Abbott_2]

Just to add that no sub-processes are created.

[Steven Schweda]

Have you set the user's WSQUOTA using the
AUTHORIZE utility?

SET DEFAULT SYS$SYSTEM
RUN AUTHORIZE
MODIFY user /WSQUOTA = xxxx
EXIT


> [...] it's working set

It is?

[John Abbott_2]

Hi Steven, yes I did. The values shown in my 1st post are actual screen scrapes from UAF, SYSGEN and a $ SHOW WORK.

Thanks for the hint tho.
Best
John.

[Steven Schweda]

So, are you trying to use SET WORKING_SET
/QUOTA to increase the value beyond what's
set by AUTHORIZE? Or is your complaint that
you can't specify a larger value using
AUTHORIZE?


alp $ help set work

SET

WORKING_SET

Redefines the default working set size for the process, or sets
an upper limit to which the working set size can be changed by an
image that the process executes. Working set limits cannot be set
to exceed those defined in the user authorization file (UAF).

[...]

[Jim_McKinney · Accepted solution]

> Have I hit a hard limit ?

Yes.

According to the I&DS (pg 940 - step 20), during process creation, the swapper sets the WSQUOTA in the process header to WSMAX or 65,536 (0x010000) pages, whichever is smaller. Since an alpha page is 16 (0x010) pagelets, if you multiply 65536*16 you'll arrive at your ceiling of 1048576 (0x0100000).

[John Abbott_2]

Thanks for that Jim, much appreciated. I was suspicious of a hard limit. What a shame :-(

... so I doubt if this was reviewed and changed in VMS V8.2 ??? (don't have a system running 8.2 yet to check).

Also does anyone know if I64 has the same limit ?

There's very little point in buying more memory if I can't use it !

It's a shame the Internals & Data Structures guide is not included in the VMS document set.

Many thanks
John.

[Jim_McKinney]

> a shame the Internals & Data Structures guide is not included

Copies can often be found for cheap on ebay...

[John Abbott_2]

Indeed... but if it was available as part of the doc set... then I'm sure there would be a IA64 Internals version too. i.e. I can only dust off my old VAX Internals or buy a Alpha one, there's no IA64 or 8.2 update available and even knowing they'll be one soon doesn't help me plan now.

I know some internals have been reviewed and "adjusted" in 8.2 but I do not know if this is IA64 specific... more likely a mixture, so I'm still in the dark.

If anyone in VMS Engineering has time to provide anything useful in reponse to my last post... I'd greatly appreciate it

Finally, not knowing how Oracle sets up very large (say over 512MB cache) memory structures (briefly) on VMS Alpha, this would also be useful too !

Kind Regards
John.

[Ian Miller.]

There are changes such as moving the working set list from the PHD which may allow a larger value. The max value of WSMAX according to SYSGEN for V8.2 Alpha and V8.2-1 I64 is the same as V7.3-2 Alpha i.e. 134217728 pagelets

I see that the default value of WSMAX on Alpha V8.2 is 524288 and I64 V8.2-1 is 784384
which is larger than V7.3-2

I think for processes using large virtual memory then they have to use P2 space as P0 is the same fixed size as always. I guess very large oracle reserved memory areas are mapped to specially created P2 regions.

[Wim Van den Wyngaert]

There's very little point in buying more memory if I can't use it !


It's only wsdefault and wsquota that are limited. wsextent can reach 4 GB (7.3).

The only problem is that you need to do some pagefaults before the working set gets increased in size. That's why I put WSINC on 100.000 so that after some faults you are allowed to increase the working set (but it can take some time).

Also check
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=971407

Wim

[John Abbott_2]

Thanks for the info

A friend with 8.2 tells me that WSQUOTA is still limited to 1048576 on IA64 and Alpha.

The database uses a global section file and has to lock the needed space into WSQUOTA, for some reason WSEXTENT doesn't help, even if I do a $ SET WORK/QUOTA=/EXTENT=/NOADJ to the max and adjust WSINC to a high value.

Useful ref link for P0/1/2 VLM etc.
http://h71000.www7.hp.com/doc/72final/6467/6467pro_002.html

Looks like a change enhancement request to a vendor is required...

[Jim_McKinney]

Here's a thought... if you're willing to adopt a solution that would not be supported by HP, Ken Adelman (of TGV fame) long ago posted the source to a program that could adjust the working set parameters for a running process. It presumed that the target process was not the invoker. The program was written for a VAX but could be ported to Alpha. For your needs, it could also be simplified quite a bit if the the code were to execute in the context of the invoker rather than another. That would eliminate the need for storing and queueing up the KAST code. It would only be necessary to jump into kernel mode and adjust the various working set related values in the process' own header as Ken demonstrates in his code. The code could perhaps be invoked from the LOGIN command procedure of the DB server before the DB is accessed. You can find Ken's code at http://groups.google.com/group/comp.os.vms/browse_frm/thread/5199eeb4c0b0a786/

[Ian Miller.]

that program reminded me of this
ftp://ftp.process.com/vms-freeware/fileserv/eset.zip
which I wrote a long time ago and have not
touched for years.

I think you need to work with hp on this as the there been various changes in memory management in recent versions and parhaps there is more to do.

[John Abbott_2]

Thanks, worth a nose into... also reminds me that Availability Manager might help with process adjustments too.

John.

[Jim_McKinney]

AMDS is probably too late in the game if it can alter the WSQUOTA in this way... I presume that you need WSQUOTA set prior to the process accessing the database?

[Jim_McKinney]

I was a bit curious about this and looked a bit more at the I&DS. I learned that the 64k page maximum (1048576 pagelets) for working set quota exists becuase the maximum size of a swap slot is also 64k pages. One implication being that if you were to raise WSQUOTA above this limit, any attempt by the system to swap a process above this limit would likely be fatal. (I post this just as an fyi as I expect that for your environment, swapping is not likely a concern.)

[Jan van den Ende]

John,

to circumvent the noted fatal problem noted by Jim,
$ SET proces/NOswap/id=...
(which of course is a privd command, needs PSWAPM)

hth,

Proost.

Have one on me.

jpe

[John Abbott_2]

Thanks for the info and the code links. In the test lab I will play with trying AMDS 1st (I can put a delay before the cache is created for testing), I suspect it will only allow up to the limit anyway.

Time permitting I'll see what use the code link will bring, but I now have the oppotunity to meet the developers in March, so I will raise some questions about P0 P2 space then. This is really my next focus.

I got bitten by the swapper in the test lab years ago when the DB process was swappable and I increased the cache & cause swapping problems on a puny swap file.

Of course nobody want their DB swapped out, so it's already /noswap, but thanks for the hint.. that's what I like about this forum (juicy bits and reminders) :-)

[John Abbott_2]

WSQUOTA limited to 1048576 on Alpha and I64.

VLM application should consider using P2 space.
See:
http://h71000.www7.hp.com/doc/72final/6467/6467pro_002.html

Hope to review with developers in March.