Contents
Abstract
This manual discusses how to find the reasons for performance problems and provides means to solve these problems. Before you start tuning your system, you should make sure you have ruled out common problems and have found the cause (bottleneck) for the problem. You should also have a detailed plan on how to tune the system, because applying random tuning tips will not help (and could make things worse).
Procedure 1.1. General Approach When Tuning a System
Be sure what problem to solve
Rule out common problems
Find the bottleneck
Monitor the system and/or application
Analyze the data
Step-by-step tuning
Before you start tuning your system, try to describe the problem as exactly as possible. Obviously, a simple and general “The system is too slow!” is no helpful problem description. If you plan to tune your Web server for faster delivery of static pages, for example, it makes a difference whether you need to generally improve the speed or whether it only needs to be improved at peak times.
Furthermore, make sure you can apply a measurement to your problem, otherwise you will not be able to control if the tuning was a success or not. You should always be able to compare “before” and “after”.
A performance problem often is caused by network or hardware problems, bugs, or configuration issues. Make sure to rule out problems such as the ones listed below before attempting to tune your system:
Check /var/log/warn and
/var/log/messages for unusual entries.
Check (using top or ps) whether a certain process misbehaves by eating up unusual amounts of CPU time or memory.
Check for network problems by inspecting
/proc/net/dev.
In case of I/O problems with physical disks, make sure it is not caused
by hardware problems (check the disk with the
smartmontools) or by a full disk.
Ensure that background jobs are scheduled to be carried out in times the server load is low. Those jobs should also run with low priority (set via nice).
If the machine runs several services using the same resources, consider moving services to another server.
Last, make sure your software is up-to-date.
Finding the bottleneck very often is the hardest part when tuning a system. openSUSE offers a lot of tools helping you with this task. See Part II, “System Monitoring” for detailed information on general system monitoring applications and log file analysis. If the problem requires a long-time in-depth analysis, the Linux kernel offers means to perform such analysis. See Part III, “Kernel Monitoring” for coverage.
Once you have collected the data, it needs to be analyzed. First, inspect if the server's hardware (memory, CPU, bus) and its I/O capacities (disk, network) are sufficient. If these basic conditions are met, the system might benefit from tuning.
Make sure to carefully plan the tuning itself. It is of vital importance to only do one step at a time. Only by doing so you will be able to measure if the change provided an improvement or even had a negative impact. Each tuning activity should be measured over a sufficient time period in order to ensure you can do an analysis based on significant data. If you cannot measure a positive effect, do not make the change permanent. Chances are, that it might have a negative effect in the future.