Skip to main content

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.

FeedbackOpens in a new tab