Caché Monitoring Guide
Monitoring Performance Using ^mgstat
[Back] [Next]
   
Server:docs1
Instance:LATEST
User:UnknownUser
 
-
Go to:
Search:    

This chapter describes the ^mgstat utility, a tool for collecting basic performance data. The utility works with all versions of Caché since release 5.0.

Note:
This utility may be updated between releases. Contact the InterSystems Worldwide Response Center (WRC) for information about downloading newmgstat.xml from ftp://ftp.intersys.com/pub/performance/.
The calling sequence uses the following arguments:
Argument Description
sample time
Required. This argument specifies the frequency (in seconds) for sampling counters; defaults to 2 seconds if sample time is not specified.
If you specify a sample time greater than 10 seconds, ^mgstat reduces it to 10 seconds. See the number of samples argument in this table.
number of samples
Required. This argument specifies the maximum number of samples to be obtained; defaults to 10 iterations if number of samples is not specified.
If ^mgstat reduces the sample time, it increases the specified number of samples to ensure that the duration (sample time * number of samples) of the run is effectively the same as it would have been if none of the arguments were modified.
filename
Optional. This argument is used only by other WRC performance tools.
page length
Optional. If you run ^mgstat interactively, this argument specifies the number of lines to display before the header rows are repeated.
This argument is ignored when you run ^mgstat as a background job.
If you specify a page length less than 5 lines, ^mgstat increases it to 5 lines; if you omit this argument or specify a page length of 0, ^mgstat displays the header once, at the beginning of the page.
For example, running ^mgstat as a background job to specify that file samples be obtained every 5 seconds until 17280 samplings are obtained (in the Caché Terminal, from the %SYS namespace), enter the following:
%SYS> JOB ^mgstat(5,17280)
Alternatively, running ^mgstat interactively to specify the same samplings, and to redisplay the headings after each 10 rows of data, enter the following:
%SYS> DO ^mgstat(5,17280,,10)
By default ^mgstat generates a filename based on the server name, configuration name, and date and time, with the mgst” extension, which is recognized by an analyzer tool written in Microsoft Excel that aids graphing of the data. By default, the file is located in the manager's directory of the Caché instance (install-dir\mgr); if, however, the output directory has been changed through the ^pButtons utility (see Change Output Directory in the “Monitoring Performance Using ^pButtons” chapter in this guide), ^mgstat uses that output directory.
Note:
The mgst file is also generated when you run the ^pButtons utility (see the Monitoring Performance Using ^pButtons chapter in this guide.
For OpenVMS systems, where filenames are restricted to a limited length, the filename may be truncated, but the date and time stamp are always present.
To ensure minimal impact on system performance, the ^mgstat utility extracts various counter information from shared memory. If the utility is running and an apparent performance issue occurs, data is available to help you investigate the problem; for assistance with your analysis, contact the InterSystems Worldwide Response Center (WRC), which can provide tasks that automate both the running of ^mgstat and the purging of files.
Most of the reported data is averaged in per-second values, except as noted in the table below. The generated output file is in a readable, comma-separated value (CSV) format, which is more easily interpreted with a spreadsheet tool such as Microsoft Excel. The first line of the file is a header line which includes the filename and the utility version. as well information about buffer allocation and the version of the product being monitored. The number of columns of data depends on the version of the product: the first two columns are the date and time; the remaining columns are:
Column Description Notes
Glorefs
Global references (database accesses).
Indicates the amount of work that is occurring on behalf of the current workload; although global references consume CPU time, they do not always require physical reads because of the buffer pool.
 
RemGrefs *
Remote global references (database accesses).
Indicates the number of global references that are generated on behalf of ECP application servers.
 
GRratio
Ratio of global references to remote global references.
 
PhyRds
Physical reads from disk.
A high number of physical reads may indicate a performance problem; you can improve the performance by increasing the number of database (global) buffers.
 
Rdratio
Ratio of logical block reads to physical block reads, but zero if physical block reads is zero.
 
Gloupds
Global updates (sets or kills).
 
RemGupds *
Remote global updates.
 
Rourefs
Routine references (includes tag^routine).
 
RemRrefs *
Remote routine references.
 
RouLaS
Routine loads and saves (fetch from or save to disk).
A high number of routine loads/saves may indicate a performance problem; you can improve the performance by increasing the number of routine buffers.
 
RemRLaS *
Remote routine loads and saves.
 
PhyWrs
Physical writes to disk.
 
WDQsz
Write Daemon Queue size (in blocks).
Not per second.
WDtmpq
Updated blocks in CACHETEMP.
Not per second.
Not available in Caché 5.0.x.
WDphase
Phase of the Write Daemon.
The most common phases are:
  • 0: Idle (WD is not running)
  • 5: WD is updating the Write Image Journal (WIJ) file.
  • 7: WD is committing WIJ and Journal.
  • 8: Databases are being updated.
Not per second.
Wijwri
Number of 256-KB blocks written to the WIJ.
This is non-zero when the WD is writing data to the WIJ.
Not available in Caché 5.0.x.
RouCMs
Number of Routine Cache Misses.
Caché 2007.1 and higher.
Jrnwrts
Number of blocks written to journals.
 
GblSz
Number of seizes on the global resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
pGblNsz
Percentage of NSeizes on the global resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
pGblAsz
Percentage of ASeizes on the global resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
RouSz
Number of seizes on the routine resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
pRouAsz
Percentage of ASeizes on the routine resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
ObjSz
Number of seizes on the object resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
pObjAsz
Percentage of ASeizes on the object resource; see Considering Seizes, ASeizes, and NSeizes in this chapter.
 
ActECP
Number of active ECP connections.
Not per second.
Addblk
Number of blocks added to ECP Client’s cache.
 
PrgBufL
Number of blocks purged from ECP Client’s cache due to global buffer shortage (on the ECP Client).
A high number may indicate a performance problem on the ECP client; you can improve performance by increasing the number of global buffers on the ECP Client.
 
PrgSrvR
Number of blocks purged from ECP Client’s cache by ECP server.
 
BytSnt
Number of bytes sent as an ECP Client.
 
BytRcd
Number of bytes received as an ECP Client.
 
WDPass
WD cycle since startup.
Not per second.
Not available in Caché 5.0.x.
IJUCnt
Number of jobs that WD is waiting for to continue this cycle.
Not per second.
Not available in Caché 5.0.x.
IJULock
Indicates whether or not the IJULock flag is set .
If IJULock is set, all updates are locked out while the WD finalizes the write cycle.
Not per second.
Not available in Caché 5.0.x.
ECP data displayed only for ECP configurations.
* 0 is displayed unless this is an ECP configuration.
Considering Seizes, ASeizes, and NSeizes
A Seize occurs whenever a job needs exclusive access on a given resource to guarantee that an update occurs without interference from other processes. If the Seize is not immediately satisfied, the update is postponed until it is satisfied.
On a single-CPU system, the process immediately hibernates (because it cannot do anything until the process holding the resource relinquishes it, which does not occur until after its own update completes).
On a multiple-CPU system, the process enters a holding loop in the “hope” that it will gain the resource in a reasonable time, thus avoiding the expense of hibernating. If the process gets access to the resource during the hold loop, the loop immediately exits and the process continues with its update; upon completing the update, the process relinquishes the resource for other processes that may be waiting for it; this is an Aseize. If, at the end of the hold loop, the resource is still held by another process, the process continues to hibernate and wait to be woken up when the resource is released; this is an Nseize.
Nseizes are a natural consequence of running multiple processes on a single-CPU system; Aseizes are a natural consequence of running multiple processes on a multi-CPU system. The difference is that Nseizes incur system, or privileged, CPU time because the operating system must change the context of the running process, whereas an Aseize incurs user time on the CPU because it continues to run until the resource is gained and released, or until it gives up and hibernates. In general, on multi-CPU systems it is more expensive for the operating system to do the context switch than to loop a few times to avoid this operation because there is both CPU overhead and memory latency associated with context switching on multi-CPU systems.