openSUSE Leap Documentation › System Analysis and Tuning Guide › Basics › General Notes on System Tuning
ContentsContents
System Analysis and Tuning Guide
  1. About This Guide
  2. I Basics
    1. 1 General Notes on System Tuning
  3. II System Monitoring
    1. 2 System Monitoring Utilities
    2. 3 Analyzing and Managing System Log Files
  4. III Kernel Monitoring
    1. 4 SystemTap—Filtering and Analyzing System Data
    2. 5 Kernel Probes
    3. 6 Hardware-Based Performance Monitoring with Perf
    4. 7 OProfile—System-Wide Profiler
  5. IV Resource Management
    1. 8 General System Resource Management
    2. 9 Kernel Control Groups
    3. 10 Automatic Non-Uniform Memory Access (NUMA) Balancing
    4. 11 Power Management
  6. V Kernel Tuning
    1. 12 Tuning I/O Performance
    2. 13 Tuning the Task Scheduler
    3. 14 Tuning the Memory Management Subsystem
    4. 15 Tuning the Network
  7. VI Handling System Dumps
    1. 16 Tracing Tools
    2. 17 Kexec and Kdump
  8. VII Synchronized Clocks with Precision Time Protocol
    1. 18 Precision Time Protocol
  9. A GNU Licenses
Navigation←→
openSUSE Leap Documentation › System Analysis and Tuning Guide › Basics › General Notes on System Tuning
Top
←→
Applies to openSUSE Leap 42.3

1 General Notes on System Tuning

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 for the problem. You should also have a detailed plan on how to tune the system, because applying random tuning tips often will not help and could make things worse.

1.1 Be Sure What Problem to Solve
1.2 Rule Out Common Problems
1.3 Finding the Bottleneck
1.4 Step-by-step Tuning
Procedure 1.1: General Approach When Tuning a System

  1. Specify the problem that needs to be solved.

  2. In case the degradation is new, identify any recent changes to the system.

  3. Identify why the issue is considered a performance problem.

  4. Specify a metric that can be used to analyze performance. This metric could for example be latency, throughput, the maximum number of users that are simultaneously logged in, or the maximum number of active users.

  5. Measure current performance using the metric from the previous step.

  6. Identify the subsystem(s) where the application is spending the most time.

    1. Monitor the system and/or the application.

    2. Analyze the data, categorize where time is being spent.

  8. Tune the subsystem identified in the previous step.

  9. Remeasure the current performance without monitoring using the same metric as before.

  10. If performance is still not acceptable, start over with Step 3.

1.1 Be Sure What Problem to Solve

Before starting to tuning a system, try to describe the problem as exactly as possible. A statement like “The system is slow!” is not a helpful problem description. For example, it could make a difference whether the system speed needs to be improved in general or only at peak times.

Furthermore, make sure you can apply a measurement to your problem, otherwise you will not be able to verify if the tuning was a success or not. You should always be able to compare “before” and “after”. Which metrics to use depends on the scenario or application you are looking into. Relevant Web server metrics, for example, could be expressed in terms of

Latency

The time to deliver a page

Throughput

Number of pages served per second or megabytes transferred per second

Active Users

The maximum number of users that can be downloading pages while still receiving pages within an acceptable latency

1.2 Rule Out Common Problems

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 the output of the systemd journal (see Book “Reference”, Chapter 11 “journalctl: Query the systemd Journal”) 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.

1.3 Finding the Bottleneck

Finding the bottleneck very often is the hardest part when tuning a system. openSUSE Leap offers many tools to help 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.

1.4 Step-by-step 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 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.

→Part II System Monitoring←Part I Basics
Print this page

© 2018 SUSE