Article 152132 of comp.os.vms:

In article <750335472wnr@nugate.demon.co.uk>, Dave Pickles <davep@nugate.demon.co.uk> writes...
>I'm building an application which will use several large (gigabyte-ish) 
>indexed RMS files, running on a small Alpha server.
> 
>Small-scale tests have shown the importance of having sufficient RMS buffers 
>available, especially when loading data.

Loading data should be delegated to CONVERT/FAST [/SORT] 
Anytime you intend to add more than say 10% of the current number
of records to a file, you are likely better of converting.
The only gotcha might be when constant file access is required.

Lotsa buffers may well help, but before doing so, doublecheck that
the file is properly tuned (bucket sizes sufficiently big, pre-allocated,
avoiding short kalternate keys with lotsa duplicates)

> Ideally I'd like to use a few 
>thousand, to cache all the index trees and still give a useful hit rate on the 
>data buckets. 

I doubt it. But it could be...

> However it seems that RMS has a limit of 127 local buffers per file. 

Wrong, that would be 255.
You can ask for up to 32K through and XABITM.
Connecting more than 1 stream also puts extra buffer in the pool


>I can have 32767 global buffers, but global buffers are effectively 
>ignored when deferred_write is enabled.

Nonsense. When deferred write is being used, the index buckets and data
buckets that your read leading to the target record are all cached in
the global buffer cache, and may be found there. Only when the data bucket
is updated will it be copied out of the global buffer cache to a local
buffer and cached there from then on, untill an other process needs to
read it at which point it will go back in the global buffer cache
albeit pinged via the disk.

I would caution you NOT to jump to 32K global buffers. Try 500, 1000, 2000,
4000, 8000 first. The lookup times may hurts application with several
thousands of global buffers on an Alpha (several hundreds for VAX)

>My question is, how can I best use the memory I've persuaded my client to buy 
>for this system. I particularly need to optimise performance during data 
>loading.

More memory never hursts. Still...

GLOBAL buffer tend to give memory back in a concurrent usage scenario.
For example, if there are 200 users with 10 local buffers each, then
some 500 global buffers may well replace 2000 local ones.

If the loading can not be done using a convert, then you may want a 
'reasonable' number (200?) of global buffers for the other users and 
to cache frequently used parts of the index and data structures (also
for the benefit of the loader) and then give the loader 200 or more
local buffers. Note.... presorting the data to be loaded should help
deferred write effectivnes

>Secondly, is there any useful documentation on setting up systems of this 
>type. Sadly the orange and grey walls had to go due to lack of space.

I'm not convinced you have a lack of space. You _did_ check the 
guide to file applications sections on indexed files right?

Check my RMS_TOOLS on the FREEWARE CD. Notably RMS_STATS and SIDR.


Hope this helps,		+--------------------------------------+
Hein van den Heuvel, Digital.	| All opinions expressed are mine, and |
  "Makers of VMS and other	| may not reflect those of my employer |
   fine Operating Systems."	+--------------------------------------+