Skip to Main Content
Return to Navigation

Monitoring Resource Usage

This section provides additional information that may help you to interpret the information that Performance Monitor provides that is related to the events reporting resource usage on host machines. These events are:

These events report the usage of machine resources (CPU, memory, network, and so on). These events, except for Event 150 (JVM Status), make calls to external APIs (often specific to the operating system) to retrieve metric information. The monitored system sends each event at the sampling interval that is specified for that system.

Working with Event 150 (JVM Status)

This event applies only to web servers.

This event does not make calls to any operating system-specific API.

Working with Event 151 (Network Status)

This event applies only to web servers.

For Event 151 (Network Status) the system launches a separate executable from Java that invokes the "netstat –n" command. On UNIX, the command runs in a separate shell. When the command finishes, the process ends. PeopleSoft does not run "netstat" with an interval argument.

Warning! On some platforms the "netstat" command can require up to a minute (or more) to finish. If the sampling interval is shorter than the time required for the command to complete, "netstat" commands will be running continuously.

Working with Event 200 (Resources Per Process)

This event applies to the application server and the Process Scheduler server.

The PeopleSoft system makes specific operating system calls to obtain metrics for %CPU that are used by the process, CPU time consumed, virtual memory size, and working set size. Operating systems have slightly different definitions for these quantities and different ways of reporting them. For instance, "working set" memory is a Windows term; "resident set" is the UNIX equivalent. PeopleSoft strives for consistency across platforms. For example, PeopleSoft expresses %CPU within a range from 0 to 100 on all machines even though some vendors scale to N*100% if multiple CPUs (N CPUs) exist.

Microsoft Windows and Linux compute one or more resources as an average of the two measurements at the beginning and end of a sampling interval. On these platforms, the Performance Monitor does not report an Event 200 (Resources Per Process) until the second sampling interval after you boot a server.

Process resource utilization is usually sampled by the operating system and written to a memory location. Windows writes to the registry, while UNIX writes to various files. The system reads the current values for the process, so events change only when the operating system updates the statistics. Most operating systems update these statistics at least once per second.

PeopleSoft obtains all information using lightweight, C++ programmatic APIs. No additional processes or shell commands are run.

Operating System

Description

Windows

Performance Monitor uses Performance Data Helper (PDH) to read registry counters. The information is identical to the Windows Performance Monitor tool. When multiple copies of a process, such as PSAPPSRV, are running, registry counters are assigned arbitrarily. For example, counter 1 and counter 2 can reverse their process assignment when a process reboots. Performance Monitor corrects for this.

  • CPU utilization is "% Processor Time," defined as the fraction of time that the process spends in kernel + user during the last PDH sampling interval (typically one second).

  • Process time is kernel + user, accurate to 1 millisecond.

  • Virtual memory is "Virtual Bytes."

  • Working set memory is "Working Set," which is the same as "Mem Usage," displayed by the Windows Task Manager.

AIX

Performance Monitor reads the psinfo files, which is the same source of information that AIX uses for its "ps" command.

  • CPU utilization is the same as "ps -o pcpu" or the %CPU from "ps v". AIX defines it as a lifetime average: total CPU time that is consumed by the process divided by total time that the process has been running.

  • Process time is system + user, excluding children. Accurate to 10 milliseconds.

  • Virtual memory is the same as "ps -o vsz", or the 1024 * SIZE field from "ps v".

  • Resident set memory is the same as the 1024 * RSS field from "ps v".

HPUX

Performance Monitor reads pst_status using pstat_getproc.

  • CPU utilization is the same as "top" divided by the number of CPUs (on HPUX "top" shows utilization of a single CPU).

  • Process time is system + user, excluding children.

  • Virtual memory is the same as the SIZE field from "top".

  • Resident set memory is the same as the RES field from "top".

Linux

Performance Monitor reads ps information from /proc files.

  • CPU utilization is the same as "top" divided by the number of CPUs (on Linux "top" shows utilization of a single CPU). It is the average utilization over the last sample period.

  • Process time is system + user, excluding children, and accurate to 10 milliseconds. The times for all threads in the process are added together.

    Warning! Linux kernel 2.4 tracks only the process time of each thread. PeopleSoft searches the /proc directory to find all threads and report the total time of the process. However, on a production system with thousands of threads, accumulating this information may take up to a second of CPU time.

  • Virtual memory is the same as "ps -o vsz" (not visible in "top"). According to the man pages, it counts just text, data, and stack.

  • Resident set memory is the same as "ps -o rss" (not visible in "top"). This value includes just text, data, and stack.

Solaris

Performance Monitor reads psinfo files, which is the same source of information that Solaris uses for its "ps" command.

  • CPU utilization is the same as "top". Solaris computes a moving average with exponential weighting.

  • Process time is system + user, excluding children, and accurate to 10 milliseconds.

  • Virtual memory is the same as "ps -o vsz" or the SIZE field from "top".

  • Resident set memory is the same as "ps -o rss" or the RES field from "top". On Solaris, shared libraries are counted in RES but not in SIZE.

OS/390

The only metric that is supported in the current release is Process Time.

Working with Event 300 (Host Resource Status)

This event applies to the application server and the Process Scheduler server.

Performance Monitor makes specific operating system calls to obtain metrics for %CPU use on the host machine, %Memory use, and the hard page fault rate. Operating systems have slightly different definitions for these quantities, and they have different ways of reporting them. In most cases, PeopleSoft expresses %Memory use to reflect utilization of physical memory.

Performance Monitor programmatically queries the Tuxedo management information base (MIB) for total Jolt connections and total requests queued. All platforms compute one or more resources as an average of the two measurements at the beginning and end of a sampling interval. Performance Monitor does not report an Event 300 (Host Resource Status) until the second sampling interval after you boot the server.

Process resource utilization is usually sampled by the operating system and written to a memory location. Windows writes to the registry, while UNIX writes to various files. The system reads the current values for the process, so events change only when the operating system updates the statistics. Most operating systems update these statistics at least once per second.

PeopleSoft obtains all information using lightweight, C++ programmatic APIs. No additional processes or shell commands are run.

Operating System

Description

Windows

Performance Monitor uses Performance Data Helper (PDH) to read registry counters. The information is identical to the Windows Performance Monitor tool.

  • CPU utilization is "% Processor Time (_Total)", defined as the fraction of time not run by the system idle thread in the last PDH sampling interval (typically one second).

  • Memory utilization is "% Committed Bytes In Use" and will change if the paging file is extended by the system administrator.

  • Page faults is "Pages / sec", which reports actual disk page fetches ("Page Faults /sec" reports soft faults).

AIX

Performance Monitor uses libperfstat API (a wrapper for knlist) to read kernel counters.

  • CPU utilization is the same as "topas" and "vmstat". This is an average over the last sample period, but process CPU use is an average over process lifetime. Therefore, on AIX, it is possible for machine CPU use to be momentarily smaller than CPU use of a process that was previously CPU-intensive.

  • Memory utilization is defined as "free real pages" / "total real memory pages". The "vmstat" command shows the number of free pages, but not the available total. The "topas" field, Real MEMORY, shows "real memory pages." The PAGING SPACE field shows only reserved pages, not free pages.

  • Page faults is the same as "topas" and "vmstat", with the absolute difference averaged over the last sampling time. According to Linux information, this value includes pages faults that do not cause paging activity.

HPUX

Performance Monitor uses pstat_getdyamic (pstat) to read kernel counters.

  • CPU utilization is the same as "top" and "vmstat". This is an average over the last sample period, but process CPU use is an average over a longer time period. Therefore, it is possible on HPUX for machine CPU use to be momentarily smaller than CPU use of a process that was previously CPU-intensive.

  • Memory utilization is defined as "real memory + text pages / physical memory." Neither of these quantities are exposed with vmstat.

  • Page faults is the same as "vmstat -s, zero fill page faults", with the absolute difference averaged to a rate over the last sampling time.

Linux

Performance Monitor reads kernel statistics from files in /proc.

  • CPU utilization is the same as "top", averaged over all processors. This is an average over the last sample period.

  • Memory utilization is the same as "top", or the "free" command "Mem used / (av)ailable" field. It measures physical memory utilization. The "used" field is actually "available - free". The "M" and "K" units of "top" are 1024 * 1024 bytes and 1024 bytes, respectively.

  • Page faults is the first "page" kernel counter from /proc/stat (pages swapped in from disk), with the absolute difference averaged to a rate over the last sampling time.

Solaris

Performance Monitor uses the Kernel Statistics API (kstat) to read kernel counters.

  • CPU utilization is the same as "top, user + kernel". This is an average over the last sample period, but process CPU use is a weighted average over a longer time period. Therefore, it is possible on Solaris for machine CPU use to be momentarily smaller than CPU use of a process that was previously CPU-intensive.

  • Memory utilization is defined as the "used / used + available" fields from "swap -s". This is only an approximation because of allocated but unreserved RAM. See the Sun web site for more information.

  • Page faults is the same as major page faults from "vmstat -s", with the absolute difference averaged to a rate over the last sampling time.

OS/390

Performance Monitor uses the ERBSMFI and CVT APIs to report resource use on the logical partition. Higher priority jobs on other partitions can "steal" resources and not appear in these metrics.

  • CPU utilization is the same as RMF "TOTAL/AVERAGE LPAR BUSY TIME PERC" field.

  • Memory utilization is defined from the RMF "AVAILABLE" versus RMF "TOTAL FRAMES" fields.

  • Page faults is not supported for this release.

Working with Event 301 (Tuxedo "pq Rows)

This event applies to the application server and the Process Scheduler server.

The system programmatically queries the Tuxedo management information base (MIB) for the status of each queue.

Working with Event 302 (Tuxedo "psr" Rows)

This event applies to the application server and the Process Scheduler server.

The system programmatically queries the Tuxedo management information base (MIB) for the status of each server. Only PeopleSoft servers appear as Performance Monitor events; the BBL is not reported.