United States-English

» Contact HP

HP OpenVMS Systems


OpenVMS information
	»	What's new on our site
	»	Upcoming events
	»	Configuration and buying assistance
	»	Send us your comments



HP OpenVMS systems
	»	OpenVMS software
	»	Supported Servers
	»	OpenVMS virtualization
	»	OpenVMS solutions and partners
	»	OpenVMS success stories
	»	OpenVMS service and support
	»	OpenVMS resources and information
	»	OpenVMS documentation
	»	Education and training



Evolving business value
	»	Business Systems Evolution
	»	AlphaServer systems transition planning
	»	Alpha RetainTrust program



Related links
	»	HP Integrity servers
	»	HP Alpha systems
	»	HP storage
	»	HP software
	»	HP products and services
	»	HP solutions
	»	HP support

HP OpenView Performance Agent for OpenVMS
Dictionary of Operating System Performance Metrics

Print Date 01/2006
OVPA for OpenVMS V1.0 based on Release C.04.00

Copyright (c) 2005,2006 Hewlett-Packard Company, Inc.
All rights reserved.

Introduction:

This dictionary contains definitions of the OpenVMS operating system performance metrics for HP OpenView Performance Agent. This document is divided into the following sections:

"Metric Names by Data Class," which lists the metrics alphabetically by data class. Use these metric names for exporting data with the extract utility. You can also use these metric names in defining alarm conditions in your alarmdef file.
"Metric Definitions," which describes each metric in alphabetical order.

Please note that the metric help has been put in a more generic format and references are made to the other platforms that also support each of the metrics.

Metric Names by Data Class

OpenVMS GLOBAL Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
GBL_ACTIVE_CPU
GBL_ACTIVE_PROC
GBL_ALIVE_PROC
GBL_CPU_IDLE_TIME
GBL_CPU_IDLE_UTIL
GBL_CPU_NICE_TIME
GBL_CPU_NICE_UTIL
GBL_CPU_SYS_MODE_TIME
GBL_CPU_SYS_MODE_UTIL
GBL_CPU_TOTAL_TIME
GBL_CPU_TOTAL_UTIL
GBL_CPU_USER_MODE_TIME
GBL_CPU_USER_MODE_UTIL
GBL_DISK_PHYS_BYTE
GBL_DISK_PHYS_BYTE_RATE
GBL_DISK_PHYS_IO
GBL_DISK_PHYS_IO_RATE
GBL_DISK_PHYS_READ
GBL_DISK_PHYS_READ_BYTE_RATE
GBL_DISK_PHYS_READ_RATE
GBL_DISK_PHYS_WRITE
GBL_DISK_PHYS_WRITE_BYTE_RATE
GBL_DISK_PHYS_WRITE_RATE
GBL_DISK_REQUEST_QUEUE
GBL_DISK_TIME_PEAK
GBL_DISK_UTIL
GBL_DISK_UTIL_PEAK
GBL_FS_SPACE_UTIL_PEAK
GBL_INTERRUPT
GBL_INTERRUPT_RATE
GBL_INTERVAL
GBL_LOADAVG
GBL_LOST_MI_TRACE_BUFFERS
GBL_MEM_CACHE
GBL_MEM_CACHE_UTIL
GBL_MEM_FREE
GBL_MEM_FREE_UTIL
GBL_MEM_PAGEIN
GBL_MEM_PAGEIN_BYTE
GBL_MEM_PAGEIN_BYTE_RATE
GBL_MEM_PAGEIN_RATE
GBL_MEM_PAGEOUT
GBL_MEM_PAGEOUT_BYTE
GBL_MEM_PAGEOUT_BYTE_RATE
GBL_MEM_PAGEOUT_RATE
GBL_MEM_PAGE_REQUEST
GBL_MEM_PAGE_REQUEST_RATE
GBL_MEM_SWAPIN_BYTE
GBL_MEM_SWAPIN_BYTE_RATE
GBL_MEM_SWAPOUT_BYTE
GBL_MEM_SWAPOUT_BYTE_RATE
GBL_MEM_SYS
GBL_MEM_SYS_UTIL
GBL_MEM_USER
GBL_MEM_USER_UTIL
GBL_MEM_UTIL
GBL_NET_COLLISION
GBL_NET_COLLISION_1_MIN_RATE
GBL_NET_COLLISION_PCT
GBL_NET_COLLISION_RATE
GBL_NET_ERROR
GBL_NET_ERROR_1_MIN_RATE
GBL_NET_ERROR_RATE
GBL_NET_IN_ERROR_PCT
GBL_NET_IN_PACKET
GBL_NET_IN_PACKET_RATE
GBL_NET_OUT_ERROR_PCT
GBL_NET_OUT_PACKET
GBL_NET_OUT_PACKET_RATE
GBL_NET_PACKET_RATE
GBL_NFS_CALL
GBL_NFS_CALL_RATE
GBL_NUM_DISK
GBL_NUM_NETWORK
GBL_NUM_USER
GBL_PROC_SAMPLE
GBL_RUN_QUEUE
GBL_STARTED_PROC
GBL_STARTED_PROC_RATE
GBL_STATTIME
GBL_SWAP_SPACE_USED
GBL_SWAP_SPACE_USED_UTIL
GBL_SWAP_SPACE_UTIL
GBL_SYSTEM_UPTIME_HOURS
GBL_SYSTEM_UPTIME_SECONDS
GBL_TT_OVERFLOW_COUNT
TBL_FILE_LOCK_USED
TBL_FILE_LOCK_UTIL
TBL_INODE_CACHE_USED
TBL_SHMEM_ACTIVE
TBL_SHMEM_TABLE_USED
TBL_SHMEM_TABLE_UTIL
TBL_SHMEM_USED

OpenVMS APPLICATION Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
APP_ACTIVE_PROC
APP_ALIVE_PROC
APP_COMPLETED_PROC
APP_CPU_SYS_MODE_TIME
APP_CPU_SYS_MODE_UTIL
APP_CPU_TOTAL_TIME
APP_CPU_TOTAL_UTIL
APP_CPU_USER_MODE_TIME
APP_CPU_USER_MODE_UTIL
APP_MAJOR_FAULT
APP_MAJOR_FAULT_RATE
APP_MEM_RES
APP_MEM_UTIL
APP_MEM_VIRT
APP_MINOR_FAULT
APP_MINOR_FAULT_RATE
APP_NAME
APP_NUM
APP_PRI
APP_PROC_RUN_TIME
APP_SAMPLE

OpenVMS PROCESS Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
PROC_APP_ID
PROC_CPU_SYS_MODE_TIME
PROC_CPU_SYS_MODE_UTIL
PROC_CPU_TOTAL_TIME
PROC_CPU_TOTAL_TIME_CUM
PROC_CPU_TOTAL_UTIL
PROC_CPU_TOTAL_UTIL_CUM
PROC_CPU_USER_MODE_TIME
PROC_CPU_USER_MODE_UTIL
PROC_EUID
PROC_GROUP_ID
PROC_INTEREST
PROC_INTERVAL_ALIVE
PROC_MAJOR_FAULT
PROC_MEM_RES
PROC_MEM_VIRT
PROC_MINOR_FAULT
PROC_PAGEFAULT
PROC_PAGEFAULT_RATE
PROC_PARENT_PROC_ID
PROC_PRI
PROC_PROC_ARGV1
PROC_PROC_ID
PROC_PROC_NAME
PROC_RUN_TIME
PROC_STOP_REASON
PROC_THREAD_COUNT
PROC_TTY
PROC_USER_NAME

OpenVMS DISK Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
BYDSK_AVG_REQUEST_QUEUE
BYDSK_AVG_SERVICE_TIME
BYDSK_DEVNAME
BYDSK_DIRNAME
BYDSK_ID
BYDSK_PHYS_BYTE
BYDSK_PHYS_BYTE_RATE
BYDSK_PHYS_IO
BYDSK_PHYS_IO_RATE
BYDSK_PHYS_READ
BYDSK_PHYS_READ_BYTE
BYDSK_PHYS_READ_BYTE_RATE
BYDSK_PHYS_READ_RATE
BYDSK_PHYS_WRITE
BYDSK_PHYS_WRITE_BYTE
BYDSK_PHYS_WRITE_BYTE_RATE
BYDSK_PHYS_WRITE_RATE
BYDSK_REQUEST_QUEUE
BYDSK_UTIL

OpenVMS NETWORK INTERFACE Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
BYNETIF_COLLISION
BYNETIF_COLLISION_1_MIN_RATE
BYNETIF_COLLISION_RATE
BYNETIF_ERROR
BYNETIF_ERROR_1_MIN_RATE
BYNETIF_ERROR_RATE
BYNETIF_ID
BYNETIF_IN_BYTE
BYNETIF_IN_BYTE_RATE
BYNETIF_IN_BYTE_RATE_CUM
BYNETIF_IN_PACKET
BYNETIF_IN_PACKET_RATE
BYNETIF_NAME
BYNETIF_OUT_BYTE
BYNETIF_OUT_BYTE_RATE
BYNETIF_OUT_BYTE_RATE_CUM
BYNETIF_OUT_PACKET
BYNETIF_OUT_PACKET_RATE
BYNETIF_PACKET_RATE

OpenVMS CPU Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
BYCPU_CPU_CLOCK
BYCPU_CPU_SYS_MODE_TIME
BYCPU_CPU_SYS_MODE_UTIL
BYCPU_CPU_TOTAL_TIME
BYCPU_CPU_TOTAL_UTIL
BYCPU_CPU_USER_MODE_TIME
BYCPU_CPU_USER_MODE_UTIL
BYCPU_ID
BYCPU_INTERRUPT
BYCPU_INTERRUPT_RATE
BYCPU_STATE

OpenVMS FILESYSTEM Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
FS_BLOCK_SIZE
FS_DEVNAME
FS_DEVNO
FS_DIRNAME
FS_FRAG_SIZE
FS_INODE_UTIL
FS_MAX_INODES
FS_MAX_SIZE
FS_SPACE_RESERVED
FS_SPACE_USED
FS_SPACE_UTIL
FS_TYPE

OpenVMS CONFIGURATION Metrics
BLANK
DATE
DATE_SECONDS
DAY
INTERVAL
RECORD_TYPE
TIME
YEAR
GBL_BOOT_TIME
GBL_COLLECTOR
GBL_CPU_CLOCK
GBL_DISTRIBUTION
GBL_GMTOFFSET
GBL_LOGFILE_VERSION
GBL_LOGGING_TYPES
GBL_MACHINE
GBL_MACHINE_MODEL
GBL_MEM_AVAIL
GBL_MEM_PHYS
GBL_NUM_APP
GBL_NUM_CPU
GBL_NUM_DISK
GBL_NUM_NETWORK
GBL_OSKERNELTYPE_INT
GBL_OSNAME
GBL_OSRELEASE
GBL_OSVERSION
GBL_SUBPROCSAMPLEINTERVAL
GBL_SWAP_SPACE_AVAIL
GBL_SWAP_SPACE_AVAIL_KB
GBL_SYSTEM_ID
GBL_THRESHOLD_CPU
GBL_THRESHOLD_NOKILLED
GBL_THRESHOLD_NONEW
GBL_THRESHOLD_PROCMEM
TBL_FILE_LOCK_AVAIL
TBL_INODE_CACHE_AVAIL
TBL_SHMEM_TABLE_AVAIL

METRIC DEFINITIONS

APP_ACTIVE_PROC

An active process is one that exists and consumes some CPU time. APP_ACTIVE_PROC is the sum of the alive-process-time/intervaltime ratios of every process belonging to an application that is active (uses any CPU time) during an interval.

The following diagram of a four second interval showing two processes, A and B, for an application should be used to understand the above definition. Note the difference between active processes, which consume CPU time, and alive processes which merely exist on the system.

     ----------- Seconds -----------

       1         2         3      4 

Proc

---- ----      ----      ----   ----

A    live      live      live   live

B    live/CPU  live/CPU  live   dead

Process A is alive for the entire four second interval, but consumes no CPU. A's contribution to APP_ALIVE_PROC is 4*1/4. A contributes 0*1/4 to APP_ACTIVE_PROC. B's contribution to APP_ALIVE_PROC is 3*1/4. B contributes 2*1/4 to APP_ACTIVE_PROC. Thus, for this interval, APP_ACTIVE_PROC equals 0.5 and APP_ALIVE_PROC equals 1.75.

Because a process may be alive but not active, APP_ACTIVE_PROC will always be less than or equal to APP_ALIVE_PROC.

This metric indicates the number of processes in an application group that are competing for the CPU. This metric is useful, along with other metrics, for comparing loads placed on the system by different groups of processes.

On non HP-UX systems, this metric is derived from sampled process data. Since the data for a process is not available after the process has died on this operating system, a process whose life is shorter than the sampling interval may not be seen when the samples are taken. Thus this metric may be slightly less than the actual value. Increasing the sampling frequency captures a more accurate count, but the overhead of collection may also rise.

APP_ALIVE_PROC

An alive process is one that exists on the system. APP_ALIVE_PROC is the sum of the alive-process-time/interval-time ratios for every process belonging to a given application.

     ----------- Seconds -----------

       1         2         3      4 

Proc

---- ----      ----      ----   ----

A    live      live      live   live

B    live/CPU  live/CPU  live   dead

Process A is alive for the entire four second interval but consumes no CPU. A's contribution to APP_ALIVE_PROC is 4*1/4. A contributes 0*1/4 to APP_ACTIVE_PROC. B's contribution to APP_ALIVE_PROC is 3*1/4. B contributes 2*1/4 to APP_ACTIVE_PROC. Thus, for this interval, APP_ACTIVE_PROC equals 0.5 and APP_ALIVE_PROC equals 1.75.

Because a process may be alive but not active, APP_ACTIVE_PROC will always be less than or equal to APP_ALIVE_PROC.

APP_COMPLETED_PROC

The number of processes in this group that completed during the interval.

APP_CPU_SYS_MODE_TIME

The time, in seconds, during the interval that the CPU was in system mode for processes in this group.

A process operates in either system mode (also called kernel mode on Unix or privileged mode on Windows) or user mode. When a process requests services from the operating system with a system call, it switches into the machine's privileged protection mode and runs in system mode.

On a system with multiple CPUs, this metric is normalized. That is, the CPU used over all processors is divided by the number of processors online. This represents the usage of the total processing capacity available.

APP_CPU_SYS_MODE_UTIL

The percentage of time during the interval that the CPU was used in system mode for processes in this group.

High system CPU utilizations are normal for IO intensive groups. Abnormally high system CPU utilization can indicate that a hardware problem is causing a high interrupt rate. It can also indicate programs that are not making efficient system calls.

APP_CPU_TOTAL_TIME

The total CPU time, in seconds, devoted to processes in this group during the interval.

APP_CPU_TOTAL_UTIL

The percentage of the total CPU time devoted to processes in this group during the interval. This indicates the relative CPU load placed on the system by processes in this group.

Large values for this metric may indicate that this group is causing a CPU bottleneck. This would be normal in a computationbound workload, but might mean that processes are using excessive CPU time and perhaps looping.

If the "other" application shows significant amounts of CPU, you may want to consider tuning your parm file so that process activity is accounted for in known applications.

   APP_CPU_TOTAL_UTIL =
     APP_CPU_SYS_MODE_UTIL + APP_CPU_USER_MODE_UTIL

NOTE: On Windows, the sum of the APP_CPU_TOTAL_UTIL metrics may not equal GBL_CPU_TOTAL_UTIL. Microsoft states that "this is expected behavior" because the GBL_CPU_TOTAL_UTIL metric is taken from the NT performance library Processor objects while the APP_CPU_TOTAL_UTIL metrics are taken from the Process objects. Microsoft states that there can be CPU time accounted for in the Processor system objects that may not be seen in the Process objects.

APP_CPU_USER_MODE_TIME

The time, in seconds, that processes in this group were in user mode during the interval.

User CPU is the time spent in user mode at a normal priority, at real-time priority (on HP-UX, AIX, and Windows systems), and at a nice priority.

APP_CPU_USER_MODE_UTIL

The percentage of time that processes in this group were using the CPU in user mode during the interval.

User CPU is the time spent in user mode at a normal priority, at real-time priority (on HP-UX, AIX, and Windows systems), and at a nice priority.

High user mode CPU percentages are normal for computationintensive groups. Low values of user CPU utilization compared to relatively high values for APP_CPU_SYS_MODE_UTIL can indicate a hardware problem or improperly tuned programs in this group.

APP_MAJOR_FAULT

The number of major page faults that required a disk IO for processes in this group during the interval.

APP_MAJOR_FAULT_RATE

The number of major page faults per second that required a disk IO for processes in this group during the interval.

APP_MEM_RES

On Unix systems, this is the size (in KB) of resident memory for processes in this group that were alive at the end of the interval. This consists of text, data, stack, as well as the process' portion of shared memory regions (such as, shared libraries, text segments, and shared data).

On HP-UX, for each process, resident memory (RSS) is calculated as

   RSS = sum of private region pages +
         (sum of shared region pages / number of references)

The number of references is a count of the number of attachments to the memory region. Attachments, for shared regions, may come from several processes sharing the same memory, a single process with multiple attachments, or combinations of these.

This value is only updated when a process uses CPU. Thus, under memory pressure, this value may be higher than the actual amount of resident memory for processes which are idle.

Refer to the help text for PROC_MEM_RES for additional information.

On Windows, this is the sum of the size (in KB) of the working sets for processes in this group during the interval. The working set counts memory pages referenced recently by the threads making up this group. Note that the size of the working set is often larger than the amount of pagefile space consumed.

APP_MEM_UTIL

On Unix systems, this is the approximate percentage of the system's physical memory used as resident memory by processes in this group that were alive at the end of the interval. This metric summarizes process private and shared memory in each application.

On Windows, this is an estimate of the percentage of the system's physical memory allocated for working set memory by processes in this group during the interval.

On HP-UX, this consists of text, data, stack, as well the process' portion of shared memory regions (such as, shared libraries, text segments, and shared data). The sum of the shared region pages is divided by the number of references.

On all other Unix systems, this consists of text, data, stack, as well as an estimate of the process' portion of shared memory.

On Unix systems, each application's total resident memory is summed. This value is then divided by the summed total of all applications resident memory and then multiplied by the ratio of available user memory versus total physical memory to arrive at a calculated percent of total physical memory. It must be remembered, however, that this is a calculated metric that shows the approximate percentage of the physical memory used as resident memory by the processes in this application during the interval.

On Windows, the sum of the working set sizes for each process in this group is kept as APP_MEM_RES. This value is divided by the sum of APP_MEM_RES for all applications defined on the system to come up with a ratio of this application's working set size to the total. This value is then multiplied by the ratio of available user memory versus total physical memory to arrive at a calculated percent of total physical memory.

This metric is not available for HP-UX MeasureWare Agent. It is available for HP-UX GlancePlus.

APP_MEM_VIRT

On Unix systems, this is the approximate size (in KB) of virtual memory for processes in this group that were alive at the end of the interval.

On Windows, this is the size (in KB) of paging file space used for processes in this group during the interval. This is the sum of the pagefile space used for all processes in this group. Groups of processes may have working set sizes (APP_MEM_RES) larger than the size of their pagefile space.

On AIX, this is the sum of the virtual memory region sizes for all processes in this group.

On all other Unix systems, this is the sum of the virtual memory region sizes for all processes in this group. Since this virtual memory size for each process includes shared regions, such as library text and data, the shared regions are counted multiple times in this metric. For example, if two processes are attached to a 10MB shared region, then 20MB is reported in this metric.

On Unix systems, this value is not affected by the reference count. As such, this metric can overestimate the virtual memory being used by processes in this group when they share memory regions.

APP_MINOR_FAULT

The number of minor page faults satisfied in memory (a page was reclaimed from one of the free lists) for processes in this group during the interval.

APP_MINOR_FAULT_RATE

The number of minor page faults per second satisfied in memory (pages were reclaimed from one of the free lists) for processes in this group during the interval.

APP_NAME

The name of the application (up to 20 characters). This comes from the parm file where the applications are defined.

The application called "other" captures all processes not aggregated into applications specifically defined in the parm file. In other words, if no applications are defined in the parm file, then all process data would be reflected in the "other" application.

APP_NUM

The sequentially assigned number of this application.

APP_PRI

On Unix systems, this is the average priority of the processes in this group during the interval.

On Windows, this is the average base priority of the processes in this group during the interval.

APP_PROC_RUN_TIME

The average run time for processes in this group that completed during the interval.

APP_SAMPLE

The number of samples of process data that have been averaged or accumulated during this sample.

BLANK

An empty field used for spacing reports. For example, this field can be used to create a blank column in a spreadsheet that may be used to sum several items.

BYCPU_CPU_CLOCK

The clock speed of the CPU in the current slot. The clock speed is in MHz for the selected CPU.

BYCPU_CPU_SYS_MODE_TIME

The time, in seconds, that this CPU was in system mode during the interval.

BYCPU_CPU_SYS_MODE_UTIL

The percentage of time that this CPU was in system mode during the interval.

BYCPU_CPU_TOTAL_TIME

The total time, in seconds, that this CPU was not idle during the interval.

BYCPU_CPU_TOTAL_UTIL

The percentage of time that this CPU was not idle during the interval.

BYCPU_CPU_USER_MODE_TIME

The time, in seconds, during the interval that this CPU was in user mode.

User CPU is the time spent in user mode at a normal priority, at real-time priority (on HP-UX, AIX, and Windows systems), and at a nice priority.

BYCPU_CPU_USER_MODE_UTIL

The percentage of time that this CPU was in user mode during the interval.

User CPU is the time spent in user mode at a normal priority, at real-time priority (on HP-UX, AIX, and Windows systems), and at a nice priority.

BYCPU_ID

The ID number of this CPU. On some Unix systems, such as SUN, CPUs are not sequentially numbered.

BYCPU_INTERRUPT

The number of device interrupts for this CPU during the interval.

BYCPU_INTERRUPT_RATE

The average number of device interrupts per second for this CPU during the interval.

On HP-UX, a value of "na" is displayed on a system with multiple CPUs.

BYCPU_STATE

A text string indicating the current state of a processor.

On HP-UX, this is either "enabled", "disabled" or "unknown". On all other systems, this is either "Offline", "Online" or "Unknown".

BYDSK_AVG_REQUEST_QUEUE

The average number of IO requests that were in the wait and service queues for this disk device over the cumulative collection time.

The cumulative collection time is defined from the point in time when either: a) the process (or kernel thread, if HP-UX) was first started, or b) the performance tool was first started, or c) the cumulative counters were reset (relevant only to GlancePlus, if available for the given platform), whichever occurred last.

For example, if 4 intervals have passed with average queue lengths of 0, 2, 0, and 6, then the average number of IO requests over all intervals would be 2.

Some Linux kernels, typically 2.2 and older kernels, do not support the instrumentation needed to provide values for this metric. This metric will be "na" on the affected kernels. The "sar -d" command will also not be present on these systems. Distributions and OS releases that are known to be affected include: TurboLinux 7, SuSE 7.2, and Debian 3.0.

BYDSK_AVG_SERVICE_TIME

The average time, in milliseconds, that this disk device spent processing each disk request during the interval. For example, a value of 5.14 would indicate that disk requests during the last interval took on average slightly longer than five onethousandths of a second to complete for this device.

This is a measure of the speed of the disk, because slower disk devices typically show a larger average service time. Average service time is also dependent on factors such as the distribution of I/O requests over the interval and their locality. It can also be influenced by disk driver and controller features such as I/O merging and command queueing. Note that this service time is measured from the perspective of the kernel, not the disk device itself. For example, if a disk device can find the requested data in its cache, the average service time could be quicker than the speed of the physical disk hardware.

This metric can be used to help determine which disk devices are taking more time than usual to process requests.

BYDSK_DEVNAME

The name of this disk device.

On HP-UX, the name identifying the specific disk spindle is the hardware path which specifies the address of the hardware components leading to the disk device.

On SUN, CDs and disks use the device name compliant with the SVR4 Interface Definition and the slice (partition) number is replaced with an asterisk. An example of a device name is "c0t3d0s*". These names are the same disk names displayed by "iostat'. Floppy devices are labeled with the device file name link from the /dev directory where "#" specifies a floppy device instance. See the man page for "disks" if your device labels are not SVID format. For more information about "instances", see the "path_to_inst" man page.

On AIX, this is the path name string of this disk device. This is the fsname parameter in the mount(1M) command. If more than one file system is contained on a device (that is, the device is partitioned), this is indicated by an asterisk ("*") at the end of the path name.

On OSF1, this is the path name string of this disk device. This is the file-system parameter in the mount(1M) command.

On Windows, this is the unit number of this disk device.

BYDSK_DIRNAME

The name of the file system directory mounted on this disk device. If more than one file system is mounted on this device, "Multiple FS" is seen.

BYDSK_ID

The ID of the current disk device. This is an identification number assigned to the disk device by scope.

BYDSK_PHYS_BYTE

The number of KBs of physical IOs transferred to or from this disk device during the interval.

On Unix systems, this includes all types of physical disk IOs including file system, virtual memory, and raw IO. The average KB transferred to or from the current disk device during the interval.

BYDSK_PHYS_BYTE_RATE

The average KBs per second transferred to or from this disk device during the interval.

On Unix systems, this includes all types of physical disk IOs including file system, virtual memory, and raw IOs.

BYDSK_PHYS_IO

The number of physical IOs for this disk device during the interval.

BYDSK_PHYS_IO_RATE

The average number of physical IO requests per second for this disk device during the interval.

On Unix systems, this counts disk reads and writes of all types, including virtual memory and raw IO.

BYDSK_PHYS_READ

The number of physical reads for this disk device during the interval.

On AIX, this is an estimated value based on the ratio of read bytes to total bytes transferred. The actual number of reads is not tracked by the kernel. This is calculated as

   BYDSK_PHYS_READ =
     BYDSK_PHYS_IO * (BYDSK_PHYS_READ_BYTE / BYDSK_PHYS_IO_BYTE)

BYDSK_PHYS_READ_BYTE

The KBs transferred from this disk device during the interval.

On Unix systems, all types of disk reads are counted, including file system, virtual memory, and raw IO.

BYDSK_PHYS_READ_BYTE_RATE

The average KBs per second transferred from this disk device during the interval.

On Unix systems, all types of disk reads are counted, including file system, virtual memory, and raw IO.

On OpenVMS, data will only be available when the disk has at approximately 30 read I/Os per interval.

BYDSK_PHYS_READ_RATE

The average number of physical reads per second for this disk device during the interval.

On AIX, this is an estimated value based on the ratio of read bytes to total bytes transferred. The actual number of reads is not tracked by the kernel. This is calculated as

   BYDSK_PHYS_READ_RATE =
     BYDSK_PHYS_IO_RATE * (BYDSK_PHYS_READ_BYTE / BYDSK_PHYS_IO_BYTE)

BYDSK_PHYS_WRITE

The number of physical writes for this disk device during the interval.

On AIX, this is an estimated value based on the ratio of write bytes to total bytes transferred because the actual number of writes is not tracked by the kernel. This is calculated as

   BYDSK_PHYS_WRITE =
     BYDSK_PHYS_IO * (BYDSK_PHYS_WRITE_BYTE / BYDSK_PHYS_IO_BYTE)

BYDSK_PHYS_WRITE_BYTE

The KBs transferred to this disk device during the interval.

On Unix systems, all types of disk writes are counted, including file system, virtual memory, and raw IO.

BYDSK_PHYS_WRITE_BYTE_RATE

The average KBs per second transferred to this disk device during the interval.

On Unix systems, all types of disk writes are counted, including file system, virtual memory, and raw IO.

On OpenVMS, data will only be available when the disk has at approximately 30 write I/Os per interval.

BYDSK_PHYS_WRITE_RATE

The average number of physical writes per second for this disk device during the interval.

On AIX, this is an estimated value based on the ratio of write bytes to total bytes transferred. The actual number of writes is not tracked by the kernel. This is calculated as

   BYDSK_PHYS_WRITE_RATE =
     BYDSK_PHYS_IO_RATE * (BYDSK_PHYS_WRITE_BYTE / BYDSK_PHYS_IO_BYTE)

BYDSK_REQUEST_QUEUE

The average number of IO requests that were in the wait queue for this disk device during the interval. These requests are the physical requests (as opposed to logical IO requests).

BYDSK_UTIL

On HP-UX, this is the percentage of the time during the interval that the disk device had IO in progress from the point of view of the Operating System. In other words, the utilization or percentage of time busy servicing requests for this device.

On the non-HP-UX systems, this is the percentage of the time that this disk device was busy transferring data during the interval.

This is a measure of the ability of the IO path to meet the transfer demands being placed on it. Slower disk devices may show a higher utilization with lower IO rates than faster disk devices such as disk arrays. A value of greater than 50% utilization over time may indicate that this device or its IO path is a bottleneck, and the access pattern of the workload, database, or files may need reorganizing for better balance of disk IO load.

On OpenVMS, data will only be available when the disk has a non-zero read/write I/Os per interval.

DATE

The date the information in this record was captured, based on local time. The date is an ASCII field in mm/dd/yy format unless localized. If localized, the separators may be different and the subfield may be in a different sequence. In ASCII files this field will always contain 8 characters. Each subfield (mm, dd, yy) will contain a leading zero if the value is less than 10. This metric is extracted from GBL_STATTIME, which is obtained using the time() system call at the time of data collection.

This field responds to language localization. For example, in Germany the field would appear as dd.mm.yy and in Italy it would be dd/mm/yy.

In binary files this field is in MPE CALENDAR format in the least significant 16 bits of the field. The most significant 16 bits should all be zero. Dividing the field by 512 will isolate the year (that is, 94). This field MOD 512 will isolate the day of the year.

DATE_SECONDS

The time that the data in this record was captured, expressed in seconds since January 1, 1970, based on local time. This is related to the standard time-stamp returned by the unix system call time(), but has had the local time zone correction applied.

DAY

The julian day of the year that the data in this record was captured. This metric is extracted from GBL_STATTIME.

BYNETIF_COLLISION

The number of physical collisions that occurred on the network interface during the interval. A rising rate of collisions versus outbound packets is an indication that the network is becoming increasingly congested. This metric does not currently include deferred packets.

This data is not collected for non-broadcasting devices, such as loopback (lo), and is always zero.

For HP-UX 10.20 and other Unix systems, this is the same as the sum of the "Coll" column from the "netstat -i" command for a network device. See also netstat(1).

For HP-UX 11.0 and beyond, this metric will be the same as the sum of the "Single Collision Frames", "Multiple Collision Frames", "Late Collisions", and "Excessive Collisions" values from the output of the "lanadmin" utility for the network interface. Remember that "lanadmin" reports cumulative counts. For this release and beyond, "netstat -i" shows network activity on the logical level (IP) only.

AIX does not support the collision count for ethernet interface. The collision count is supported for token ring (tr) and loopback (lo) interface.

Physical statistics are packets recorded by the network drivers. These numbers most likely will not be the same as the logical statistics. The values returned for the loopback interface will show "na" for the physical statistics since there is no network driver activity.

Logical statistics are packets seen only by the Interface Protocol (IP) layer of the networking subsystem. Not all packets seen by IP will go out and come in through a network driver. Examples cases are the 127.0.0.1 (loopback interface). Pings or other network generating commands (ftp, rlogin, and so forth) to 127.0.0.1 will not change physical driver statistics. Pings to IP addresses on remote systems will change physical driver statistics.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_COLLISION_1_MIN_RATE

The number of physical collisions per minute on the network interface during the interval. A rising rate of collisions versus outbound packets is an indication that the network is becoming increasingly congested. This metric does not currently include deferred packets.

This data is not collected for non-broadcasting devices, such as loopback (lo), and is always zero.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_COLLISION_RATE

The number of physical collisions per second on the network interface during the interval. A rising rate of collisions versus outbound packets is an indication that the network is becoming increasingly congested. This metric does not currently include deferred packets.

This data is not collected for non-broadcasting devices, such as loopback (lo), and is always zero.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_ERROR

The number of physical errors that occurred on the network interface during the interval. An increasing number of errors may indicate a hardware problem in the network.

On Unix systems, this data is not available for loop-back (lo) devices and is always zero.

For HP-UX 10.20 and other Unix systems, this is the same as the sum of "Ierrs" (RX errors: or RX-ERR on Linux) and "Oerrs" (TX errors: or TX-ERR on Linux) from the "netstat -i" command for a network device. See also netstat(1).

For HP-UX 11.0 and beyond, this metric will be the same as the sum of the "Inbound Errors" and "Outbound Errors" values from the output of the "lanadmin" utility for the network interface. Remember that "lanadmin" reports cumulative counts. For this release and beyond, "netstat -i" shows network activity on the logical level (IP) only.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_ERROR_1_MIN_RATE

The number of physical errors per minute on the network interface during the interval.

On Unix systems, this data is not available for loop-back (lo) devices and is always zero.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_ERROR_RATE

The number of physical errors per second on the network interface during the interval.

On Unix systems, this data is not available for loop-back (lo) devices and is always zero.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_ID

The ID number of the network interface.

BYNETIF_IN_BYTE

The number of KBs received from the network via this interface during the interval. Only the bytes in packets that carry data are included in this rate.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

This metric is available on HP-UX 11.0 and beyond.

BYNETIF_IN_BYTE_RATE

The number of KBs per second received from the network via this interface during the interval. Only the bytes in packets that carry data are included in this rate.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

This metric is available on HP-UX 11.0 and beyond.

BYNETIF_IN_BYTE_RATE_CUM

The average number of KBs per second received from the network via this interface over the cumulative collection time. Only the bytes in packets that carry data are included in this rate.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

This metric is available on HP-UX 11.0 and beyond.

BYNETIF_IN_PACKET

The number of successful physical packets received through the network interface during the interval. Successful packets are those that have been processed without errors or collisions.

For HP-UX 10.20 and other Unix systems, this is the same as the sum of the "Ipkts" column (or RX on Linux) from the "netstat -i" command for a network device. See also netstat(1).

For HP-UX 11.0 and beyond, this metric will be the same as the sum of the "Inbound Unicast Packets" and "Inbound Non-Unicast Packets" values from the output of the "lanadmin" utility for the network interface. Remember that "lanadmin" reports cumulative counts. For this release and beyond, "netstat -i" shows network activity on the logical level (IP) only.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_IN_PACKET_RATE

The number of successful physical packets per second received through the network interface during the interval. Successful packets are those that have been processed without errors or collisions.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_NAME

The name of the network interface.

For HP-UX 11.0 and beyond, these are the same names that appear in the "Description" field of the "lanadmin" command output.

On all other Unix systems, these are the same names that appear in the "Name" column of the "netstat -i" command.

Some examples of device names are:

lo - loop-back driver
ln - Standard Ethernet driver
en - Standard Ethernet driver
le - Lance Ethernet driver
ie - Intel Ethernet driver
tr - Token-Ring driver
et - Ether Twist driver
bf - fiber optic driver

All of the device names will have the unit number appended to the name. For example, a loop-back device in unit 0 will be "lo0".

BYNETIF_OUT_BYTE

The number of KBs sent to the network via this interface during the interval. Only the bytes in packets that carry data are included in this rate.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

This metric is available on HP-UX 11.0 and beyond.

BYNETIF_OUT_BYTE_RATE

The number of KBs per second sent to the network via this interface during the interval. Only the bytes in packets that carry data are included in this rate.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

This metric is available on HP-UX 11.0 and beyond.

BYNETIF_OUT_BYTE_RATE_CUM

The average number of KBs per second sent to the network via this interface over the cumulative collection time. Only the bytes in packets that carry data are included in this rate.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

This metric is available on HP-UX 11.0 and beyond.

BYNETIF_OUT_PACKET

The number of successful physical packets sent through the network interface during the interval. Successful packets are those that have been processed without errors or collisions.

For HP-UX 10.20 and other Unix systems, this is the same as the sum of the "Opkts" column (or TX on Linux) from the "netstat -i" command for a network device. See also netstat(1).

For HP-UX 11.0 and beyond, this metric will be the same as the sum of the "Outbound Unicast Packets" and "Outbound Non-Unicast Packets" values from the output of the "lanadmin" utility for the network interface. Remember that "lanadmin" reports cumulative counts. For this release and beyond, "netstat -i" shows network activity on the logical level (IP) only.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_OUT_PACKET_RATE

The number of successful physical packets per second sent through the network interface during the interval. Successful packets are those that have been processed without errors or collisions.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

BYNETIF_PACKET_RATE

The number of successful physical packets per second sent and received through the network interface during the interval. Successful packets are those that have been processed without errors or collisions.

On HP-UX 10.20, commands addressed to the local host always went down to the driver and the logical and physical counters were always updated.

This metric is updated at the sampling interval, regardless of the number of IP addresses on the system.

FS_BLOCK_SIZE

The maximum block size of this file system, in bytes.

On HP-UX, a value of "na" is displayed if the file system is not mounted.

On the other Unix systems, a value of "na" is displayed when the file system is no longer mounted. If the product is restarted, these unmounted file systems are not displayed until remounted.

FS_DEVNO

On Unix systems, this is the major and minor number of the file system.

On Windows, this is the unit number of the disk device on which the logical disk resides.

FS_DEVNAME

On Unix systems, this is the path name string of the current device.

On Windows, this is the disk drive string of the current device.

On HP-UX, this is the "fsname" parameter in the mount(1M) command. For NFS devices, this includes the name of the node exporting the file system. It is possible that a process may mount a device using the mount(2) system call. This call does not update the "/etc/mnttab" and its name is blank. This situation is rare, and should be corrected by syncer(1M). Note that once a device is mounted, its entry is displayed, even after the device is unmounted, until the midaemon process terminates.

On SUN, this is the path name string of the current device, or "tmpfs" for memory based file systems. See tmpfs(7).

FS_DIRNAME

On Unix systems, this is the path name of the mount point of the file system.

On Windows, this is the drive letter associated with the selected disk partition.

On HP-UX, if the logical volume has a mounted file system. This is the directory parameter of the mount(1M) command for most entries. Exceptions are:

For lvm swap areas, this field contains "lvm swap device".
For logical volumes with no mounted file systems, this field contains "Raw Logical Volume" (relevant only to MeasureWare Agent).

On HP-UX, the file names are in the same order as shown in the "/usr/sbin/mount -p" command. File systems are not displayed until they exhibit IO activity once the midaemon has been started. Also, once a device is displayed, it continues to be displayed (even after the device is unmounted) until the midaemon process terminates.

On SUN, only "UFS", "HSFS" and "TMPFS" file systems are listed. See mount(1M) and mnttab(4). "TMPFS" file systems are memory based filesystems and are listed here for convenience. See tmpfs(7).

On AIX, see mount(1M) and filesystems(4). On OSF1, see mount(2).

FS_FRAG_SIZE

The fundamental file system block size, in bytes.

On HP-UX, a value of "na" is displayed if the file system is not mounted.

On the other Unix systems, a value of "na" is displayed when the file system is no longer mounted. If the product is restarted, these unmounted file systems are not displayed until remounted.

FS_INODE_UTIL

Percentage of this file system's inodes in use during the interval.

On SUN, a value of "na" is displayed when the file system is no longer mounted. If the product is restarted, these unmounted file systems are not displayed until remounted.

On OpenVMS this is metric is calculated by dividing the disk used space by the disk cluster size and then dividing that number by the maximum disk size divided by the disk cluster size. Note that on OpenVMS inode concept does not apply. The value used is an OpenVMS specific metric.

FS_MAX_INODES

Number of configured file system inodes.

On SUN, a value of "na" is displayed when the file system is no longer mounted. If the product is restarted, these unmounted file systems are not displayed until remounted.

On OpenVMS, this metric is calculated by dividing the maximum disk size by the disk cluster size. This metric is used in the FS_MAX_INODES calculation above.

FS_MAX_SIZE

Maximum number that this file system could obtain if full, in MB.

On HP-UX, this metric is updated at 4 minute intervals to minimize collection overhead. Note that this is the user space capacity - it is the file system space accessible to non root users. The bdf command shows the total file system capacity which includes the extra file system space accessible to root users only.

For HP-UX 10.20 and beyond, a value of "na" may be displayed if the file system is not mounted.

On SUN, a value of "na" is displayed when the file system is no longer mounted. If the product is restarted, these unmounted file systems are not displayed until remounted.

On OpenVMS, this metric is based on the minimum file size, which is the disk cluster size.

FS_SPACE_RESERVED

The amount of file system space in MBs reserved for superuser allocation.

FS_SPACE_USED

The amount of file system space in MBs that is being used.

FS_SPACE_UTIL

Percentage of the file system space in use during the interval.

For HP-UX 10.20 and beyond, a value of "na" may be displayed if the file system is not mounted.

On SUN, a value of "na" is displayed when the file system is no longer mounted. If the product is restarted, these unmounted file systems are not displayed until remounted.

FS_TYPE

A string indicating the file system type. On Unix systems, some of the possible types are:

hfs - user file system
ufs - user file system
ext2 - user file system
cdfs - CD-ROM file system
vxfs - Veritas (vxfs) file system
nfs - network file system
nfs3 - network file system Version 3

On Windows, some of the possible types are:

NTFS - New Technology File System
FAT - 16-bit File Allocation Table
FAT32 - 32-bit File Allocation Table

FAT uses a 16-bit file allocation table entry (216 clusters).

FAT32 uses a 32-bit file allocation table entry. However, Windows 2000 reserves the first 4 bits of a FAT32 file allocation table entry, which means FAT32 has a theoretical maximum of 228 clusters. NTFS is native file system of Windows NT and Windows 2000.

GBL_ACTIVE_CPU

The number of CPUs online on the system.

For HP-UX and certain versions of Linux, the sar(1M) command allows you to check the status of the system CPUs.

For SUN and DEC, the commands psrinfo(1M) and psradm(1M) allow you to check or change the status of the system CPUs.

For AIX, the pstat(1) command allows you to check the status of the system CPUs.

GBL_ACTIVE_PROC

An active process is one that exists and consumes some CPU time. GBL_ACTIVE_PROC is the sum of the alive-process-time/intervaltime ratios of every process that is active (uses any CPU time) during an interval.

The following diagram of a four second interval during which two processes exist on the system should be used to understand the above definition. Note the difference between active processes, which consume CPU time, and alive processes which merely exist on the system.

     ----------- Seconds -----------

       1         2         3      4 

Proc

---- ----      ----      ----   ----

A    live      live      live   live

B    live/CPU  live/CPU  live   dead

Process A is alive for the entire four second interval but consumes no CPU. A's contribution to GBL_ALIVE_PROC is 4*1/4. A contributes 0*1/4 to GBL_ACTIVE_PROC. B's contribution to GBL_ALIVE_PROC is 3*1/4. B contributes 2*1/4 to GBL_ACTIVE_PROC. Thus, for this interval, GBL_ACTIVE_PROC equals 0.5 and GBL_ALIVE_PROC equals 1.75.

Because a process may be alive but not active, GBL_ACTIVE_PROC will always be less than or equal to GBL_ALIVE_PROC.

This metric is a good overall indicator of the workload of the system. An unusually large number of active processes could indicate a CPU bottleneck.

To determine if the CPU is a bottleneck, compare this metric with GBL_CPU_TOTAL_UTIL and GBL_RUN_QUEUE. If GBL_CPU_TOTAL_UTIL is near 100 percent and GBL_RUN_QUEUE is greater than one, there is a bottleneck.

GBL_ALIVE_PROC

An alive process is one that exists on the system. GBL_ALIVE_PROC is the sum of the alive-process-time/interval-time ratios for every process.

     ----------- Seconds -----------

       1         2         3      4 

Proc

---- ----      ----      ----   ----

A    live      live      live   live

B    live/CPU  live/CPU  live   dead

Because a process may be alive but not active, GBL_ACTIVE_PROC will always be less than or equal to GBL_ALIVE_PROC.

GBL_BOOT_TIME

The date and time when the system was last booted.

GBL_COLLECTOR

ASCII field containing collector name and version. The collector name will appear as either "SCOPE/xx V.UU.FF.LF" or "Coda RV.UU.FF.LF". xx identifies the platform; V = version, UU = update level, FF = fix level, and LF = lab fix id. For example, SCOPE/UX C.04.00.00; or Coda A.07.10.04.

GBL_CPU_CLOCK

The clock speed of the CPUs in MHz if all of the processors have the same clock speed. Otherwise, "na" is shown if the processors have different clock speeds.

GBL_CPU_IDLE_TIME

The time, in seconds, that the CPU was idle during the interval. This is the total idle time, including waiting for I/O.

On a system with multiple CPUs, this metric is normalized. That is, the CPU used over all processors is divided by the number of processors online.

GBL_CPU_IDLE_UTIL

The percentage of time that the CPU was idle during the interval. This is the total idle time, including waiting for I/O.

On Unix systems, this is the same as the sum of the "%idle" and "%wio" fields reported by the "sar -u" command.

On a system with multiple CPUs, this metric is normalized. That is, the CPU used over all processors is divided by the number of processors online.

GBL_CPU_NICE_TIME

The time, in seconds, that the CPU was in user mode at a nice priority during the interval.

On HP-UX, the NICE metrics include positive nice value CPU time only. Negative nice value CPU is broken out into NNICE (negative nice) metrics. Positive nice values range from 20 to 39. Negative nice values range from 0 to 19.

On Sun systems, this metric is only available on SunOS 4.1.X.

GBL_CPU_NICE_UTIL

The percentage of time that the CPU was in user mode at a nice priority during the interval.

On Sun systems, this metric is only available on SunOS 4.1.X.

GBL_CPU_SYS_MODE_TIME

The time, in seconds, that the CPU was in system mode during the interval.

GBL_CPU_SYS_MODE_UTIL

Percentage of time the CPU was in system mode during the interval.

This metric is a subset of the GBL_CPU_TOTAL_UTIL percentage.

This is NOT a measure of the amount of time used by system daemon processes, since most system daemons spend part of their time in user mode and part in system calls, like any other process.

High system mode CPU percentages are normal for IO intensive applications. Abnormally high system mode CPU percentages can indicate that a hardware problem is causing a high interrupt rate. It can also indicate programs that are not calling system calls efficiently.

GBL_CPU_TOTAL_TIME

The total time, in seconds, that the CPU was not idle in the interval.

This is calculated as

   GBL_CPU_TOTAL_TIME =
     GBL_CPU_USER_MODE_TIME + GBL_CPU_SYS_MODE_TIME

GBL_CPU_TOTAL_UTIL

Percentage of time the CPU was not idle during the interval.

This is calculated as

   GBL_CPU_TOTAL_UTIL =
     GBL_CPU_USER_MODE_UTIL + GBL_CPU_SYS_MODE_UTIL

   GBL_CPU_TOTAL_UTIL + GBL_CPU_IDLE_UTIL = 100%

This metric varies widely on most systems, depending on the workload. A consistently high CPU utilization can indicate a CPU bottleneck, especially when other indicators such as GBL_RUN_QUEUE and GBL_ACTIVE_PROC are also high. High CPU utilization can also occur on systems that are bottlenecked on memory, because the CPU spends more time paging and swapping.

NOTE: On Windows, this metric may not equal the sum of the APP_CPU_TOTAL_UTIL metrics. Microsoft states that "this is expected behavior" because this GBL_CPU_TOTAL_UTIL metric is taken from the performance library Processor objects while the APP_CPU_TOTAL_UTIL metrics are taken from the Process objects. Microsoft states that there can be CPU time accounted for in the Processor system objects that may not be seen in the Process objects.

GBL_CPU_USER_MODE_TIME

The time, in seconds, that the CPU was in user mode during the interval.

User CPU is the time spent in user mode at a normal priority, at real-time priority (on HP-UX, AIX, and Windows systems), and at a nice priority.

GBL_CPU_USER_MODE_UTIL

The percentage of time the CPU was in user mode during the interval.

User CPU is the time spent in user mode at a normal priority, at real-time priority (on HP-UX, AIX, and Windows systems), and at a nice priority.

This metric is a subset of the GBL_CPU_TOTAL_UTIL percentage.

High user mode CPU percentages are normal for computationintensive applications. Low values of user CPU utilization compared to relatively high values for GBL_CPU_SYS_MODE_UTIL can indicate an application or hardware problem.

GBL_DISK_PHYS_BYTE

The number of KBs transferred to and from disks during the interval. The bytes for all types of physical IOs are counted. Only local disks are counted in this measurement. NFS devices are excluded.

It is not directly related to the number of IOs, since IO requests can be of differing lengths.

On Unix systems, this includes file system IO, virtual memory IO, and raw IO.

On Windows, all types of physical IOs are counted.

On SUN, if a CD drive is powered off, or no CD is inserted in the CD drive at boottime, the operating system does not provide performance data for that device. This can be determined by checking the "by-disk" data when provided in a product. If the CD drive has an entry in the list of active disks on a system, then data for that device is being collected.

GBL_DISK_PHYS_BYTE_RATE

The average number of KBs per second at which data was transferred to and from disks during the interval. The bytes for all types physical IOs are counted. Only local disks are counted in this measurement. NFS devices are excluded.

This is a measure of the physical data transfer rate. It is not directly related to the number of IOs, since IO requests can be of differing lengths.

This is an indicator of how much data is being transferred to and from disk devices. Large spikes in this metric can indicate a disk bottleneck.

On Unix systems, this includes file system IO, virtual memory IO, and raw IO.

GBL_DISK_PHYS_IO

The number of physical IOs during the interval. Only local disks are counted in this measurement. NFS devices are excluded.

On Unix systems, this includes all types of physical reads and writes to and from disk, including file system IO, virtual memory IO and raw IO.

On HP-UX, this is calculated as

   GBL_DISK_PHYS_IO =
     GBL_DISK_FS_IO + GBL_DISK_VM_IO +
     GBL_DISK_SYSTEM_IO + GBL_DISK_RAW_IO

GBL_DISK_PHYS_IO_RATE

The number of physical IOs per second during the interval. Only local disks are counted in this measurement. NFS devices are excluded.

On Unix systems, this includes all types of physical reads and writes to and from disk, including file system IO, virtual memory IO and raw IO.

On HP-UX, this is calculated as

   GBL_DISK_PHYS_IO_RATE =
     GBL_DISK_FS_IO_RATE + GBL_DISK_VM_IO_RATE +
     GBL_DISK_SYSTEM_IO_RATE + GBL_DISK_RAW_IO_RATE

GBL_DISK_PHYS_READ

The number of physical reads during the interval. Only local disks are counted in this measurement. NFS devices are excluded.

On Unix systems, all types of disk reads are counted, including file system, virtual memory, and raw reads.

On HP-UX, there are many reasons why there is not a direct correlation between the number of logical IOs and physical IOs. For example, small sequential logical reads may be satisfied from the buffer cache, resulting in fewer physical IOs than logical IOs. Conversely, large logical IOs or small random IOs may result in more physical than logical IOs. Logical volume mappings, logical disk mirroring, and disk striping also tend to remove any correlation.

On HP-UX, this is calculated as

   GBL_DISK_PHYS_READ =
     GBL_DISK_FS_READ + GBL_DISK_VM_READ +
     GBL_DISK_SYSTEM_READ + GBL_DISK_RAW_READ

HP OpenVMS Systems