Introduction to Oracle Performance and tuning under Solaris

It's hard to know what the reason is when a system slows down in performance. Is it a memory leak, a disk subsystem bottleneck, or a specific application that has limited scalability? There are ways to discover and understand the root cause of performance problems, and it is possible to eliminate it.

This paper gives some suggestions on where to start. This paper describes how to proceed with performance considerations and how to locate common performance bottlenecks, and also introduces some concepts related to performance, such as Private shared memory (Ism-intimatesharedmemory) and Priority memory page scheduling. The article focuses on the Solaris2.6 operating environment.

Start performance issues

Performance, perhaps more than the other aspects of computer system behavior need to have a comprehensive consideration. To identify the root cause of the problem from one or more components, you must take a structured approach.

The real result is that the most important part of solving a performance problem is defining the problem that you are trying to solve. In practical terms, this means defining an action or test case to:

A) Know how fast the system is currently.

B know that the system needs to be fast "x" times, or that the system has been faster than "X" times in different environments.

Setting a baseline is the first step in the beginning. Performance analysis is a top-down process that begins with a simple and clear definition of the problem that needs to be addressed. 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 you can accept or not accept. Unless you can clearly describe the symptoms/opportunities, it would be a chance to identify the root cause of the problem.

Performance analysis is like detective work, and we build facts by evidence and observation, very careful not to fall into a predetermined and factual conclusion--only to confirm conjecture when there is very overwhelming evidence.

Be suspicious of all assumptions. The fact that other people claim is actually just a hypothesis that may or may not be correct. If this assumption is wrong, you may be working on an incorrect basis to draw incorrect conclusions.

Here are some caveats. The Solaris operating environment is good for the performance optimization of workloads in most cases. The newer the release, the less performance optimizations that need to be done manually. The root cause of performance problems is often found to be caused by an attempt to optimize performance. First you need to pay attention to the application, and finally the operating environment.

Any changes to the system configuration, such as performance settings such as memory size and disk layout, should be checked for current correctness. Similarly, a system upgrade with parameters may have an impact on the performance of the new operating environment.

Performance monitoring

1. Start with exposed problems

What do you see as symptoms of performance problems?

For example, is a particular type of database query, file or network operations slower than you expect? In the case of test cases, how can you make the steps more specific, such as an SQL query or a 30-line C program?

Use your knowledge to the fullest extent possible to illustrate "What's wrong" to define your problem. Examples of good problem descriptions are like this:

An SQL query takes twice times more time on vxfs than on UFS.

The SVR4 Message Queuing operation takes 30 more time on the operating environment version a than on the operating environment version B.

Login to System A is three times times more time than logging into system Y.

A problem description should not include a workaround or a possible workaround.