Release 8.0
A54638-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8(TM) Server Tuning Release 8.0 A54638-01 |
|
This chapter provides an overview of performance factors in existing systems which have been properly designed. Note, however, that tuning these factors cannot compensate for poor design!
Later chapters discuss each of these factors in depth.
The following figure illustrates the many factors involved in Oracle system performance, when considering a well-designed existing application.
Attention: Tuning these factors is effective only after you have tuned the business process and the application, as described in "Performance Tuning Method". Tuning these factors cannot make up for the performance gains that must be designed in!
Performance problems tend to be interconnected rather than isolated. The following table provides a key to performance factors in an existing system, and the areas in which symptoms may appear. Buffer cache problems, for example, may show up as issues of CPU, memory, or I/O. Tuning the buffer cache for CPU may in turn improve I/O.
In a CPU-bound system, the CPU resource is completely used up, service time is too high and you want to achieve more. Alternatively, you have too much idle time, want to achieve more, and the CPU is not completely used up. There is room to do more: you need to determine why so much time is spent waiting.
To diagnose insufficient CPU, you must check CPU utilization by your entire system, not only utilization by Oracle Server processes. At the beginning of a workday, for example, the mail system may consume a very high amount of the available CPU, while employees check their messages. Later in the day, the mail system may be much less heavily used, and its CPU utilization will drop accordingly.
Workload is a very important factor when evaluating your system's level of CPU utilization. During peak workload hours, 90% CPU utilization with 10% idle and waiting time may be understandable and acceptable. Thirty percent utilization at a time of low workload may also be understandable. However, if your system shows high utilization at normal workload, there is not room for peak workload. You have a CPU problem if idle time and time waiting for I/O are both close to zero (less than 5%) at a normal or low workload.
See Also: Chapter 13, "Tuning CPU"
Sometimes memory problems may be detected as an I/O problem. There are two kinds of memory requirements: Oracle and system. Oracle memory requirements impact the system requirements. Memory problems may be the cause of all the paging and swapping that goes on in the machine. Make sure that your system does not start swapping and paging. The whole system should be able to run within the limitations set by internal memory.
The system memory requirements for non-Oracle processes and the Oracle memory requirements should be equal to or less than internal memory. To achieve this, you can trim some elements of the Oracle requirements, most likely buffer cache, shared pool, or redo log buffer. On the system level you can trim the number of processes and/or the amount of memory each process uses. You can also identify which processes are using the most memory. One way to reduce memory usage might be by sharing SQL.
See Also: Chapter 14, "Tuning Memory Allocation"
Be sure to evenly distribute I/O across disks and channels.
I/O problems may result from limitations of your hardware configuration. Your system needs enough disks and SCSI busses to support the transaction throughput you desire. You can evaluate the configuration by figuring the number of messages all your disks and busses can potentially support, and comparing that to the number of messages required by your peak workload.
If the response time of an I/O becomes too high, the most common problem is that wait time has gone up (response time = service time + wait time). If wait time goes up, it means that there are too many I/O requests for this device. If service time goes up, this normally goes hand in hand with a larger I/O, so you write more bytes.
The different background processes (DBWR, ARCH, and so on) perform different kinds of I/O, and each process have different I/O characteristics. Some read and write in the block size of the database, some read and write in larger chunks. If service time is too high, stripe the file over different devices.
Mirroring can also be a cause of I/O bottlenecks unless the data is mirrored on the same number of disks as the database itself.
See Also: Chapter 15, "Tuning I/O"
Network constraints are similar to I/O constraints. You need to consider:
As the number of users and the demand rises, the network can sometimes quietly become the bottleneck in an application. You may be spending a lot of time waiting for network availability. Use available operating system tools to see how busy your network is.
See Also: Chapter 16, "Tuning Networks"
Operating system software determines:
Before you can effectively tune Oracle, you must ensure that the operating system is at its peak performance. Work closely with the hardware/software system administrators to ensure that Oracle is allocated the proper operating system resources.
Note: On NT systems there are no pre-set or configurable maximum numbers of processes that can be supported or connected.
See Also: Operating system tuning is different for every platform. Refer to your operating-system hardware/software documentation as well as your Oracle operating system-specific documentation for more information.
In addition, see Chapter 17, "Tuning the Operating System"
