buffering rightslist.dat

[MarkOfAus]

Hi all,

How can I RMS buffer rightslist.dat? I can boot off a CD, I guess, but is that the only way?

Any ideas, hints?
Thanks

[David Jones_21]

If your question is how can you set global buffers on rightslist.dat, one way would be to use analyze/rms/fdl to get a description of the file, edit the FDL file to change the gbc value, then create a new version of rightslist.dat with convert/fdl. Finally, do a reboot to make the processes use the new version.

[MarkOfAus]

Yes, apologies, I meant set global RMS buffering on the rightslist.dat file.

[John Gillings · Accepted solution]

Mark,

As of V7.3 (or thereabouts) you can execute a SET FILE/SHARE/GLOBAL=n against an open file. It won't take effect until the next time the file is opened, but you won't get a "file locked" error.

See HELP SET FILE/SHARE

To get full benefit for RIGHTSLIST, issue the SET FILE/SHARE, then reboot.

Also as of V7.3 there are significant performance benefits to having some global buffers enabled on any shared file, even apart from the buffering. Quote from Hein "there is only one INCORRECT value for global buffers - ZERO".

As of V8.2 you can also SET FILE/GLOBAL=PERCENT=n to specify a percentage of the size of the file, rather than a fixed number of buffers. Global buffers are also in P2 space, which eliminates the main limitation on using global buffers.

If you're on an older version you could CONVERT/SHARE the existing file to a new version, then SET FILE/GLOBAL, then reboot (immediately, so you don't accumulate any new changes in the active file).

[Hein van den Heuvel]

Just use $SET FILE/SHARE/GLOBAL=50
Any new process will pick it up.

After a future reboot all will pick it up.

If you can, restart SECURITY_SEVER, AUDIT_SERVER or QUEUE_MANAGER as those keep RIGHTSLIST open, and with that keep the global buffers alive. I tend to use a dedicated process to keep files with global buffers and RMS stats open, to make sure those global sections do not get dropped in a slow moment

Might as will toss in a /STAT for a while.
... if you are ever goign to look.

Global buffers on RIGHTSLIST often helps,
Global buffers on SYSAUF even more so.

You may also want to tune both, making sure the index levels stays at just 1.
I like a large index bucket and small data bucket for SYSUAF.

I find it often 'good enough' to just convert them and put a new version in place, allowing existing processes to keep on using the old version. Of course that will not work when adding (lots of) users.

That also works on older VMS versions where /SHARE was not available.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Hein van den Heuvel]

Ah... notes collision!
(Good memories of VAXnotes serving VAXWRK::VMSnotes... right John? :-)


John wrote>> reboot (immediately, so you don't accumulate any new changes in the active file.

The processes keeping the SYSUAF and RIGHTSLIST are not the ones making changes best I know, so IMHO there is no great rush, as the changed will go to the new file. But of course you do need those older processes to see things like new usernames, UIC, rights and changed settings in general.

btw... I have recently seen one problem with global buffers. With 8.2 RMS re-uses process regions which nicely avoid potential address space laddering (VASFUL). unfortunately this was broken in 8.3 with the P2 chancges. Any unpatched 8.3 system will create those regions, but never re-use then. This may cause process failures with RMS$_DME if (and only if) a single image frequently opens and closes files with global buffers. This can be indirect... for example JAMS and MULTINET re-opened SYSUAF through $GETUAI and failed after several hours usage. There is a fix for RMS V8.3, and the two products mentioned have been taught how to use the CONTEXT param for GETUAI thuse avoiding the OPEN/CLOSES of GETUAI, making the (OpenVMS) world a sligthly better place.


Hope this helps some more,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[MarkOfAus]

Hein & John,

Thank you very much for your answers; superb!

Incidentally, I'm on 7.3-2. Mostly, the topdio on the device shows rightslist.dat is being hit hard - every user, rdb and so on has the rightslist.dat open, but only TNT_SERVER and queue_manager have the sysuaf.dat open continually.

Perhaps for another topic is has anyone had experience with rightslist.dat on a ram disk?

Regards,
Mark

[Hein van den Heuvel]

>> Perhaps for another topic is has anyone had experience with rightslist.dat on a ram disk?

And that from a guy who started out asking how to set global buffer in the first place... how will you get it onto the ram disk if you do not even know how to set gloabl buffers on it huh?

Rightlist on ram disk is just silly.

Go wash your mouth!

:-) :-)


Global buffers will completely avoid all the (read) QIOs, not just speed them up, and global buffers will also turn the locks into CONCURRENT READ locks, thus reducing lock overhead on the box.

Sysuaf might not be kept open by so many for so long, but that almost makes it MORE of candidate for gloabl buffers. Without global buffers each new process create will read through the index from the start. With global buffers the bulk will be ready to be used.

The rightslist users keeping the file open will have the (root) index bucket cached in local buffers and will not benefit that much.

Still, like you you indicate, a DIRIO monitor, or SHOW MEM/CACH=(TOPQIO=50,VOLUME=device_with_rightslist) will tell you where to focus tuning efforts.

Hein.

[John Gillings]

Mark,

>Perhaps for another topic is has anyone
>had experience with rightslist.dat on a
>ram disk?

No direct experience, but you need to be careful as ram disks are volatile! With sufficient global buffers, you should get the same effect. Even without global buffers, XFC should help for read performance.

Another possibility - if you have SAN storage is to make a small disk to contain just your cluster "personality" files (they don't take up much space, but there are more of them than you think!) you could then shadow them with a RAM disk to get the read performance of the RAM disk, but avoid the volatility. Write performance will be limited by the speed of the real disk.

[Thomas Ritter]

RAM disks are not available cluster wide.