Linux stability testing software detailed __linux

This article introduces a variety of Linux systems, server testing software. There are many wrong places, please correct the reader.

a SPEC2000

Spec CPU2000 is a benchmark program test group developed by the standard performance evaluation agency "The Standard Performance evaluation Corporation (SPEC)" for evaluating CPU performance. processors, memory, and compilers all affect the final test results, while the impact of I/O (disk), network, operating system, and graphics subsystems on spec CPU2000 is very small. At present, SPEC CPU2000 is the industry's preferred CPU profiling tool.
SPEC CPU2000 includes CINT2000 and CFP2000 two sets of benchmark programs that measure and contrast CPU fixed-point performance, which is used to measure and contrast floating-point performance. CINT2000 contains 12 test projects, CFP2000 contains 14 test projects.

The main hardware modules involved: CPU, DDR, compiler

Common parameters:

two SPEC2006

and spec CPU 20,001 samples, Spec CPU 2006 includes the

CINT2006 and C FP2006 Two subprojects, the former for measuring and contrasting integer performance, while the latter is used to measure and
In comparison to floating-point performance, some of the tests in Spec CPU 2000 are upgraded in Spec CPU 2006 and discarded/
Some tests were added, so the two-version test scores were not comparable.

General parameter Description

Runspec-c linux-mipsel-gcc-i test-n 1 All	Runspec	Runspec represents the execution of the spec CPU2000 benchmark program to begin testing
-C	Read the test configuration file, test.cfg in the Config directory of the spec CPU2000 installation directory
-I.	Enter the size of the test dataset, ref represents the maximum test dataset, and test represents the minimum test dataset
-N	The number of times each test project is run, if spec CPU2000 is required to automatically calculate the test score, the number of times required is equal to or greater than 3, i.e. n>=3
L	If an error occurs in a use case during the test, skip the error case, and continue with the other use cases, if the program runs incorrectly without the parameter, SPEC CPU2000 will stop the test
All	SPEC CPU2006 will run all test projects in the benchmark program
LINUX-MIPSEL-GCC: Configuration files include hardware software, and other configurations, etc.	HW Config	hw config  hw_cpu_name  = loongson  hw_model      = 3A  hw_cpu_mhz   = 800  hw_fpu        = integrated  hw_nchips       = 1  HW _ncores       = 4  hw_ncoresperchip= 4  hw_ Nthreads     = 1  hw_ncpuorder = 1  hw_parallel   = no  hw_pcache    = 64kb i + 64kb d   HW_SCACHE    = 4MB (i + d)  hw_memory        = 2 x 1gb ddr333   hw_vendor        = ict
SW Config	Sw_os = Debian Sw_file = ext3 Sw_state = RunLevel 3 Sw_compiler = gcc, g++ & Gfortran 4.3
Other configuration	Do not list

three Dbench

Dbench is a very analog file Services test tool that tests local file systems by generating I/O loads or
Network File System. 18 different types of I/O calls are used. This includes opening files, reading, writing, locking, unlocking, getting file properties, setting file properties, shutting down, getting disk free space, getting file time, setting file time, find open, Find Next, find close, rename files, delete files, Creates a new file and empties the file buffer.
Dbench can simulate any number of clients without having to physically set them up. Dbench only generates file system load, it does not have network calls. During the run, each client records the number of bytes of data being moved and divides the number by the amount of time it takes to move the data. The total number of client throughput is then accumulated to determine the overall throughput of the server. The total I/O throughput fraction represents the number of megabytes transmitted per second during the test. This measure shows the quality of the server's processing of file requests from the client.
Dbench is ideal for testing hyper-threading because it creates a lot of load and activity on the CPU and I/O scheduler. Dbench can rigorously test the ability of hyper-threading to support multithreaded file services, because clients create and access many files at the same time. Each client must create a test data file equivalent to approximately 21 megabytes. For tests to run 20 clients, it is expected to be about 420 megabytes of data. Dbench is considered a very good test method for measuring the performance of the elevator algorithm used in the Linux file system. Dbench is used to test the correctness of the algorithm and to test whether the elevator response is fast enough. It's also an interesting page replacement test.
Client.txt files from the network sniffer dump a real netbench run. Client.txt about 4MB, contains 90,000 operations for one NetBench client doing a typical run in NetBench. They parse client.txt and use it to produce the same load, to simulate any number of concurrent clients.
Dbench only the file system load generated. It all the same IO call, unlike the Samba SMBD server that faces the NetBench run, it has no network calls.
Tbench: Generated TCP and processing load. The effect is that the same socket SMBD will be called for netbench load. It does not have a file system call. Behind the idea is tbench in NetBench
Eliminate SMBD in the test, although SMBD code can infinately acceleration. "The throughput Tbench results show the NetBench run speed.

Main design hardware modules: CPU, IO, SATA

Parameter Setting Reference:

-V	Display version
-T	Set run time
-D	Run under the underlying directory
-C	Set the path of the load file
-S	Sync io files
-S	Sync Io folder
-X	Setting up support for EA
-T	Set socket options for Tbench
Nproces	Number of clients

Four Unixbench

Unixbench is also a classic tool for benchmarking performance in Linux and UNIX test systems, Unixbench testing includes
The benchmark performance of system call, read-write, process, 2D, 3D, Pipeline, operation, C library and so on, its advantage is to mention
For the system performance evaluation system, for the system scoring, so easy to compare the system test; but Unixbench
Lacking in network performance testing. The Unixbench test content contains system, 2D, 3D, misc test Items. System
Some basic functions of the test system, 2D test 2D graphics acceleration, 3D test 3D acceleration; Misc test such as characters,
Tests such as integral type.

Which is designed to test the module,

Dhrystone
Used to compute and compare the performance of a computer. Because there is no floating-point operation, this test is mainly focused on string processing. This test is deeply influenced by the following factors: hardware and software design, compiler and linker options, code optimization, cache memory, wait status, and integer data types.
Whetstone
Measure the speed and efficiency of floating-point operations. This test consists of several modules that are considered to be a mixture of operations that are typically used in scientific applications. Various C functions, including sin, cos, sqrt, exp and log, and reshaping, floating-point arithmetic operations, array access, conditional transitions, and procedure calls are all used. Integers and floating-point arithmetic are computed in this test.
EXECL throughput
Calculates the number of execl calls that occur per second. Execl is part of the EXEC function family. It updates the current process image with a new process image. It and many other similar commands are EXECVE () front-end programs.
File Copy
This test measures the rate at which data can be transmitted from one file to another when different buffer sizes are used. The read-write replication test for a file obtains the number of characters that can be read, written, and copied within a specified time (default is 10 seconds).
Pipe throughput
Pipelines are one of the easiest ways to communicate between processes. Pipeline throughput refers to the number of times per second that a process can write 512 bytes of data to the pipeline and read them back from the pipeline. This test has no counterpart in the actual program design.
pipe-based Context Switching
Calculates the number of times that two processes exchange an increased integer through a pipeline. A pipeline based context-switching test is more like a real application. This test produces a subprocess that can be used to continue a two-way pipe conversation.
Process creation
Calculates the number of times a process derives and harvests a child process that exits immediately. Because process creation involves creating process control blocks and allocating memory for new processes, this test is directly dependent on memory bandwidth. This test is typically used to compare the execution of a variety of operating system process creation calls.
Shell Scripts
Measure the number of concurrent copies of a set of 1,2,4,8 shell scripts that can be started and harvested by the process per second.
System Call Overhead
This test is an estimate of the cost of entering and leaving the operating system kernel. For example, the overhead of executing a system call. It consists of a simple system that repeats calls to GetID system calls and GetID returns the process is number of the calling process. This test uses the time to perform these calls to estimate the cost of entry and departure.
Graphical Tests
This test provides a graphical test of 2d,3d. Reporting performance depends not only on the hardware, but also on whether the system has appropriate drivers for the hardware.

Testing involves hardware modules including: CPU, memory, video card, System (compiler, file transfer, etc.)

The parameters are set as follows:

td>   td> verbose mode runs the

	./run	run a standard "index" test ("Byte index"), save the report under the results directory
	./run gindex	build system basic metrics and graphics index
description	more than one CPU, the test will be run two times  -  a single copy of each test run once, and once with n parts, where n is the number of CPUs. Some categories of tests, but (current graphics tests) will only run a single copy. Because the test is based on a certain amount of time (variable work), system runs usually takes about 18 minutes in the "Graphics" section of about 29 minutes. A "gindex on a dual-core machine runs" 2 "System" through (single and dual processing) and a "graphics" run for about 15 minutes.
parameter setting	-Q	quiet mode run
-v
-I (count)	run cycles, at least 1, the default is ten
-C (n	The number of scripts for a test run,-C can be used multiple times, such as:  ./run -c 1 -c 4
Run file internal test	system