Documentation/devtools/maemo5/sp-endurance

Image:Ambox_content.png
This article documents a developer tool.
A list of available devtools is available, together with installation instructions.


Contents

[edit] Description

sp-endurance provides tools to save various system endurance related information (resource usage, errors) on device.

Provided tools include:

  • binaries for saving /proc and X client resource usage as CSV
  • a script for saving these along with syslog, SMAPS data, df and ifconfig output etc.
  • a script for getting quick system memory usage change overview from the endurance data

The endurance data can be used for detecting and measuring resource leakage and application errors.

[edit] Packages

source: sp-endurance

binary: sp-endurance

[edit] Usage

Because resource leakage detection requires repeating the given use-cases many times, it's best to automate the running of the test-cases. Both before the first and after each additional test-case run the following can be done:

# save-incremental-endurance-stats use-case-name
# cat /dev/null > /var/log/syslog
# cat /dev/null > /var/log/syslog.old

This will create a directory called use-case-name (if it doesn't exist) and add on each invocation a new subdirectory with the current endurance data. The subdirectories are named 101, 102 and so on.

Syslogs can be large and they are included into the endurance data so it's best to clear syslog(s) (as indicated above) after the endurance data is stored. Otherwise storing the data can take quite a long time and potentially consume huge amounts of disk space.

Note: If you run this in the device over ssh instead of from console, you might not have DISPLAY set correctly and then xmeminfo complains that it cannot connect to X server. In that case, just enter:

# export DISPLAY=:0

before starting your testing.

[edit] Emphasizing leakage

Sometimes it is not clear from the endurance data whether there's a memory leak or not. Increasing the number of test-case runs helps, but getting more measurements doesn't necessarily make it easier to see the leakage. In this case it is best to emphasize the leakage by increasing the number of test-case repeats between measurements exponentially, like this:

#!/bin/sh
measurements=5
repeats=1
for round in $(seq $measurements); do
        echo "round $round:"
        # repeat the test-case round^2 times
        for repeat in $(seq $repeats); do
                echo -n " $repeat"
                # RUN THE TEST-CASE HERE
        done
        repeats=$(($repeats+$repeats))
        save-incremental-endurance-stats use-case-name
        cat /dev/null >/var/log/syslog
        cat /dev/null >/var/log/syslog.old
done

[edit] Post-processing

After the tests have been completed, the stored endurance data can then be transferred to PC for post-processing with sp-endurance-postproc.

Note that the post-processing tools create the error and resource leakage summary from the differences between 2nd and last measurement. They assume that:

  • the first measurement is "initial state" i.e. the system and application are still in a state where things needed by the test-case are not yet initialized
  • processes involved in the test-case haven't been terminated before the last measurement. If the process doesn't exist anymore in the last measurement, there's nothing to differentiate

On the device a rough system memory overview of the endurance data can be obtained with:

# endurance-mem-overview use-case-name/*

[edit] Links

Man pages:

[endurance-mem-overview](/development/documentation/man_pages/endurance-mem-overview.html)

[proc2csv](/development/documentation/man_pages/proc2csv.html)

[save-incremental-endurance-stats](/development/documentation/man_pages/save-incremental-endurance-stats.html)

[xmeminfo](/development/documentation/man_pages/xmeminfo.html)

[edit] See Also

sp-endurance-postproc, syslog