OSW Profile 1.0

Introduction

This report was generated by the oswbba utility which is a companion utility to OSWatcher. This utility uses vmstat and iostat data collected by OSWatcher and produces graphs of some of the most important operating system metrics. Displaying this information graphically gives the user the ability to correlate the data and look for trends which may be missed by looking at various OS utilities manually. Additionally, oswbba can analyze this data for you and automatically look for problems on your system. You should analyze your data and use this html graphing profile as a companion for the analysis report.

This report is divided into sections. Each section may contain one or more related graphs. At the end of each section there is a narrative advising the user on what to look for. Some of the graphs may be missing because your particular version of UNIX/Linux many not collect this metric

For more information on how to interpret this data consult the OSWatcher User Guide (MOS note #301137.1). As differences exist across UNIX platforms for these utilities it is always best to refer to your specific platform's man pages.

Back

I. Operating System CPU Queues

The following graphs show operating system run queue, processes blocked for resources queue and processes swapped queue. Not all Operating Systems report processes being swapped so the last graph in this section may be missing.

What to look for

These queue statistics are based on vmstat and are aggregated for multiple CPU systems. The numbers being reported for these queues should be divided by the number of physical CPU’s listed in the properties section. A common mistake is to consider virtual cpu's or threads as real cpu's which they are not.
Large run queue. When the number in the run queue is divided by the number of physical cpu's, then this number should not exceed 3-4 processes for any length of time. If it does, you have either processes consuming lots of cpu which can be verified by looking at the output of oswtop listed in your OSWatcher archive, or your system lacks sufficient capacity for your workload.
Disk problems may be identified if the number of processes blocked exceeds the number of processes on the run queue. This can also be a result of Oracle dumping lots of trace files because of error conditions on the database.
Not all UNIX systems report statistics for the swap queues. A non-zero number in this field indicates that certain threads have been swapped out to the (swap) disk as there was a shortage of physical memory. Even when the system frees the memory, those processes continue to swap out till you make them do something (like just truss the process)

Back

II. Operating System CPU Utilization

The following graphs show CPU utilization. On multiple cpu systems these statistics are aggregated across all processors.

What to look for

CPU utilization. The amount of time spent running system code should not exceed 30%, for any length of time, especially if idle time is close to 0%.
A combination of large run queue with no idle CPU is an indication that the system has insufficient CPU capacity.
The CPU Utilization: Wait I/O graph, if it exists on you version of UNIX/Linux, can be a strong indication that there is severe I/O blocking occuring outside the database if a significant amount of time is being spent waiting on I/O.

Back

III. Operating System CPU Other

The following graphs show processor statistics for context switches and device interrupts. This information is useful if you suspect you have a CPU problem.

What to look for

Unusually high values for device interrupts can be further investigated with iostat. I/O issues affecting the database should be reflected in I/O related wait events in section IV above. Operating System I/O is detailed in Section X below.
Any significant increase in context switches, such as when context switches are a lot higher than the disk I/O and network packet rate, should be cause for further investigation.

Back

IV. Operating System Memory

The following graphs show operating system memory statistics.

What to look for

Decreasing values for free memory and swap over time can indicate memory leaks. You can look for memory leaks by running oswbba with the -mem_all option.
The swap memory should never approach zero.
Memory bottlenecks are determined by the scan rate (sr) . The scan rate is the pages scanned by the clock algorithm per second. If the scan rate (sr) is continuously over 200 pages per second then there is a memory shortage. Unfortunately, not all UNIX systems report scan rate. Unfortunately Linux does not report scan rate
On Linux, it is important to look at the page in graph. A large value that is continuous can indicate a serious memory issue.

Back

V. Operating System I/O

The following graphs show I/O statistics for the top 3 devices in terms of service time, percent busy, reads per second and writes per second. Only the top 3 devices are graphed.

What to look for

Average service times greater than 10msec for long duration.
Percent busy should not approach 100% for any length of time. Response times start to become significantly longer once device utilization climbs over 50%
Some UNIX systems report queue time included in service time, others do not. Check your systems man pages under iostat for verification.

V. Operating System I/O Throughput

The following graphs show I/O throughput for the top 3 devices in terms of total throughput and also the top 3 busiest devices graphed verses throughput.

What to look for

If you have a storage array, then the only reliable metric from iostat is throughput. This is because writes are reported as complete before they are written to disk because of all the caching associated with storage arrays. In this case, focus on the throughput as a function of device utilization. If your device is 100 percent busy and only pulling 500Kbytes/sec and it is rated for 12Mbytes/sec you can tell some problem exists within I/O subsystem.

Back

I/O Device Summary

Profile ID#:
Input Archive:
Hostname:
OS Version:
Snapshot Frequency:
OS CPU Count:


		Profile ID#:
Copyright © 2014, Oracle Corporation. All Rights Reserved