Caching

[Wim Van den Wyngaert]

Has anyone still an idea / test result of what the impact of the "set RMS" parameters are in VMS versions of today ? Especially with the VIOC or EFC enabled.

[Jan van den Ende]

Wim,

You really missed Hein's presentation in Brussel yesterday, have you? To me, it really was worth the trip.

One of the things he stressed was the amount of performance you can win with RMS buffers, especially with bigger files, and the effect gets more extreme as a measure of the number of keys!
The slides are distributed among the attendees, and if you give your email address I can forward them.
I am sure Hein won't object.

Jan

[Wim Van den Wyngaert]

Use spapimpelmees@pandora.be but without spa.

Thx

[Art Wiens]

Would it be possible to post them somewhere? If not, I would appreciate a copy aw42pc@dropthispartandthenextdot.shaw.ca

Thank you,
Art

[Jan van den Ende]

Hein,

how about posting?

(zie je wel, je geeft ze een helpend handje, moet je gelijk je vingers natellen!)

Jan

[Jan van den Ende]

All others interested:

the slides "will be posted" at
<> under the topic "Club Activities"
(but I just tried and got a
"error on page"
so maybe not everything is ready yet)

Hein, by the time you are ready to try, if it still ain't working I guess you will know whom to contact...


Happy tuning!

Jan

[Wim Van den Wyngaert]

Jan,

The address is http://www.cuo.be/Club_Activities/Agenda/Agenda_2004/AGENDA_2004.htm#SecondQ2004
but I didn't find the presentation itself. But I got the mail.

It is very good for indexed files but these are not actively used over here.

I'm interested in knowing if the RMS buffering isn't bypassed by other caching mechanisms. And not only for indexed files.

Also : which kind of directories should I mark as "no_cache" ?

[Wim Van den Wyngaert]

Did an experiment.

$i:
$ sea *.log qqqqq
$ goto i

After some time
$ show mem/cac=(tophit...)

Although heavily used, the *.log was not in cache (current size 86 MB). Why ?

[Hein van den Heuvel]

I'm glad to hear you also thought we had a nice meeting in Brussels. I know I enjoyed myself!

I used my HPworld 2004 presentation 2445.
A slighty older (Compaq, not HP) version of the presenation is already available on the Freeware V5 CD and online as:

http://h71000.www7.hp.com/freeware/freeware60/rms_tools/rms_tuning.ppt

Indeed, this presenation focusses on indexed file as this appears to be the most challenging area.

For sequential (and relative) files you can also set up local (or GLOBAL!) buffers.

The big advantage of having blocks in the RMS buffers versus a fle system buffer is that RMS does not have to issue a QIO, it is 'closer' to the data, and no memory copy is needed to move it from XFC to RMS.

In general (Your Milage May Vary!) sequential file a read from the beginning to the end and closed. For example your login.com or an object being linked against (over and over). One does not try to cache such file in RMS as you do not come back ( in the same image) and after the close RMS 'forgets' its cache. Exception: Global buffers with some process keeping the file open.

IF you are using a private databases like structure in a sequential file, with pointers and offsets and where you do you back and forward, then adding lots (200?) of local (or global) buffers should work better than the XFC cache.

For 'normal' sequential file use the default (32k now) is reasonable.
If you are performance sensitive and memory rich and have a decent IO systems (All this applies to many VMS systems) then you may want to bump the size of the buffers for more effectiver IO subsystem usage. And you may want to increase the number for improved Read-Ahead and Write-Behind performance.
So I generally recommend:

SET RMS/SYS/SEQ/BUF=4/BLOCK=100

BUF = 2, 4, 8, even, odd... your call. 'knee' tends to be 4
BLOCK = 64, 100, 127... your call. Max is 127.

Please provide more input about typical file usage for better advice.

hth,
Groetjes,

Hein.

[Wim Van den Wyngaert]

Hein,

Our IO system is mostly taken by Sybase dumps. They dump Giga's of data into flat files.

Secondly, many programs are used to read rather big files (100M+).