All kind of bufferings

[Wim Van den Wyngaert]

Probably a Hein question.

What is the gain of global buffers when extended file cache is used ? On my AS500 the rightlist reads are almost all served by the efc. Only reduce some overhead ? Isn't efc more practical because it will decide itself which files are good to be cached ?

Wim

[Karl Rohwedder]

One thing that comes to mind; with global buffers you have better control, what will be cached. The XFC may get trashed by accessing some big files.

regards kalle

[Robert Gezelter]

Wim,

I would agree. RMS Global Buffers are a finer tool than the XFC, which only knows about raw disk blocks.

Think of it this way: RMS Global Buffers are, in a sense, an L1 cache, if XFC is enabled, it acts as a L2 cache.

Remember, Global Buffers can be effectively keep your indices in core, because it knows what an index is. XFC does not.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel · Accepted solution]

The XFC cache is good, very good.

It's biggest limitation however is that it does not support actively write shared files in a cluster.

To witt, it works wonders for RIGHTSLIST, but not so good, and sometimes not at all for SYSUAF.

That it works at all for SYSUAF is because is does 'keep on trying. But as soon as it sees an active write to a cached file on an other node, it will discard any pages with cached data for that file on the current node.

The XFC is a whole lot better than the old VIOC which disabled caching as soon as a file was opened allowing writes on an other node, even if that other node never did a write.

RMS Global Buffers will give you cached data for cluster wide write shared files. Of course the data for a block which is changed can only live on one node, but all those indexed blocks which did not change can be ready in memory on all nodes.

The management for the data consistency is with the exact same BUCKET LOCK as used for RMS Local buffers, so no extra overhead there.

In fact, the second big reason to use Global Buffers on single nodes or clustered nodes is that the added structures for global buffers allowed RMS to use more then just the EX lock mode it uses for local buffers.

For Global buffers RMS Caches the locks for the cached data in CR (Concurrent Read) mode. For example: That 'root' bucket all users go through on their way down to specific data, but which rarely (once a month?) changes, will just always be there ready for use!.
For local buffers the locks are cached in NL (Null) mode and are always upconverted to EX (Exclusive) before looking at the data, and back down to NL when done with a bucket.

So RMS Global Buffers, unlike XFC, has the POTENTIAL to dramatically decrease RMS Bucket Lock activity in a cluster. Bucket locks are at least 2x more frequent than record locks, and often 10x more frequent ($put into multi-key file).

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

[Wim Van den Wyngaert]

Hein,

I was right. It is a Hein question.

If not in a cluster, XFC could compete with EFC or is it still significantly better ?

Wim

[Hein van den Heuvel]

>> I was right. It is a Hein question.

There are plenty of others who could answer that question, but when you mentioned RMS...

>> If not in a cluster, XFC could compete with EFC or is it still significantly better

Sorry, I don't know what you mean with XFC vs EFC. What is Efc? The X in XFC is short for eXtended.

The VIOC alternative should be avoided.
XFC is the way to go.

For some applications a commercial tool like Raxco's Perfect Cache (part of its "performance suite" http://www.raxco.com/products/performancesuite/index.cfm ) might be the best choice.
I seem to recall it does LBN caching, not VBN caching and allows concurrent write access to the drives in a clusters.

As far as bang for the memory buck, database caches like RMS (global) buffers, and Oracle SGA, informix, ... ) are often a better place to allocate memory than a file ir disk disk.

Hein.

[Wim Van den Wyngaert]

Sorry for the confusion. I mean can XFC compete with global buffering when not in a cluster.

[Hoff]

Different applications and different configurations respond differently. Try it. Tweak XFC caching off and engage global buffers. Run some tests.

Isolate the performance limit(s). These limits can tend to be in unexpected areas -- sometimes something wildly unexpected is the limiting factor.

Ignoring performance limits and investigations in the general case and specifically considering I/O caching, the closer your caching is to "full" knowledge of your data and data access patterns, the better -- from disk-level, controller-level, XFC, RMS buffers, application-level, etc... While lower-level caches (usually) help (some applications see more improvements than others), sometimes caches can hose your performance. Higher-level and tailored caching does better.

But sometimes something unexpected -- like virtual memory faulting patterns and memory access strides can hammer you far more than the I/O caching for your data access.

An AlphaStation 500? (Tweaking and testing performance on a system as old as that seems, well, less likely to produce the performance of a system replacement with a newer Alpha. Toss an EV68 or EV7 and faster I/O at this case, or toss in an Integrity server. That's just a test system, right? :-)

Stephen Hoffman
HoffmanLabs LLC