Linux stress testing and LTP Architecture

I. Several Questions

Before getting started, let's look at a few questions: What is stability and reliability? What is stress testing? Why stress testing?

What is stability and reliability?
Stability reflects that the system will not experience exceptions. Reliability reflects the ability of the system to maintain normal operation without being affected by the outside world.
The stability and reliability of the system are usually measured by the continuous running time and the reliable running time of the system.

What is stress testing?
Stress testing is a destructive test, that is, the operation of the system under abnormal and overloaded conditions. It is used to assess how the system will run when the maximum load is exceeded. It is a test of the system's ability to withstand a certain load intensity under normal circumstances.

Why stress testing?
Generally, we use stress testing to determine the stability and reliability of the system.

After learning about the above problems, let's take a look at how to design a stress test.

Ii. Design of stress testing

In the test of Linux kernel version stability, it is necessary to clearly declare and prove why the version is stable or unstable. Different Linux developers, users, and publishers use their own methods to test kernel stability. However, if they do not publish basic information about the tests they run, the covered code, and the pressure level they reach, this will greatly reduce the value of the results.

Therefore, an appropriate test method should be provided to standardize the Linux kernel stability test. A combined test method is developed based on the statistics on the utilization rate of system resources, the four steps of this combined test method are: Test selection, system resource utilization evaluation, kernel code coverage analysis, and final stress test evaluation.

1. Test Selection
The test selection includes testing to achieve two goals:
-The test should be able to obtain a high level of resource utilization in the main kernel areas such as CPU (s), memory, I/O, and network.
-The test should fully overwrite the kernel code to support the stability statement generated from the results.

2. system resource utilization rate evaluation
The combination of the selected tests must put sufficient pressure on system resources. The four main aspects of the Linux kernel can affect the system response and execution time:
-CPU: the time used to process data on the machine's CPU (s.
-Memory: the time when the data is read and written from the real memory.
-I/O: the time when data is read and written from the disk memory.
-Networking: the time when data is read and written from the network.

The evaluation phase of system resource utilization usually requires multiple attempts to obtain a suitable test combination and get the expected level of utilization. Overuse is always a critical issue when determining a test combination. For example, if the selected combination is too limited by I/O, the CPU test result may be poor, and vice versa. This part of the method involves a large number of experiments and errors until all resources reach the expected level.
After a combination is selected, the test must run for a long time to accurately evaluate the resource utilization rate. The duration of the test depends on the length of each test. If multiple tests run at the same time, the time must be long enough so that the longest of these tests can be completed. In this evaluation process, the SAR tool should also be running. In the conclusion of evaluation operation, you should collect and evaluate the utilization levels of all four types of resources.

3. Analyze kernel code coverage
Obtaining adequate kernel coverage is another responsibility for system stress testing. Although the selected test combination makes full use of the four main resources, it may be a small part of the execution of the kernel. Therefore, the coverage rate should be analyzed to ensure that the combination can become a system stress test, rather than a system load generator.

4. Evaluate the final stress test
The last step in the method is to verify the system stress test. Execute stress tests on a kernel that is considered stable; normally, the kernel in the release version can meet this requirement, but not always. To perform stress testing over a long period of time and run the SAR tool at the same time, there are two reasons:
-Running for a long time can help you discover all problems in the combination. Otherwise, these problems may be ignored in a short period of "sniff test.
-The data generated by SAR constitutes a baseline for comparison during testing.
　　
After a long running, you can determine whether the test combination is a suitable candidate for system stress testing based on all the collected data.

Iii. Ltp (Linux test project)

The LTP Working Group designs the Linux kernel stress test script ltpstress. sh used this design method to provide sufficient pressure to the system. The LTP Working Group analyzed the combined test, to determine which parts of the Linux kernel are used in the test execution. Then, the composite test was modified to increase the percentage of code coverage while maintaining the expected high-intensity system pressure. The final stress test covers enough of the Linux kernel to facilitate stability declaration, and supports data with system usage and kernel code coverage.

There are two open-source tools to help analyze the code coverage of the Linux kernel:
-Gcov: an open source code tool maintained by LTP. This tool analyzes kernel code coverage and reports which rows, functions, and branches are overwritten and how many times they are accessed.
-Lcov: Another open source code tool developed by IBM and maintained by LTP. This tool consists of a Perl script built on text-based gcov output to implement HTML-based output. The output includes the coverage percentage, chart, and overview page, allowing you to quickly browse the coverage data. You can find these two tools on the LTP homepage.
The lcov tool generates a complete HTML Tree Containing each line of code in the kernel and the data (if any) about how many times each line has been executed ). This tool quantifies the coverage data and generates a percentage number on each part of the kernel and file coverage.
The kernel code coverage is only analyzed in ltpstress. SH is used in the design and development process to ensure lptsress. sh availability, we do not need to perform kernel code coverage analysis during actual testing.

1 LTP ltpstress. Sh target
The goal of ltpstress. Sh is to use the LTP test suite to test the Linux operating system for a long time, focusing on the workload related to the Linux user environment, rather than trying to prove the defects. This application combines multiple tests from different aspects of the LTP test suite as well as memory and network transmission load generators. Before execution, the test adjusts the total memory usage according to the number of physical and virtual memory in the system.

2 ltpstress. Sh Test Method
There are two phases of the test method: "initial test" and "stress test ". Passing the initial test is a necessary condition for starting the test. Initial tests include the successful operation of the LTP test suite on hardware and operating systems that will be used for reliability. The driver script runalltest. Sh attached to the LTP test kit is used to verify the kernel. This script serializes a testing of a component package and reports all the results. You can also choose to run several instances in parallel. By default, this script is executed:

-File System stress test.
-Hard Disk I/O test.
-Memory Management stress test.
-IPC stress test.
-Sched test.
-Test the command function.
-Verification test of the system call function.

Stress testing can verify the robustness of a product during high system usage. As runalltest. sh supplement, specially designed a name named ltpstress. sh testing scenario, while using network and memory management, runs a wide range of kernel components concurrently, and generates high load on the testing system. Ltpstress. Sh is also part of the LTP test suite. This script runs similar test cases in parallel and runs different test cases in sequence to avoid intermittent faults caused by simultaneous access to the same resource or mutual interference. By default, this script is executed:

-NFS stress test.
-Memory Management stress test.
-File System stress test.
-Mathematical (floating point) testing.
-Multi-thread stress testing.
-Hard Disk I/O test.
-IPC (pipeio, semaphore) test.
-Verification test of the system call function.
-Network pressure test.

3. System Monitoring
The top tool attached to the LTP test suite is modified and used as a system monitoring tool. With top, you can observe the behavior of the processor in real time. The improved top tool has additional functions. You can save the snapshot of the top result to a file and give an average Summary of the result file, including CPU, memory, and swap space utilization.

In our test, the SAR tool takes a snapshot of the system usage every 10 seconds and saves it to the result file.

The hardware configurations of all selected test systems should be the same as possible before the test. Remove additional hardware to reduce potential hardware faults. Select the lowest security option during image installation. Reserve at least 2 GB of hard disk space to store top data files and LTP log files.

Do not interfere with the system during the test. Occasionally visit the system to confirm that the test is still in progress. Methods of confirmation include using PS commands, checking top data, and checking LTP log data.

4. Ltp Structure
The directory structure of LTP is basically divided into the document directory (DOC), the test driver directory (PAN), the test Script directory (testscripts), and the test case library (testcase), testing command file directory (runtest), header file directory (include), library directory (LIB) and so on.
DOC: This directory is the location of the instruction file and help document. The content of LTP and each tool are described in detail in this directory.
Pan: This directory stores the test driver pan of the LTP test suite.
Testscripts: This directory stores a set of executable test scripts and different test scripts.
Testcase: This directory stores the source code of all test cases used in the LTP test suite.
Runtest: each file in this directory is a set of test case commands to be executed, each file for different aspects of the test.
Include: the header file directory of the LTP test suite, which defines the data structure and function structure of LTP.
Lib: library file required by the LTP test suite during runtime, which defines various functions of LTP.

5 LTP Test Method

The LTP test suite has a dedicated test driver pan. The execution of specific test cases is called by Pan. It can track orphan processes and capture test output information. It works like this:
Read the command line to be executed for the entry to be tested from a test command file, wait for the end of the test, and record the detailed test output. By default, Pan selects a command line randomly to run the task. You can specify the number of times the test is executed at the same time.
Pan will record the detailed output produced by the test in a complex format, but it does not sort and collect data. The data sort and collect statistics is completed by workers, explain is a testing result analysis tool that understands the pan output format and outputs it into a table
Form to summarize those tests for passed or failed.

6. Actual LTP operation
In actual operation, you also need to configure some necessary services to run the LTP test suite correctly, with ltprunall. sh can be run without configuring other services, but for ltpstress. sh, which can run correctly only after some related services are configured. The services you need to configure are as follows:

Configure the RSH and rlogin services so that you can directly log on to the local machine as root without password verification.
Enable the xinetd service.
Create a file named. rhosts in the user's home directory. The file content is the host name and IP address that allows RSH and rlogin operations on the local machine. An example is as follows:
# Vi. rhosts
Test. My. Domain
192.168.1.11
Localhost. localdomain
127.0.0.1

The last thing to do in the configuration work is to restart the xinetd service, because RSH and rlogin are controlled by the xinetd service:
/Etc/init. d/xinetd restart

Or service xinetd restart

Http://shop104965075.taobao.comhttp: // shop104965075.taobao.com

Http://linuxeden.com/doc/24305.html