<<< VAXAXP::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>> -< VAX and Alpha VMS - Digital Internal Use Only >- ================================================================================ Note 582.7 SMARTDRV for VMS Alpha ? 7 of 7 BSS::JILSON "WFH in the Chemung River Valley" 502 lines 14-MAY-1997 09:36 -------------------------------------------------------------------------------- You really have to watch out for BACKUP polluting the statistics. Sure wish that VMS included a utlity to zero the statistics portion of SHOW MEMORY/CACHE/FULL instead of relying on the CSC to do it for them :*) [OpenVMS] How to Interpret Info From SHOW MEMORY/CACHE/FULL on Alpha Any party granted access to the following copyrighted information (protected under Federal Copyright Laws), pursuant to a duly executed Digital Service Agreement may, under the terms of such agreement copy all or selected portions of this information for internal use and distribution only. No other copying or distribution for any other purpose is authorized. Copyright (c) Digital Equipment Corporation 1995, 1996. All rights reserved. PRODUCT: OpenVMS Alpha, All Versions COMPONENT: Virtual I/O Cache (VIOC) SOURCE: Digital Equipment Corporation OVERVIEW: This article provides information on how to interpret the information found in the DCL command "SHOW MEMORY/CACHE/FULL". The following is a display from the command from an Alpha system with a numeric value assigned to each element. The explanation for the element can be found in the section associated with the numeric value. Virtual I/O Cache 1. Total Size (Kbytes) 3200 3. Read IO Count 422489 " Free Kbytes 0 4. Read Hit Count 242514 " Kbytes in Use 3200 5. Read Hit Rate 57% 7. Write IO Bypassing Cache 4455 6. Write IO Count 48359 2. Files Retained 95 8. Read IO Bypassing Cache 100523 SECTION 1: ---------- Total Size (Kbytes), Free Kbytes, and Kbytes in Use. The "Total Size" of the VIOC is the count of the Kbytes allocated from memory for cached files. This value is fixed and is defined by the SYSGEN parameter VCC_MAXSIZE. Note: The SYSGEN parameter VCC_MAXSIZE is the count of the number of the blocks allocated from memory for the VIOC. The default value for the parameter is 6400. This block value is equal to the displayed value for the "Total Size (Kbytes)", 3200, based on the following algorithm: 1 block = 512 bytes 1 Kbyte = 1024 bytes (2 blocks) 6400 blocks = 3276800 bytes 3276800 bytes = 3200 Kbytes blocks * bytes_per_block ------------------------ = Kbytes bytes_per_Kbyte Another, much simpler, algorithm is (VCC_MAXSIZE/2). However, the correlation of 'blocks' to 'Kbytes' is unclear with the simple equation. The number of "Free Kbytes" is the count of bytes allocated for the VIOC that do not currently contain valid file data. When a DIO to a cachable file is executed, and no reference to the file data can be located in the VIOC, a portion of these "Free Kbytes" is allocated. Once allocated, the number of "Free Kbytes" is decremented and the count of "Kbytes in use" is incremented. The sum of "Free Kbytes" and "Kbytes in use" is equal to the value of "Total size". SECTION 2: ---------- Files Retained. This element is the count of File Control Blocks (FCB) retained by the file system, not files retained by the VIOC. The value of this element is based on the value of EXE$GL_LIMBOLEN, which is the count of FCBs retained in an FCB cache called the LIMBO queue. These FCBs are from files that have been deleted on the system. The FCBs are cached to speed the allocation of file headers for newly created files. The head of the LIMBO queue is pointed to by EXE$GQ_LIMBOQ and its size is based on EXE$GL_LIMBOMAX. When the file system attempts to move another FCB into the queue, it checks to see if EXE$GL_LIMBOLEN is equal to EXE$GL_LIMBOMAX. If this is true, the LIMBO queue is flushed down to the value of EXE$GL_LIMBOTHR in a FIFO manner, and EXE$GL_LIMBOLEN is reset to reflect the new size of the queue. The size of the LIMBO queue is hardcoded to 250 for EXE$GL_LIMBOMAX, and 200 for EXE$GL_LIMBOTHR. However, with VIOC enabled these values are limited to 100 or the SYSGEN parameter ACP_HDRCACHE, whichever is less. When a file is cached by VIOC, an associated FCB is created for cache called a CFCB (Cache File Control Block). CFCBs are also cached in a LIMBO queue but the association between the CFCB LIMBO queue and the FCB LIMBO queue is not guaranteed. This dissociation is due to the fact that a CFCB can be removed from the CFCB LIMBO queue and associated with a completely different FCB then for what it was originally created. This re-association is caused by the periodic inability of the VIOC to allocate more space for expansion, i.e.; the creation of a new CFCB. If expansion is disabled and there are CFCBs on the CFCB LIMBO queue, VIOC uses these entries. There may also be more CFCBs defined in nonpaged pool than FCBs. This occurs because FCBs are deallocated back to nonpaged pool as files are closed and the limbo queue is unable to contain them. SECTION 3: ---------- Read IO Count. This element is the count of all DIO reads. SECTION 4: ---------- Read HIT Count. This element is the count of all DIO reads satisfied with data from the VIOC. SECTION 5: ---------- Read HIT rate. This element is calculated based on the following formula; (*10)/(/10) The break-even percentage for OpenVMS Alpha is 30-35%. Note: Refer to the discussion below regarding "Tuning VIOC". SECTION 6: ---------- Write IO Count. This element is the count of all DIO writes to files that have associated data in the VIOC. SECTION 7: ---------- Write IO Bypassing the Cache. This element is the sum of 2 counters: 1. Write I/Os Bypassing the VIOC due to function 2. Write I/Os Bypassing the VIOC due to size Note: Refer to the discussion below regarding the "Analysis of IO Bypassing the Cache". SECTION 8: ---------- Read IO Bypassing the Cache. This element is the sum of 2 counters: 1. Read I/Os Bypassing the VIOC due to function 2. Read I/Os Bypassing the VIOC due to size Note: Refer to the discussion below regarding the "Analysis of IO Bypassing the Cache". TUNING VIOC ----------- There are many things that have the potential to negatively affect the "Hit Rate" seen in Section 5 of the SHOW MEMORY/CACHE/FULL display. 1. The size of VIOC. SYMPTOM: If "Free Kbytes" constantly indicates 0 free, then the amount of non-paged pool allocated for the cache may be limiting the size that VIOC needs to be effective in your environment. SOLUTION: Increase the value of VCC_MAXSIZE. 2. How VIOC is accessed: Certain utilities and applications access data in a fashion not conducive to caching, or execute in a way that skews the numbers observed with the SHOW MEMORY/CACHE/FULL command. Note: A program to reset the counters described in section 3, 4, 6, 7, and 8 is provided at the end of this article. Examples: a. BACKUP, when run, typically causes a large increase to the "Read IO Count" while incurring no read hits. This is due to the size and function of the IO BACKUP is executing. Depending on the amount of data being backed up, the increase to "Read IO Count" can be drastic in a short span of time. Since the "Read Hit Rate" remains somewhat flat for this same period of time, the calculated "Hit%" is skewed. The skewed values remain until the system is rebooted, or until enough time and IOs, with an equitable hit rate, occur. Typically, "Read IO Bypassing Cache" increases in proportion to "Read IO Count". b. Some network applications use special functions when performing IO causing "Read IO Count" to increase while incurring no read hits. Typically, "Read IO Bypassing Cache" increases in proportion to "Read IO Count" and the overall size of the VIOC shows minimal growth. In this case, VIOC should be disabled to conserve resources. This problem has been experienced with certain TCP/IP applications like PATHWORKS. c. Some database applications access information in an inconsistent manner, i.e.; doing minimal consecutive access to the same record in a file, that the size of the VIOC increases to or near its maximum, incur a consistent "Read IO Count" with little or "Read IO Bypassing Cache", and show "Hit%" far below the break-even point. In this case VIOC should be disabled to conserve resources. Analysis of IO Bypassing the Cache ---------------------------------- Most read or write IOs Bypassing the VIOC due to "function" are due to the IO request being made with either a function modifier or with NOCACHE enabled. Read or write IOs Bypassing the cache due to "size" are due to a request size in the IO greater than 35 blocks. If the IO Bypassing the cache is consistently 80% or more of Read IO Count (element 5), disable VIOC by setting VCC_FLAGS to 0. To view the counters that are incremented when IOs bypass the VIOC use the System Dump Analyzer (SDA). For example: $ ANALYZE/SYSTEM SDA> SHOW EXECUTIVE : : ( Continue to press return until you find--+ ) | +---------------------------------------+ v SYS$VCC <---- ( This is the definition for VIOC ) Nonpaged read only 800FE000 80109800 <-- (VIOC code) Nonpaged read/write 855CE000 855CFA00 <-- (VIOC data) v | +---------------+ v SDA> EVALUATE @(855CE000+nn) ^ | +---------------+ ^ 24 for read IO Bypassing the cache due to the function, 28 for read IO Bypassing the cache due to the size The "function" of an IO is defined in a data structure for the IO called the IO Request Packet (IRP) and is almost exclusively application dependent. No manipulation of cache parameters can overcome how an application chooses to perform an IO. Program to Reset selected VIOC Counters: ---------------------------------------- Note: There are 4 lines of this code that have been formatted to conform to the 80 column width of the article. These lines must be rectified to 132 columns before this code can be linked or run. The lines in question are terminated by a hyphen (-) with the proceeding on the following line. .title VIOC_RST_CNT-AXP .ident /V2.0/ ;***************************************************************************** ; COPYRIGHT (C) 1994 BY ; DIGITAL EQUIPMENT CORPORATION, MAYNARD ; MASSACHUSETTS. ALL RIGHTS RESERVED. ; ; THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED ; ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE INCLUSION ; OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER COPIES ; THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY OTHER ; PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY TRANSFERRED. ; ; THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE AND ; SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT CORPORATION. ; ; DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS ; SOFTWARE ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL. ; ; NO RESPONSIBILITY IS ASSUMED FOR THE USE OR RELIABILITY OF SOFTWARE ; ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL EQUIPMENT CORPORATION. ; ; SUPPORT FOR THIS SOFTWARE IS NOT COVERED UNDER ANY DIGITAL SOFTWARE ; PRODUCT SUPPORT CONTRACT, BUT MAY BE PROVIDED UNDER THE TERMS OF THE ; CONSULTING AGREEMENT UNDER WHICH THIS SOFTWARE WAS DEVELOPED. ; ;**************************************************************************** ;* * ;* This program is provided AS IS and as such offers no warranty, * ;* implied or otherwise by DIGITAL EQUIPMENT CORPORATION or any * ;* of it's employees. Any loss of services or damages incurred by * ;* the use of this program are the sole responsibility of those * ;* authorizing it's execution. * ;* * ;**************************************************************************** ; ; Reg Hunter - Digital Customer Support Center/Colorado Springs ; 9-APR-1996 ; ; This routine reset the counters that determine the hit% for the VIOC. ; The location of these counters are an offset from CACHE$ACCESS. ; ; The offset value used in OpenVMS ALPHA 6.1 is 1188(hex), for an ; *unpatched* version of SYS$VCC.EXE. Use the following steps to ; determine what the correct offset value would be: ; ; $ ANALYZE/SYSTEM ; SDA> EVALUATE CACHE$ACCESS-SYS$VCC_NPRW ; Hex: 00001188 Dec: 00004488 ; ^ ; | ; *** Use the displayed hexadecimal value in the following *** ; *** 2 locations: *** ; *** *** ; *** OFFSET: .LONG ^X *** ; *** subl2 #^x,r2 *** ; ************************************************************ ; ; Once the routine has been edited with the proper offset value do: ; ; $ MACRO VIOC_RST_CNT-AXP ; ( Ignore the AMAC-I-BRANCHBET informational message. ) ; $ LINK/SYSEXE/SYSLIB/SYSSHR VIOC_RST_CNT-AXP ; $ RUN VIOC_RST_CNT-AXP ; ; The counters to be reset are: ; (CACHE$ACCESS-) ; + 18 for CACHE$GL_VREAD, the Read IO counter ; + 1C for CACHE$GL_READHIT, the Read Hit counter ; + 20 for CACHE$GL_VWRITE, the Write IO counter ; + 24 for CACHE$GL_RRNDMOD, Read IO bypassing VIOC due to ; function counter ; + 28 CACHE$GL_RRNDSIZ, Read IO bypassing VIOC due to ; size counter ; + 2C CACHE$GL_WRNDMOD, Write IO bypassing VIOC due to ; function counter ; + 30 CACHE$GL_WRNDSIZ, Write IO bypassing VIOC due to ; size counter ; ;------------------------------------------------------------------------------- .library /sys$library:lib.mlb/ .link /sys$system:sys.stb/ ; ; USER mode routine to call the KERNEL mode routine which actually ; does all the work. ; .psect noexe ; ; Output warning and prompt for reply. ; warn_mess: .ascid /*************** THIS ROUTINE MAY CAUSE A SYSTEM - CRASH ***************** / warn_mess1: .ascid /This routine must be linked with the correct - offset into the VIOC code. / warn_mess2: .ascid /This version of the routine has been linked with - an offset of !8XL. / ;; warn_mess3: .ascid /To determine the correct offset, access SDA and - execute the command, / warn_mess4: .ascid /"SDA> EVALUATE CACHE$ACCESS-SYS$VCC_NPRW". / prompt: .ascid /Do you want to continue? (y-n)[n]: / resp: .long 80 .address resp_len resp_len: .blkb 80 respc: .long 1 OFFSET: .LONG ^X ; .PSECT code,exe .entry start, ^m ; begin: pushal warn_mess ; Output the warning message. calls #1, g^lib$put_output ; pushal warn_mess1 ; calls #1, g^lib$put_output ; movc5 #0,#0,#20,#80,resp_len ;; zero buffer movl #80,resp ;; $fao_s ctrstr=warn_mess2,- ;; outbuf=resp,- ;; p1=offset ;; pushal resp ;; calls #1, g^lib$put_output ;; pushal warn_mess3 ; calls #1, g^lib$put_output ; pushal warn_mess4 ; calls #1, g^lib$put_output ; pushal resp ; Prompt for a reply pushal prompt ; pushal resp ; calls #3, g^lib$get_input ; cmpb #^A/n/,resp_len ;; Check the replys. "n" beql donenow ;; cmpb #^A/N/,resp_len ;; "N" beql donenow ;; cmpb #^A/ /,resp_len ;; " ", beql donenow ;; cmpb #^A/y/,resp_len ;; "y" beql resetum ;; cmpb #^A/Y/,resp_len ;; "Y" beql resetum ;; brw donenow ; ; CHKRNL and call reset_counts routine. ; resetum: $cmkrnl_s routin=reset_counts brw donenow ; ; KERNEL mode routine to reset all VIOC statistic counters seen ; from the SHOW MEMORY/CACHE/FULL command. ; .entry reset_counts, ^m lock lockname=MMG ; lock MMG spinlock(synchronize) ; ; In order to find the head of the array that contains the VIOC counters ; we need to start with a cache global location known to the system. ; ; (There were many to choose from. I chose CACHE$ACCESS, a global) ; (address of a routine in SYS$VCC, because I liked the name. ) ; moval g^cache$access,r2 ; get value to help locate ; vcc database address ; ; Once we have the global address we need to fix the pointer to the ; head of AXPs VIOC array. This fix is done by subtracting the proper ; value. ; ; The proper value must be included before this routine will ; MAC or LINK. ; subl2 #^x,r2 ; point to top of array ; ; Reset the counters. ; clrl ^x18(r2) ; Reset Read count clrl ^x1c(r2) ; Reset Read hit clrl ^x20(r2) ; Reset Write cnt clrl ^x24(r2) ; Reset rrnd func clrl ^x28(r2) ; Reset rrnd siz clrl ^x2c(r2) ; Reset wrnd func clrl ^x30(r2) ; Reset wrnd siz ; unlock lockname=MMG ; Desynchronize ret ; ; Don't run, or finished. ; donenow: $exit_s .end start RELATED ARTICLES: Other articles in the OPENVMS database describe more on how the Virtual I/O Cache functions, on both OpenVMS VAX and Alpha. These articles can be found using search strings of: VIOC Virtual I/O Cache Improves Read Performance VIOC SHOW MEMORY/CACHE/FULL VAX MEMORY RECLAMATION FROM VIOC