You can use the %getperfcount() function from FlashBASIC to obtain these performance counters.
See File System Memory Usage in the Administrators Guide for a brief overview of host memory, which aids in understanding the following counters.
| Cache Hits/s | Represents the number of times per second
a given page was found in the mapped pages. Note: A mapped page is
not necessarily in physical memory since Windows can have flushed
the file cache. This situation should only arise in extreme cases.
|
| Cache Misses/s | 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. |
| Flush/s | Represents the number of times per second an explicit disk write was triggered. Disk writes are performed by a background thread controlled by the registry entry FlushPeriod. Note: This does not
include the cache flushes Windows may do on its own.
|
| Group Locks/s | 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. |
| Item Locks/s | Represents the number of times per second a thread failed to acquire an item lock. |
| Mem Full/s | 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. |
| Open/s | 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.
|
| Ovf Add/s | 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. |
| Ovf Read/s | 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. |
| Read/s | Represents the number of times per second a record was read. Note: This does not necessarily imply a disk I/O.
|
| Writes/s | Represents the number of times per second a record was written. Note: This does not necessarily imply a disk I/O.
|