topic Re: Extended File Cache in Operating System - OpenVMS

Extended File Cache

David Teixeira — Tue, 08 Feb 2005 11:18:48 GMT

I'm running OpenVMS 7.3 on an Alpha ES45 and need to disable Extended File Cache. How would I go about this?

Any assistance would be greatly appreciated.

Re: Extended File Cache

Uwe Zessin — Tue, 08 Feb 2005 11:37:12 GMT

Set VCC_FLAGS = 0 to disable all cacheing or = 1 to enable the old-style VIOC.

Re: Extended File Cache

Ian Miller. — Tue, 08 Feb 2005 17:59:04 GMT

why do you wish to do this?

Re: Extended File Cache

Uwe Zessin — Wed, 09 Feb 2005 03:04:56 GMT

To make the system go slower?

Seriously, perhaps David has heard about problems in the initial XFC releases, but I think they have been fixed by now and ECOs, even for VMS V7.3, are available.

Re: Extended File Cache

Galen Tackett — Wed, 09 Feb 2005 07:05:08 GMT

Perhaps there are reasons to turn off the cache.

Wouldn't it be possible to have access patterns such that the Extended File Cache would not help performance?

Or a memory-poor situation where the physical memory taken up by the cache could be better used for some other purpose?

Just some thoughts...

Galen

Re: Extended File Cache

Hein van den Heuvel — Wed, 09 Feb 2005 07:33:41 GMT

I'd like to echo the WHY sentiment.

Galen Tackett wrote:
>>> "Perhaps there are reasons to turn off the cache."

In which case we would like to know WHY?
Perhaps we have a similar problem and do not realize it yet, or perhaps we are in a position to fix it or otherwise improve it.

>>> "Wouldn't it be possible to have access patterns such that the Extended File Cache would not help performance?"

There is a known 'pathelogical' case with CONVERTing very large (mutliple GBs) indexed files with small, odd sized buckets. For this purpose odd is = not a multiple of 8KB.
This has since been addresses, but the real solution was of course to use reasonable large bucketsize on really large files.
Too many customers leave the size at the original design point, say 6, where 10 years later in production they really need 24 or 32 blocks (still not really big).

>>> "Or a memory-poor situation where the physical memory taken up by the cache could be better used for some other purpose?

NO. The XFC will drop back if need be.

Regards,
Hein.

Re: Extended File Cache

David Teixeira — Wed, 09 Feb 2005 10:53:24 GMT

Thank you for all your responses. Here is an exerpt from a report given to us from our software vendor. We are upgrading and it was recommended that we turn off the XFC.(note that the database we're upgrading is called CACHE [cash-ay])

"MEMORY UTILIZATION:
Node has 2 GB of memory, with 3% of that memory free. This could cause problems during and after the 3.0 upgrade. I would recommend turning off the Extended File Cache in VMS, as Cache does not use it, and at least .33 GB of memory is currently allocated to this feature. There has been expansion of the nonpaged dynamic memory, but with this little memory free, I would not recommend increasing NPAGEDYN."

Now my issue is that a while back I set VCC_flags to 0. But when I bounced the system, the settings did not stick. Does anyone know why this is happening?

Re: Extended File Cache

Ian Miller. — Wed, 09 Feb 2005 11:06:45 GMT

David, how did you change vcc_flags?
You should put the new value in SYS$SYSTEM:MODPARAMS.DAT and run AUTOGEN.
Parhaps you changed VCC_FLAGS in SYSGEN then did WRITE ACTIVE but not WRITE CURRENT?

Cache database may not use the cache but everything else on the node does. The size of the cache is dependent on the amount of free memory and adjusts automagically.

If you are that short of free memory you should be looking at getting more or reducing MAXPROCESSCNT & BALSETCNT parhaps. Either way a look at your whole system is needed.

Re: Extended File Cache

David Teixeira — Wed, 09 Feb 2005 13:41:02 GMT

Hi Ian,

I modified sys$system:modparams.dat and ran autogen but it's not working. VCC_flags is now set to 2 and the default is 2. Here is what my modparams.dat file looks like:

SCSSYSTEMID=1026
SCSNODE="PPSIDX"
VAXCLUSTER=0
MIN_KSTACKPAGES=3
WINDOW_SYSTEM = 1
MIN_NPAGEDYN = 1998848
vcc_flags=0
! End of Factory Installed Software settings
!
SHADOWING=2
SHADOW_SYS_UNIT=0
SHADOW_SYS_DISK=1
SHADOW_MAX_COPY=4
TAPE_ALLOCLASS=1
ALLOCLASS=1
WINDOW_SYSTEM=0 ! Turn Decwindows on
!
MAXPROCESSCNT=700 ! M/VX License + 30 + UCX Symbionts processes
BALSETCNT=MAXPROCESSCNT-2 ! MAXPROCESSCNT - 2 - LEAVE AS IS
MIN_GBLSECTIONS=700
MIN_SYSMWCNT=1763
MIN_WSMAX=146320
MIN_GBLPAGES=3749700 ! Stuart R Salzer, value before autogen.
MIN_GBLPAGFIL=225632 ! MINGBLPAGFIL = MIN_GBLPAGES
MIN_SYSMWCNT=1763 ! GBLPAGES / 128
!
TTY_DEFCHAR2=135170 ! Virtual Terminals
TTY_TIMEOUT=180 ! Virtual terminals ;changed 10-22-91 by JJV/IDX
TTY_ALTYPAHD=2064 ! NEW LATMASTER ;changed 01-31-92 by jjv/idx
MIN_ACP_WINDOW=80 ! RECOMMENDED BY Tuning Guide Dated 4/1/94 V1 page 1-3
MIN_CHANNELCNT=10000 ! RECOMMENDED BT DEC WHEN WE INCREASED TELNET SESSIONS
MMG_CTLFLAGS=0 ! RECOMMENDED BY Tuning Guide Dated 4/1/94 V1 page 1-3

Re: Extended File Cache

Ian Miller. — Wed, 09 Feb 2005 16:14:40 GMT

are there any errors reported in SYS$SYSTEM:AGEN$PARAMS.REPORT ?

There are some entries in your modparams that look like historical entries from VAX/VMS (reference to LATMASTER for example which I think was VMS V5.4-x?) and the setting of MMG_CTLFLAGS.

Re: Extended File Cache

David Teixeira — Wed, 09 Feb 2005 16:36:34 GMT

Hi Ian,

Here's the report. What do you think could be going on here? -thanks! dave

AUTOGEN Parameter Calculation Report on node: PPSIDX
This information was generated at 9-FEB-2005 13:25:05.80
AUTOGEN was run from GENPARAMS to GENPARAMS - default execution specified

** No changes will be done by AUTOGEN **
The values given in this report are what AUTOGEN would
have set the parameters to.

The following concerns were detected within MODPARAMS.DAT

** Note ** - Duplicate values for MIN_NPAGEDYN found.
Records were defined by MODPARAMS and VMS to set symbol to 1998848

** Note ** - Multiple MIN values found for MIN_GBLSECTIONS.
Using MODPARAMS value (700) which is superseding VMS value (600)

** Note ** - Multiple MIN values found for MIN_WSMAX.
Using MODPARAMS value (146320) which is superseding VMS value (12000)

** Note ** - Multiple MIN values found for MIN_GBLPAGES.
Using MODPARAMS value (3749700) which is superseding VMS value (150000)

** Note ** - Multiple MIN values found for MIN_GBLPAGFIL.
Using MODPARAMS value (225632) which is superseding VMS value (1024)

** Note ** - Duplicate values for MIN_SYSMWCNT found.
Records were defined by MODPARAMS to set symbol to 1763

This run of AUTOGEN is *NOT* based on FEEDBACK information.
The resulting calculations may not be representative of your workload.
Compaq recommends the use of feedback to adjust system resources to
match system workloads.

Parameter information follows:
------------------------------

MAXPROCESSCNT parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 1052. The value 422
will be used in accordance with the following requirements:
MAXPROCESSCNT has been specified by a hard-coded value of 422.

Information on OpenVMS executable image Processing:

Processing SYS$MANAGER:VMS$IMAGES_MASTER.DAT
Total global pagelets counted = 46434
Total global sections counted = 212
Total global pagefile counted = 296
Total resident code pages counted = 382
Total resident data pages counted = 0

GBLPAGES parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 51144154. The value 51197682
will be used in accordance with the following requirements:
GBLPAGES has been increased by 53528.
GBLPAGES minimum value is 3749700.

GBLSECTIONS parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 400. The value 700
will be used in accordance with the following requirements:
GBLSECTIONS has been increased by 49.
GBLSECTIONS minimum value is 700.

SHADOW_MAX_COPY parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 1. The value 4
will be used in accordance with the following requirements:
SHADOW_MAX_COPY has been specified by a hard-coded value of 4.

BUS addressable pool information:
Based on the current configuration, BUS addressable pool (BAP)
will be created as a separate pool of 40960 bytes.

MMG_CTLFLAGS parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 3. The value 0
will be used in accordance with the following requirements:
MMG_CTLFLAGS has been specified by a hard-coded value of 0.

GH_RES_CODE parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 512. The value 1024
will be used in accordance with the following requirements:
GH_RES_CODE minimum value is 1024.

PROCSECTCNT parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 32. The value 64
will be used in accordance with the following requirements:
PROCSECTCNT minimum value is 64.

PQL_MWSDEFAULT parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 512. The value 1024
will be used in accordance with the following requirements:
PQL_MWSDEFAULT minimum value is 1024.

PQL_MWSQUOTA parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 1024. The value 2048
will be used in accordance with the following requirements:
PQL_MWSQUOTA minimum value is 2048.

PQL_MWSEXTENT parameter information:
- AUTOGEN parameter calculation has been overridden.
The calculated value was 2048. The value 8192
will be used in accordance with the following requirements:
PQL_MWSEXTENT minimum value is 8192.

Re: Extended File Cache

Bill Hall — Wed, 09 Feb 2005 17:27:28 GMT

David,

You need to specify the correct starting and ending phases of AUTOGEN.

$@SYS$UPDATE:AUTOGEN GETDATA SETPARAMS are the minimum start and ending phases you must specify to read MODPARAMS.DAT and set the new SYSGEN parameters.

More detailed help can be found online $@SYS$UPDATE:AUTOGEN HELP.

Bill

Re: Extended File Cache

Uwe Zessin — Thu, 10 Feb 2005 01:11:22 GMT

A bit off topic, but:

>> WINDOW_SYSTEM=0 ! Turn Decwindows on

That's not true...
The value of 1 defined to load DECwindows. It happens to 'work' anyway due to bugs in the startup.

Re: Extended File Cache

John Eerenberg — Thu, 10 Feb 2005 17:27:13 GMT

autogen . . . here is the steps I have used very effectively on all my systems.
1) edit modparams.dat
2) @sys$update:autogen savparams genparams
3) review the report
4) repeat 1-3 until satisfied.
5) @sys$update:autogen setparams
6) reboot
Steps 2) and 5) come from the system management manual.

Since I have started using Cache (and have used other MUMPS for years) . . . I find the following odd:
"MEMORY UTILIZATION:
Node has 2 GB of memory, with 3% of that memory free. This could cause problems during and after the 3.0 upgrade. I would recommend turning off the Extended File Cache in VMS, as Cache does not use it, and at least .33 GB of memory is currently allocated to this feature."
Cache most likely excludes its files from XFC. But VMS does not exclude its own files. A number of VMS files could exist in the XFC and help overall performance.
Consider a small XFC of 128MB. Anything smaller might crash the system (as I was the first to find this out the hard way last year; engineering is addressing it). If 128MB is too much, then turning off the XFC is appropriate. But honestly, XFC is very good about shrinking its size if other processes need the memory. I see no downside to doing this and my experience says this is good to consider.

A different MUMPS vendor (and yes, I know Cache is more then MUMPS) is recommending no XFC to its customers but this was based on a poor understanding of VMS internals. This seems to be spreading and that is a shame. In the end, if they say turn it off, you have to turn off XFC.

"There has been expansion of the nonpaged dynamic memory, but with this little memory free, I would not recommend increasing NPAGEDYN."
I couldn't disagree more with this recommendation. I would urge you to increase npagedyn and prevent pool expansion. If the vendor wants to leave npagedyn as is, then I strongly suggest you set npag_gentle and npage_agressive to 100 each. Last time I checked with VMS support, you are running the risk of a system hang or crash if your pool is too fragmented (expansion is an indication of such).

I saw in your listing that MMG_CTLFLAGS=0. IMHO, there is no good technical reason for this. Consider using the default of 3. I can't be 100% certain, but I wonder if MMG_CTLFLAGS=0 negatively affects XFC's ability to shrink and grow efficiently especially if 3% memory is free.

Also, I am leary of managing any GH_* parameters in modparams.dat. Consider removing all references and autogen management (even if autogen changes them from autogen to autogen).

I am guessing, but from experience I can tell from your listing that more work could be done. For example, if you have lots of logicals, ACLs, MBXs, etc. then most likely you have a performance problem or two waiting to happen.

Always get vendor buy-in before making changes especially if they are taking responsbility for the system's integrity, etc.

good luck,
john

Re: Extended File Cache

Rob Young_4 — Fri, 11 Feb 2005 12:12:39 GMT

David,

Thank you for all your responses. Here is an exerpt from a report given to us from our software vendor. We are upgrading and it was recommended that we turn off the XFC.(note that the database we're upgrading is called CACHE [cash-ay])

"MEMORY UTILIZATION:
Node has 2 GB of memory, with 3% of that memory free. This could cause problems during
and after the 3.0 upgrade. I would recommend turning off the Extended File Cache in VMS,
as Cache does not use it, and at least .33 GB of memory is currently allocated to this
feature. There has been expansion of the nonpaged dynamic memory, but with this little
memory free, I would not recommend increasing NPAGEDYN."

---

This is silly - dig in your heels. I hate
this interface... I can't remember what I
read before - time to open another window.

Two points... John Eerenberg has a good
spot on MMG_CTLFLAGS - that shouldn't be
0. Someone turned off working set trimming.
Someone decided that memory management
is not necessary.

Second bigger point that I don't see anyone addressing, is you want caching. Turning
off caching means you go out to disk OR
if you have a real disk subsystem disk controller cache for "hot" blocks.

Cache does use XFC. Now the argument would
be physical memory dedicated to Cache obviates the need of that. But what people
don't do is give Cache a Gig on startup. Cache doesn't have the flexibility of an XFC
to give it up when the OS needs it.

Start with this thread:

http://tinyurl.com/5t6s9

There are 5 or 6 companions to that from
my XFC investigation. Go to groups.google.com and type xfc - look for:

XFC, IO Size and Backup - Take Two

(4 down on the screen) if interested.

Here is why to leave XFC on. Say you've
given Cache 60000 physical pages , Cache will
kick out blocks and XFC will have hits on
them (I've seen this with Cache's daddy...
.GLS files will have XFC hits).

But most importantly, you run the risk of
slowing a system down greatly if XFC isn't
turned on. Just day to day stuff. You
do a directory listing - you are going out
to disk/controller. DCL! Imagine that
sylogin.com that everyone hits - guess what?
With caching off - you are out to disk/controller. And most insidiously - you
aren't using global buffers on rightslist.dat, guess what? That is one
hot puppy! How do I know? XFC. If you
trundle through SDA> XFC you can get a good
feel for what is going on.

Enough Rambling.

Rob

Re: Extended File Cache

Dale A. Marcy — Mon, 14 Feb 2005 13:10:59 GMT

John indicated:

"autogen . . . here is the steps I have used very effectively on all my systems.
1) edit modparams.dat
2) @sys$update:autogen savparams genparams
3) review the report
4) repeat 1-3 until satisfied.
5) @sys$update:autogen setparams
6) reboot
Steps 2) and 5) come from the system management manual."

One minor change I make to this sequence is that the savparams only needs to be done the first time. The second and subsequent times, I change savparams to getdata.

Re: Extended File Cache

David Teixeira — Mon, 14 Feb 2005 13:29:01 GMT

I would like to thank everyone who responded to my post!!! You've all been very helpful! From the responsed I've received, I decided not to disable XFC in preparation for our upgrade.

We performed our upgrade over the weekend and we haven't experienced any performance issues whatsoever.

Thanks again everyone!

Re: Extended File Cache

David Teixeira — Mon, 14 Feb 2005 13:29:48 GMT