1.1 Common recommendations
1.1.1 A lot of notes (record Everything)
One of the important things to do when doing performance tuning is to record everything, including the results of each output and execution. You can create a new folder and then plug the resulting files into that folder. Include the following:
- Documentation of hardware/software configuration, such as DMESG and uname–a output
- Save and organize performance results, record system configurations, and also save the results of your tests.
- Write a command-line call that writes a complex command to a script or record to a terminal.
- Record research information and URLs, and record information about what the Internet finds.
In addition to documenting this information, the following points should be kept in mind when investigating a problem:
- The meaning of the result may be ambiguous, and sometimes you need more information to understand the meaning of the result.
- All the information is useful, just like investigating a crime.
- Review your notes regularly to get new ideas--and keep them fresh.
1.1.2 Perform repetitive tasks automatically
There are many commands for Linux, and it is easy to enter a command that is responsible for errors. Therefore, it is a good idea to automate performance tools and application testing.
- The invocation of the performance tool is suggested to be written in script or saved to a TXT file.
1.1.3 Choose the low-cost tool as much as possible
In general, the observing system modifies the behavior of the system. (physically called Heisenberg uncertainty principle) So, we try to use low-cost tools, such as PS is good, and with memprof or valgrind overhead, will change the behavior of the system.
1.1.4 using multiple tools to clarify problems
Using only one tool can lead to misleading judgments, such as tool A, which says IO is slow, and B says that the system uses a lot of switching. If you replace a faster disk with only a, the result is very little performance gains. You should actually increase the memory and use less swap so there is not a lot of disk IO.
1.1.5 Trust your tools.
The tool is just, to believe it.
1.1.6 use other people's experience (cautious)
Using the experience of others may be more effective, but keep a skeptical attitude.
1.2 Overview of Performance survey
1.2.1 Find indicators, baselines, and targets
- Determine the metrics and know when to stop optimization, such as the number of requests per second of the Web.
- Determine the baseline, run the application and record its performance before tuning and tuning, which is the baseline.
- Identify goals that will guide you through performance tracking. You can try to find other people with the same configuration, find the results of industry standard test programs, or use your hardware on different OS or applications.
1.2.2 Tracking approximation problems
1.2.3 to see if the problem is resolved already
Find similar information on the web.
1.2.4 Project Start (Start survey)
You can try some of the following methods to start a survey.
Isolate problems, use system differences to discover causes, change only one thing at a time, and always re-measure after optimization.
1.2.5 Records, Records, records
Linux performance Optimization first chapter performance tracking recommendations
