Skip to main content
Previous section   Next section

Monitoring Performance Using ^mgstat

This chapter describes the ^mgstat utility, a tool for collecting basic performance data.

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/.

You must call ^mgstat from the %SYS namespace, and can usethe following positional arguments:

Argument Description
sample time
This argument specifies the frequency (in seconds) for sampling counters. If not specified, the default is 2 seconds.
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
This argument specifies the maximum number of samples to be obtained. If not specified, the default is 10 iterations.
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
This arguments specifies the filename for the .mgst file that ^mgstat generates, relative to install-dir\mgr. If not specified, the default filename is ServerName_InstanceName_Date_Time.mgst.
page length
If you run ^mgstat interactively, this argument specifies the number of lines to display before the header rows are repeated. The default is 0, which displays the header once at the beginning of the page; if you specify a value less than 5 lines (other than 0), ^mgstat increases it to 5.
Note:
This argument is ignored when you run ^mgstat as a background job.

For example, if 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)
Copy code to clipboard

Alternatively, if running ^mgstat interactively, to specify the same samplings redisplay the headings after each 10 rows of data, enter the following:

%SYS>DO ^mgstat(5,17280,,10)
Copy code to clipboard

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 install-dir\mgr directory of the InterSystems IRIS® data platform instance; however, if the output directory has been changed through the ^SystemsPerformance utility (see Change Output Directory in the “Monitoring Performance Using ^SystemsPerformance” chapter in this guide), ^mgstat uses that output directory.

Note:

The mgst file is also generated when you run the ^SystemsPerformance utility and included in the HTML performance report (see the “Monitoring Performance Using ^SystemsPerformance” 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), 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 distributed cache cluster 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 IRISTEMP.
Not per second.
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.
 
RouCMs
Number of Routine Cache Misses.
 
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.
IJUCnt
Number of jobs that WD is waiting for to continue this cycle.
Not per second.
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.
PPGrefs The count of all process private global accesses.  
PPGupds The count of all process private global updates.  

* 0 is displayed unless this is an ECP configuration.

Seize statistics are not included in the report unless the CollectResourceStats parameter in the CPF is enabled.

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.