Skip to main content

Monitoring Performance Using ^mgstat

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

Running ^mgstat

You must call ^mgstat in the %SYS namespace. You can use the following positional arguments:

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

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

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

  4. 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, in the %SYS namespace), enter the following:

%SYS>JOB ^mgstat(5,17280)

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)

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 ^SystemPerformance utility (see Change Output Directory), ^mgstat uses that output directory.

Note:

The .mgst file is also generated when you run the ^SystemPerformance utility and included in the HTML performance report (see Monitoring Performance Using ^SystemPerformance).

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.

Data Provided by ^mgstat

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.

 
pGblNsz

Percentage of NSeizes on the global resource; see Considering Seizes, ASeizes, and NSeizes.

 
pGblAsz

Percentage of ASeizes on the global resource; see Considering Seizes, ASeizes, and NSeizes.

 
RouSz

Number of seizes on the routine resource; see Considering Seizes, ASeizes, and NSeizes.

 
pRouAsz

Percentage of ASeizes on the routine resource; see Considering Seizes, ASeizes, and NSeizes.

 
ObjSz

Number of seizes on the object resource; see Considering Seizes, ASeizes, and NSeizes.

 
pObjAsz

Percentage of ASeizes on the object resource; see Considering Seizes, ASeizes, and NSeizes.

 
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.

Considering Seizes, ASeizes, and NSeizes

Note:

Seize statistics are included if the underlying system is collecting them; more information can be found in the Config.MiscellaneousOpens in a new tab class; see the CollectResourceStats property.

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.

See Also

FeedbackOpens in a new tab