%getperfcount() Function

The %getperfcount() function returns the D3 performance counters. The OpenSSL libraries must be loaded to use this function.

Syntax

n = %getperfcount( buffer, MAXBUF )

Parameter(s)

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.

Example(s)

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:

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.