Linux Stress & Torture Testing, Burning In Systems With Open-Source
Written by Michael Larabel in Hardware on 7 January 2015 at 08:37 PM EST. Add A Comment
There's a new way to pound your Linux/BSD systems very hard for burning them in, checking the system's reliability, and stressing them to the max.

One of the sought after features for the Phoronix Test Suite has been to be able to concurrently run benchmarks in parallel to stress systems further -- not for speeding up the performance exploration process, but to brutally stress a system for reliability testing, etc. This feature is now enabled in Phoronix Test Suite on GitHub for those wishing to push their system hard.

This feature is exposed via the phoronix-test-suite stress-run sub-command and works the same way as the run/benchmark/batch-run commands. When running in the stress-run mode, there is no support for saving the test results since the numbers would be certainly skewed due to running tests randomly and concurrently. By default the Phoronix Test Suite will run two tests concurrently but you can easily increase this number via the PTS_CONCURRENT_TEST_RUNS environment variable to run however many tests you'd like all at once.

The current algorithm for pairing of tests to run concurrently is trying to pick one random test from each applicable hardware/software subsystem; so running phoronix-test-suite stress-run encode-mp3 encode-flac xonotic openarena would first result in one of the (CPU-based) encoding tests being run while the second test to be run concurrently would be a graphics test. As soon as one test is finished, another is slotted for immediate execution based upon the test subsystems still active and what random test from the passed tests/suites hasn't yet been run. In other words, it won't try running multiple graphics tests all at once or all disk tests all at once, but will try to do those consecutively -- unless of course all you pass to the stress-run command are tests/suites of the same subsystem type.

The Phoronix Test Suite also still supports the TOTAL_LOOP_TIME environment variable for just not running test(s) once but to keep doing so until however much time has elapsed as set by the environment variable in minutes. So running TOTAL_LOOP_TIME=60 phoronix-test-suite stress-run build-linux-kernel c-ray hpcc would keep running that same selection of tests for a total of one hour.

So if you wanted to get really advanced and push your system very hard for whatever reason, you could run something like TOTAL_LOOP_TIME=120 PTS_CONCURRENT_TEST_RUNS=4 phoronix-test-suite stress-run hpcc build-linux-kernel c-ray unigine-valley fio encode-flac ... to stress the system hard with four tests always running on the system at any given point for the next two hours. Thanks to the design of the Phoronix Test Suite, no changes are needed to the test profiles/suites and this will work with any contained PTS test (see all of the available test/suites via and paired with the other features of the open-source Phoronix Test Suite software the automated testing possibilities are near limitless.

This feature can be found in Git and will be found in this quarter's release of the Phoronix Test Suite 5.6 update. Any feedback, suggestions for a better test scheduling algorithm, or any further stress-run additions can be made by contacting me or simply by commenting on this article. For enterprise users in need of additional Phoronix Test Suite capabilities, custom engineering and commercial support is available.
Related News
About The Author
Author picture

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter or contacted via

Popular News This Week