Introduction to Oracle performance and adjustment in Solaris

It is hard to know why a system is slow in running and performance degrades. Is it a memory leak, a bottleneck on the disk subsystem, or is there a limit on the scalability of a specific application? There are some ways to discover and understand the root cause of performance problems, and it is possible to eliminate it. This article provides some suggestions on where to start. This article introduces how to consider performance and how to locate common performance bottlenecks. It also introduces some concepts closely related to performance, such as private Shared Memory ISM-Intimate Shared Memory) and priority Memory Page scheduling. This article focuses on the Solaris 2.6 operating environment.

Start with performance problems

Performance may require more comprehensive consideration than other aspects of computer system behavior. To identify the root cause of a problem from one or more components, a structured approach is required.

The actual result is that the most important part in solving performance problems is to define the problems you are trying to solve. In terms of actual application, this means to define an operation or test case, so that you can:

A) know how fast the system is.

B) know that the system needs to be faster than "X" or that the system has been faster than "X" in different environments.

Setting a baseline is the first step. Performance analysis is a top-down process that begins with a simple and clear definition of the issues to be resolved. If you want a system to run faster, you still need to define which attributes of the system you want to improve and what costs are acceptable or unacceptable. Unless you can clearly describe the symptoms/opportunities of a problem, it is only luck to identify the root cause of the problem.

Performance analysis is like a detective work. We establish a factual basis through evidence and observation, be very careful not to fall into the pre-imagined conclusions that do not match the facts-the conjecture is confirmed only when there is overwhelming evidence.

Doubt all assumptions. The fact claimed by others is actually just a hypothesis that may be true or incorrect. If this assumption is incorrect, you may work on an incorrect basis to draw an incorrect conclusion.

Here are some warnings. In most cases, the Solaris operating environment provides excellent performance optimization for workloads. The newer the release version, the less manual performance optimization is required. The root cause of performance problems is often found because of an attempt to optimize performance. First, pay attention to the application, and finally the operating environment.

Any changes to system configurations, such as performance settings such as memory size and disk layout, should check their current correctness. Similarly, a system upgrade with parameters may affect the performance of the new operating environment.

Performance monitoring

1. Starting from the exposed problems

What operations enable you to see performance problems?

For example, is file or network operations slower than expected for a specific type of database query? How detailed are the operation steps for giving test cases, such as an SQL query or a 30-line C program?

Use your knowledge to the greatest extent possible to describe "where is the problem?" To define your problem. An example of a good problem is as follows:

An SQL query takes twice as long as UFS IN A VXFS statement.

SVR4 Message Queue operations in operating environment version A are 30 percent longer than in operating environment Version B.

It takes three times more time to log on to system A than to log on to system Y.

A Problem description should not include a solution or a possible solution.

In most cases, a clear explanation of the problem means that more than half of the problem solving process has been completed. When explaining the issues you are trying to solve, it is also important to take into account the user's point of view, which means that from the application perspective. This is contrary to people's nature. People always try to prove or falsify a possible cause through experiments, rather than evaluating the possibility of a cause based on observed facts.

The problem is described as follows:

The "wt" List of mpstat has too much waiting time.

User Tasks take too long.

The boundary between functional correctness and performance problems of a system and its applications is often a gray area. The issue of system suspension and process suspension is not covered in this article. If you suspect that the system functions are incorrect, instead of performance problems, call your SUN Solution Center to find a solution to the problem. The premise of a high-performance system is that its functions must be correct first.

As part of your active maintenance plan, it is also very valuable to check/var/adm/messages for hardware problems such as disk retries or for the generation of additional messages.

It is also very valuable to view the historical information of the system. If your system has had better performance, draw a time curve to record in detail when the first time you find performance deteriorated and when the performance has been poor.

2. Know what will happen to your system under normal circumstances

It is a good idea to save an example of how your system works properly. You can easily collect and save monthly performance data, such:

* Stat class: vmstat, mpstat, iostat, vxstat, and sar

Ps output to show which processes are running (in the Solaris 8 operating environment is prstat ). In addition, many commercial and unsupported products can be used for performance monitoring. SE Toolkit is a free and unsupported product. For more information about different versions of SE Toolkit, see Sun Performance SE Toolkit page ). SE Toolkit reports disk activity, CPU utilization, TCP and network connections, memory, and more information. In our experience, it is easy to install, does not need to restart the system, and generates easy-to-understand graphical display.

Many such products share a common problem, that is, they have different thresholds for different hardware configurations. For example, a specific threshold value may appear too slow for a-MHz system, but it may be acceptable for a-MHz system.

3. Find performance bottlenecks

Once you have defined the performance issues to be solved, the next step is to narrow down the scope to the bottleneck.

At this stage, it is necessary to ask the following questions:

What bottlenecks does the application tell me? Taking Oracle as an example, an Oracle database administrator should know what BSTAT/ESTATS are and how to run and understand them. In other words, from the application perspective, BSTATS/ESTATS can display bottlenecks that limit Oralce performance, which can be used as a guide for further analysis.

Where is most of the time spent? Is it a kernel or a user process? You can answer this question through vmstat, mpstat, sar, ps, and prstat.

Are all resources of similar types equally busy? The significance of this problem is to find the unequal distribution of resources. For example, a disk may be the bottleneck, or a CPU may be busier than other CPUs. For the CPU, see mpstat. Use iostat for disks. Which or which processes use the most resources? Use these commands to view the processes that use the most CPU and memory:

ps -eo pid,pcpu,args | sort +1n

CPU percentage:

ps -eo pid,vsz,args | sort +1n

/usr/ucb/ps aux |more

The output is sorted. The processes that use the most CPU and memory are listed above.

The Solaris 8 operating environment provides prstat, which provides a dynamic annotation of CPU and memory usage. The output result of prstat-cvm is very useful.

Now let's take a look at how to use common Solaris commands to start performance analysis.

The vmstat command is simple. Here we can see an example of insufficient CPU capacity for running applications.

% vmstat 15　procs memory page disk faults cpu　r b w swap free re mf pi po fr de sr m0 m1 m2 m3 in sy cs us sy id　45 0 0 2887216 182104 3 707 449 6 455 0 80 2 6 1 0 1531 5797 983 61 30 9　58 0 0 2831312 46408 5 983 582 56 3211 0 492 0 0 0 0 1413 4797 1027 69 31 0　55 0 0 2830944 56064 2 649 656 3 806 0 121 0 0 0 0 1441 4627 989 69 31 0　57 0 0 2827704 48760 4 818 723 6 800 0 121 0 0 1 0 1606 4316 1160 66 34 0　56 0 0 2824712 47512 6 857 604 56 1736 0 261 0 0 1 0 1584 4939 1086 68 32 0　58 0 0 2813400 47056 7 856 673 33 2374 0 355 0 0 0 0 1676 5112 1114 70 30 0　60 1 0 2816712 49464 7 861 720 6 731 0 110 7 0 3 0 2329 6131 1067 64 36 0　58 0 0 2817552 48392 4 585 521 0 996 0 146 0 0 0 0 1357 6724 1059 71 29 0

The first line output by vmstat can always be ignored. Under "procs", a column marked "r" is the number of processes in the process running queue waiting to obtain the CPU. The "id" column indicates the CPU idle time. This machine does not have enough CPU resources to meet the process running needs, which can be seen from the majority of its CPU time spent in the user space (see the "us" column ).

There are two ways to use it: first, add more CPUs, or second, perform performance analysis on the application code to see if some part of the application can be optimized. Optimization of code snippets may require a lot of effort-and sometimes little effect. When it comes to time, it is best to consider your possible "Return on Investment.

(