# %getperfcount() function

The %getperfcount() function returns
the D3 performance counters.

## 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:

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

---
Source: https://d3codex.com/pickbasic-flashbasic/percent-getperfcount-function/ - part of the D3Codex reference.