Document revision date: 15 July 2002
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS System Manager's Manual


Previous Contents Index

17.11.2.1 Allocating Reserved Memory

During system initialization, the VMS$RESERVED_MEMORY.DATA data file is read.

For each entry in the data file, the number of megabytes is deducted from the system's fluid page count for this memory-resident global section as specified by the /SIZE qualifier on the RESERVED_MEMORY ADD command. If /PAGE_TABLES was specified, the amount of memory required for the shared page tables mapping the memory-resident global section is deducted from the system's fluid page count as well.

If /ALLOCATE was specified on the RESERVED_MEMORY ADD command, a suitable chunk of physical pages is also allocated and set aside for the memory-resident global section. If /PAGE_TABLES was specified, an additional chunk of physical pages is allocated and set aside for the shared page tables. The pages have a physical alignment appropriate for the largest granularity hint factor for the given sized chunk. If /ZERO was specified, the pages are zeroed during system initialization or when the system is idle. If /ZERO was not specified or if /NOZERO was specified, the pages are zeroed at the time the memory-resident global section is created.

If the system parameter STARTUP_P1 is set to MIN, entries in the Reserved Memory Registry entries are ignored and memory is not reserved.

If errors are encountered during system initialization while processing the Reserved Memory Registry data file, with reserving system fluid pages, or with allocating contiguous, aligned physical pages, an error message is issued to the console and the system continues to boot.

17.11.2.2 Freeing Reserved Memory

In the running system, you can free reserved memory by issuing the following SYSMAN command:


SYSMAN RESERVED_MEMORY FREE gs_name /GROUP = n 

The specified gs_name is the name of the memory-resident section associated with the entry being freed from the Reserved Memory Registry. A name must be specified.

The value n specified by the /GROUP qualifier is the UIC group number (in octal) associated with the memory-resident section being freed. If the memory-resident global section is a group global section, you must specify the /GROUP qualifier. If the memory-resident global section is a system global section, you must not specify the /GROUP qualifier.

If physical pages were not preallocated during system initialization for this global section, the reserved memory is simply added to the system's fluid page count. Otherwise the physical pages are deallocated onto the system's free or zeroed page list. The system's fluid page count is adjusted to include the deallocated pages.

If page tables are also reserved for the named memory-resident global section, the reserved memory for the shared page tables is also freed.

If the reserved memory is in use by the named memory-resident global section, the amount of reserved memory not currently in use is freed.

The RESERVED_MEMORY FREE command does not affect the Reserved Memory Registry data file contents, it only affects the memory within the running system.

17.11.2.3 Displaying Reserved Memory

Two different places hold reserved memory information, the Reserved Memory Registry data file and the Reserved Memory Registry in the running system created during system initialization based on the entries in the data file.

Different display mechanisms may be used depending on where the information about the reserved memory originates.

There are three mechanisms for displaying the Reserved Memory Registry within the running system: SYSMAN, the DCL SHOW MEMORY command and SDA.

17.11.2.4 Using Reserved Memory

The system services SYS$CREATE_GDZRO and SYS$CRMPSC_GDZRO_64 call internal kernel mode OpenVMS Alpha routines to use the reserved memory registered in the Reserved Memory Registry.

The global section need not be registered in the Reserved Memory Registry. If the global section name is registered in the Reserved Memory Registry, the size of the global section need not exactly match the size of the reserved memory. If the global section is not registered, or if /NOALLOCATE was specified when the global section was registered in the Reserved Memory Registry, the fault option is used for the memory-resident global DZRO section. If the size is greater than the size of the reserved memory, the system service call to create the memory-resident global DZRO section fails if there are not enough additional fluid pages within the system.

If /ALLOCATE was specified when the global section was registered in the Reserved Memory Registry, the allocate option is used for the memory-resident global DZRO section. The size of the global section must be less than or equal to the size of the reserved, preallocated memory or the error SS$_MRES_PFNSMALL is returned by the system service call.

17.11.2.5 Returning Reserved Memory

When a memory-resident global section is deleted, the physical pages used for that global section are deallocated to the free page list if physical pages were not preallocated for this global section. The system's fluid page count is adjusted only for those pages not reserved in the Reserved Memory Registry for this global section.

When a memory-resident global section is deleted, the physical pages used for that global section are returned to the Reserved Memory Registry if physical pages were preallocated for this global section. The physical pages are not deallocated to the free page list and are still reserved. No adjustment is made to the system's fluid page count.

Reserved memory may only be freed to the running system by using the RESERVED_MEMORY FREE command to the SYSMAN utility.

Note

Permanent global sections are deleted by calling SYS$DGBLSC and upon the last reference to the global section. Nonpermanent global sections are simply deleted upon last reference to the global section.

17.11.3 Application Configuration

The configuration of an OpenVMS Alpha application that uses memory-resident global sections performs the following steps:

  1. Execute the SYSMAN RESERVED_MEMORY ADD commands that specify the required use of reserved memory.
  2. Run AUTOGEN with feedback to set the system's fluid page count appropriately and size the system's pagefile, number of processes and working set maximum size appropriately.
  3. Reboot the system to allow for the reserved memory to be deducted from the system's fluid page count and for contiguous, aligned pages to be allocated and zeroed as necessary.


Chapter 18
Managing File System Data Caches

This chapter describes how to manage the Extended File Cache (XFC) (Alpha only) and the Virtual I/O Cache (VIOC). These are the caches that the Files-11 file system uses to cache data for ODS-2 and ODS-5 volumes.

Information Provided in This Chapter

This chapter describes the following tasks:
Task Section
Disabling caching clusterwide Section 18.3
Mounting a volume with caching disabled Section 18.4
Managing the Extended File Cache (Alpha Only) Section 18.5
Managing the Virtual I/O Cache Section 18.6

This chapter explains the following concepts:
Concept Section
Caching Section 18.1
File system data caches Section 18.2

18.1 Understanding Caching

The Files-11 file system uses a technique called caching to improve performance. It keeps a copy of data that it has recently read from disk or written to disk in an area of memory called a cache.

When an application reads data, the file system checks whether the data is in its cache. It issues an I/O to read the data from disk only if the data is not in the cache.

Caching improves read performance. Reading data from memory (from the cache) is much faster than reading it from disk.

There are several levels of caching in both the hardware I/O subsystem and in OpenVMS. In general, more levels of caching result in better response time in accessing data.

18.2 Understanding File System Data Caches

For ODS-2 and ODS-5 volumes, the Files-11 file system has several caches. It has metadata caches for file metadata such as file headers, and a data cache for file data. It can use one of two system-wide data caches, as follows:
File System Data Cache Description
Virtual I/O Cache (VIOC) This is the original data cache, and is available on VAX and Alpha.
Extended File Cache (XFC) This data cache is available on OpenVMS Alpha Version 7.3 and later, and is available only on OpenVMS Alpha. It provides better performance and more capability than VIOC. XFC is the default cache on OpenVMS Alpha Version 7.3 and later.

This chapter describes how to manage the data caches. For information on managing the metadata caches, see the OpenVMS Performance Management. Note that RMS makes use of local and global buffers that can perform data caching. By default, this caching is not enabled. You can manipulate the RMS local and global buffers to affect I/O performance. For information on managing the RMS local and global buffers, see the Guide to OpenVMS File Applications. Note also that the modified page list is a type of cache; that is, if a process references a page that is on the modified page list, the page is placed back into the working set of the process and is not output to disk.

Both XFC and VIOC are virtual block caches that maintain consistent data within an OpenVMS Cluster. They cache both data files and image files. The data caches are write-through caches; when an application writes data to a file, the data is written straight through to disk. The application has to wait until the disk I/O completes and the data is on disk.

In an OpenVMS Cluster, different nodes can use different data caches. This allows mixed architecture clusters to benefit from XFC. OpenVMS Alpha nodes can use either XFC or VIOC. OpenVMS VAX nodes can use only VIOC, as described in Section 18.5.6.

XFC improves I/O performance and contains the following features that are not available with VIOC:

18.3 Disabling Caching Clusterwide

At system startup, the value of a static system parameter controls whether the file system uses a data cache, and if so, which data cache it uses (XFC or VIOC). The system parameter depends on the operating system, as shown in the following table:
Operating System System Parameter Enabled Disabled
OpenVMS Alpha VCC_FLAGS 1 or 2 (default) + 0
OpenVMS VAX VBN_CACHE_S 1 (default) 0


+1 selects VIOC, 2 (the default) selects XFC

In an OpenVMS Cluster, if file system data caching is disabled on one node, it is disabled throughout the cluster. The other nodes in the cluster cannot use XFC or VIOC until that node leaves the cluster or reboots with VCC_FLAGS or VBN_CACHE_S set to a non-zero value. You can use the DCL command SHOW MEMORY to determine whether caching is enabled.

To disable caching clusterwide, follow these steps on any node in your OpenVMS Cluster:

  1. Set the appropriate system parameter (VCC_FLAGS or VBN_CACHE_S) to 0, using MODPARAMS.DAT.
  2. Run AUTOGEN to ensure that other system parameters allow for the new value. This is not essential, but it is advisable.
  3. Reboot the system to make the new value effective.

18.4 Mounting a Volume With Caching Disabled

To prevent the file system from caching data on a particular volume, such as a database volume, use the MOUNT /NOCACHE command to mount the volume with caching disabled.

If you are using XFC in an OpenVMS Cluster, mounting a volume /NOCACHE is easier than using SET FILE /CACHING_ATTRIBUTE to set the caching attribute of all the files in the volume to no caching (see Section 18.5.3). Using MOUNT /NOCACHE ensures the minimum caching overhead. Note that the MOUNT/NOCACHE command also disables XQP caching.

Example

This example mounts a database volume labeled ORACLE_VOL1 with caching disabled:


$ MOUNT DUA100: ORACLE_VOL1 /NOCACHE /SYSTEM

18.5 Managing XFC (Alpha Only)

This section describes how to manage XFC, which is available only on OpenVMS Alpha. It describes the following tasks.
Task Section
Controlling the size of the cache Section 18.5.1
Controlling the maximum cached I/O size Section 18.5.2
Disabling caching for a file Section 18.5.3
Disabling read-ahead caching Section 18.5.4
Monitoring performance Section 18.5.5
Using in a mixed architecture OpenVMS Cluster Section 18.5.6

18.5.1 Controlling the Size of the Cache

This section describes how to control the minimum and maximum size of XFC

XFC is held in virtual memory in S2 space and automatically shrinks and grows, depending on your I/O workload and how much spare memory is available on your system. S2 space is a 64-bit address space, so the cache can grow to very large sizes when required.

As your I/O workload increases, the cache automatically grows, but never to more than the maximum size. And when your applications need memory, the cache automatically shrinks, but never to less than the minimum size.

18.5.1.1 Controlling the Minimum Cache Size

The minimum size of XFC is controlled by the value of the VCC$MIN_CACHE_SIZE entry in the reserved memory registry. VCC$MIN_CACHE_SIZE specifies the amount of memory in megabytes (MB) that is allocated to XFC at system startup. The cache never shrinks below this size. This memory is never released.

Checking the Minimum Size

To check the minimum size of XFC, use either the Sysman utility command RESERVED_MEMORY /SHOW or the DCL command SHOW MEMORY /RESERVED. For example:


$ SHOW MEMORY /RESERVED
              System Memory Resources on 11-MAY-2000 15:50:25.64 
 
Memory Reservations (pages):       Group    Reserved      In Use       Type 
  VCC$MIN_CACHE_SIZE                 ---        1536        1536  Allocated 
Total (400.00 Mb reserved)                      1536        1536

Setting a Minimum Size

By default, the reserved memory registry does not contain an entry for VCC$MIN_CACHE_SIZE, so no memory is allocated to XFC at system startup. However, XFC allocates a small amount of memory to maintain overall system throughput. The amount of memory allocated varies according to the size of your machine.

To set a minimum size, follow these steps:

  1. Use the Sysman utility's RESERVED_MEMORY ADD command to add an entry for VCC$MIN_CACHE_SIZE. For example, to set the minimum size to 300MB:


    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> RESERVED_MEMORY ADD VCC$MIN_CACHE_SIZE /SIZE=300 /ALLOCATE -
    _SYSMAN> /NOGLOBAL_SECTION /NOZERO /NOPAGE_TABLE
    

    You must use all the qualifiers shown in this example. For best performance, set the minimum size to a multiple of 4MB.
    Note that if you are doing this on a NUMA type machine, where you want to allocate reserved memory in different RADs, you may choose to use the following commands (rather than those above) to set the minimum size:


    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> RESERVED_MEMORY ADD VCC$MIN_CACHE_SIZE /SIZE=300 /ALLOCATE -
    _SYSMAN> /NOGLOBAL_SECTION /NOZERO /NOPAGE_TABLE/RAD=0
    SYSMAN> RESERVED_MEMORY EXTEND VCC$MIN_CACHE_SIZE /SIZE=500 /ALLOCATE -
    _SYSMAN> /NOGLOBAL_SECTION /NOZERO /NOPAGE_TABLE/RAD=1
     
    

  2. Run AUTOGEN to ensure that other system parameters allow for the new value. This is not essential, but it is advisable.
  3. Reboot the system to make the new value effective.
    During startup, if the system does not have enough memory to allocate the specified minimum size, no memory is allocated to XFC and its minimum size is set to 0MB.

Changing the Minimum Size

To change the minimum size of XFC, follow these steps:

  1. Use the Sysman utility's RESERVED_MEMORY MODIFY command to modify the existing entry for VCC$MIN_CACHE_SIZE. For example, to change the minimum size to 360MB:


    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> RESERVED_MEMORY MODIFY VCC$MIN_CACHE_SIZE /SIZE=360 /ALLOCATE -
    _SYSMAN> /NOGLOBAL_SECTION /NOZERO
    

    You must use all the qualifiers shown in this example. For best performance, remember to set the minimum size to a multiple of 4MB.

  2. Run AUTOGEN to ensure that other system parameters allow for the new value. This is not essential, but it is advisable.
  3. Reboot the system to make the new value effective.
    During startup, if the system does not have enough memory to allocate the specified minimum size, no memory is allocated to XFC and its minimum size is set to 0MB.

18.5.1.2 Controlling the Maximum Cache Size

To control the maximum size of XFC, use the dynamic system parameter VCC_MAX_CACHE. It specifies the size in megabytes.

By default, VCC_MAX_CACHE is --1, which means that at system startup, the maximum size of XFC is set to 50 percent of the physical memory on the system. For example, if the system has 2GB of physical memory, its maximum size is set to 1GB.

Note that the maximum size specified by VCC_MAX_CACHE does not include the memory that XFC consumes indirectly via the OpenVMS lock manager.

The value of VCC_MAX_CACHE at system startup sets an upper limit for the maximum size of XFC. You cannot increase the maximum size beyond that value.

For example, VCC_MAX_CACHE is 60 at system startup, so the maximum size is initially set to 60MB. You then set VCC_MAX_CACHE to 40, which decreases the maximum size to 40MB. If XFC is bigger than 40MB, it gradually shrinks to 40MB. You then set VCC_MAX_CACHE to 80, but the maximum size is only increased to 60MB, the value set at system startup. You cannot increase the maximum size beyond the value set at system startup.

If VCC_MAX_CACHE is less than the minimum size specified by the value of the VCC$MIN_CACHE_SIZE entry in the reserved memory registry, then during system startup, VCC_MAX_CACHE is ignored and the maximum size of XFC is set to the same value as the minimum size. In this case, XFC has a fixed size and cannot shrink or grow.

Example

This example changes the maximum size of XFC to 50MB:


$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET VCC_MAX_CACHE 50
SYSGEN> WRITE ACTIVE


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6017PRO_080.HTML