Monitoring Performance Using ^mgstat

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)Opens in a new tab for information about downloading newmgstat.xml from ftp://ftp.intersys.com/pub/performance/Opens in a new tab.

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. Note: 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. Note: 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. Note: 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 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.

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)Opens in a new tab, 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.