• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..--

src/23-Nov-2023-13,0958,665

Android.bpD23-Nov-20232.2 KiB8275

COPYINGD23-Nov-202311.1 KiB202169

METADATAD23-Nov-2023309 1615

MODULE_LICENSE_APACHE2D23-Nov-20230

Makefile.amD23-Nov-202347 42

Makefile.inD23-Nov-202324.2 KiB755669

NOTICED23-Nov-202310.4 KiB191158

OWNERSD23-Nov-202346 21

README.mdD23-Nov-20235 KiB10570

aclocal.m4D23-Nov-202333.8 KiB952857

config.guessD23-Nov-202342.8 KiB1,4641,273

config.subD23-Nov-202335.6 KiB1,8361,698

configureD23-Nov-2023207.8 KiB7,4036,060

configure.acD23-Nov-20234.2 KiB143125

depcompD23-Nov-202317.4 KiB590375

install-shD23-Nov-202313.3 KiB520344

missingD23-Nov-202310.9 KiB368275

stressapptest.1D23-Nov-20233.8 KiB193150

README.md

1# stressapptest
2Stressful Application Test (or stressapptest, its unix name) is a memory interface test.
3It tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. It has been used at Google for some time and now it is available under the apache 2.0 license.
4
5  (Exported from code.google.com/p/stressapptest)
6
7Discussion group: https://groups.google.com/d/forum/stressapptest-discuss
8
9
10## Usage
11
12To execute, a typical command would be:
13```
14./stressapptest -s 20 -M 256 -m 8 -W    # Test 256MB, running 8 "warm copy" threads. Exit after 20 seconds.
15./stressapptest --help                  # list the available arguments.
16```
17Common arguments
18* -M mbytes : megabytes of ram to test (auto-detect all memory available)
19* -s seconds : number of seconds to run (20)
20* -m threads : number of memory copy threads to run (auto-detect to number of CPUs)
21* -W : Use more CPU-stressful memory copy (false)
22* -n ipaddr : add a network thread connecting to system at 'ipaddr'. (none)
23* --listen : run a thread to listen for and respond to network threads. (0)
24* -f filename : add a disk thread with tempfile 'filename' (none)
25* -F : don't result check each transaction, use libc memcpy instead. (false)
26
27Error handling
28* -l logfile : log output to file 'logfile' (none)
29* -v level : verbosity (0-20) (default: 8)
30
31```
32./stressapptest -s 20 -M 256 -m 8 -C 8 -W # Allocate 256MB of memory and run 8 "warm copy" threads, and 8 cpu load threads. Exit after 20 seconds.
33./stressapptest -f /tmp/file1 -f /tmp/file2 # Run 2 file IO threads, and autodetect memory size and core count to select allocated memory and memory copy threads.
34```
35
36
37## Installation
38
39stressapptest is often available on linux and can be installed as a distro package:
40```
41sudo apt-get install stressapptest
42sudo emerge stressaptest
43sudo yum install stressapptest
44sudo zypper install stressapptest
45```
46To build from source, the build/installation package follows the GNU guidelines. So, to download the latest package:
47```
48git clone https://github.com/stressapptest/stressapptest.git
49cd stressapptest
50./configure
51make
52sudo make install
53```
54And it should be installed. You can use the most common options on the configure script, it was generated by autoconf and automake, so they are accepted.
55
56
57## Objective
58
59Stressful Application Test (or stressapptest) tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation.
60
61stressapptest may be used for various purposes:
62* Stress test: as described here.
63* Hardware qualification and debugging.
64* Memory interface test: see the Theory behind this.
65* Disk testing.
66
67
68**Background**
69
70Many hardware issues reproduce infrequently, or only under corner cases. The theory being used here is that by maximizing bus and memory traffic, the number of transactions is increased, and therefore the probability of failing a transaction is increased.
71
72
73**Overview**
74
75stressapptest is a userspace test, primarily composed of threads doing memory copies and directIO disk read/write. It allocates a large block of memory (typically 85% of the total memory on the machine), and each thread will choose randomized blocks of memory to copy, or to write to disk. Typically there are two threads per processor, and two threads for each disk. Result checking is done as the test proceeds by CRCing the data as it is copied.
76
77
78**Detailed Design**
79
80The code is structured fairly simply:
81
82A large amount of memory is allocated in a single block (default is 85% of physical memory size).
83Memory is divided into chunks, each filled with a potentially stressful data pattern.
84Worker threads are spawned, which draw pages from an "empty" queue and a "valid" queue, and copy the data from one block to the other.
85Some threads memory copy the data.
86Some threads invert the data in place.
87Some threads write the data to disk, and read it to the new location.
88After the specified time has elapsed, all "valid" pages have their data compared with the original fill pattern.
89
90
91**Caveats**
92
93This test works by stressing system interfaces. It is good at catching memory signal integrity or setup and hold problems, memory controller and bus interface issues, and disk controller issues. It is moderately good at catching bad memory cells and cache coherency issues. It is not good at catching bad processors, bad physical media on disks, or problems that require periods of inactivity to manifest themselves. It is not a thorough test of OS internals. The test may cause marginal systems to become bricks if disk or memory errors cause hard drive corruption, or if the physical components overheat.
94
95
96**Security Considerations**
97
98Someone running stressapptest on a live system could cause other applications to become extremely slow or unresponsive.
99
100
101**Logged information**
102
103stressapptest can output a logfile of miscompares detected during its execution. stressapptest cannot yet log reboot failures, or other failures not visible to user space.
104
105