The %getperfcount() function returns the D3 performance counters.
n = %getperfcount(buffer, MAXBUF)
| n | Number of characters returned in the buffer. If n = -1, the buffer size is too small. |
| buffer | Specifies the buffer in which to return a dynamic array of the performance count information. |
| MAXBUF | Specifies the maximum size for the buffer. |
The example program below illustrates displaying the performance counter.
include dm,bp,includes nt_util.inc equ MAXBUF to 512 char buffer[MAXBUF] n = %getperfcount( buffer, MAXBUF ) if n > 0 print buffer
This returns a display of the following performance counters:
Reads: 117988 Writes: 4008 ItemLocks: 2 GroupLocks: 0 Opens: 36245 MemoryFull: 0 OvfAdds: 1 OvfReads: 16413 CacheMiss: 16823
| Reads | Represents the number of times per second a record was read. Note: This does not necessarily imply a disk I/O.
|
| Writes | Represents the number of times per second a record was written. Note: This does not necessarily imply a disk I/O.
|
| ItemLocks | Represents the number of times per second a thread failed to acquire an item lock. |
| GroupLocks | Represents the number of times per second a thread failed to acquire a group lock. Group locks are internal locks set when a table is modified. High group lock counts indicate that small tables are accessed by many threads. A solution might be to increase the modulo of these tables. |
| Opens | Represents the number of times per second a table was opened.
If this number is consistently high, it may be an indication of an
application problem that keeps opening files and never closes them. Note: The VME caches file descriptors. As a result, it does not hurt to
leave files open. Generally, Visual Basic OLE applications do not
have access to such a cache. Therefore, a rogue Visual BASIC application
that loops opening files can create this kind of problem.
|
| MemoryFull | Represents the number of times per second the server failed to map a page in memory because all entries are in use. This counter should always be null. If this counter becomes non-null, it is an indication that the memory is too small for the application. If the physical memory is already above 2 GB of memory, splitting the database across two or more servers could help solve this problem. |
| OvfAdds | Represents the number of times per second a table was extended. If this number is consistently not null, it is an indication that one or more files are severely undersized and are in the process of being populated. |
| OvfReads | Represents the number of times per second poorly-sized tables
are accessed. If this number is consistently not null, it is an indication
that one or more files are severely undersized and are accessed heavily. A high ratio (Ovf Read / ( Read + Write ) is an indication that there are one or more frequently used files that are poorly sized. It is important to locate these files and resize them. The D3 File Manager has a tool to scan a database for poorly sized files and, currently, they can be resized using the nt_resize utility from the VME (see the D3 Reference Manual). Determining that the ratio is high depends on the capability of the system. A 50% ratio would start to be problematic. Approaching 100% will likely degrade performance. |
| CacheMiss | Represents the number of times per second a given page was not found in the mapped pages. Each cache miss does not necessarily trigger a disk I/O, because the missing page can still be in the Windows disk cache. |