Skip to content

pt-pmp

NAME

pt-pmp - Aggregate GDB stack traces for a selected program.

SYNOPSIS

Usage

pt-pmp [OPTIONS] [FILES]

pt-pmp is a poor man’s profiler, inspired by http://poormansprofiler.org. It can create and summarize full stack traces of processes on Linux. Summaries of stack traces can be an invaluable tool for diagnosing what a process is waiting for.

RISKS

Percona Toolkit is mature, proven in the real world, and well tested, but all database tools can pose a risk to the system and the database server. Before using this tool, please:

  • Read the tool’s documentation

  • Review the tool’s known “BUGS”

  • Test the tool on a non-production server

  • Backup your production server and verify the backups

DESCRIPTION

pt-pmp performs two tasks: it gets a stack trace, and it summarizes the stack trace. If a file is given on the command line, the tool skips the first step and just aggregates the file.

To summarize the stack trace, the tool extracts the function name (symbol) from each level of the stack, and combines them with commas. It does this for each thread in the output. Afterwards, it sorts similar threads together and counts how many of each one there are, then sorts them most-frequent first.

pt-pmp is a read-only tool. However, collecting GDB stacktraces is achieved by attaching GDB to the program and printing stack traces from all threads. This will freeze the program for some period of time, ranging from a second or so to much longer on very busy systems with a lot of memory and many threads in the program. In the tool’s default usage as a MySQL profiling tool, this means that MySQL will be unresponsive while the tool runs, although if you are using the tool to diagnose an unresponsive server, there is really no reason not to do this. In addition to freezing the server, there is also some risk of the server crashing or performing badly after GDB detaches from it.

Dumpers eu and pteu use eu-stack (https://sourceware.org/elfutils/) instead of GDB. eu-stack collects stacks with minimal impact and does not cause same issues as GDB does. Dumpers eu and pteu are recommended to use instead of GDB and one of them will be default dumper in future versions.

OPTIONS

--binary

short form: -b; type: string; default: mysqld

Which binary to trace.

--dumper

short form: -d; type: string; default: gdb

Which dumper use to get stack traces(gdb: gdb, eu: eu-stack, pteu: pt-eustack-resolver).

--help

Show help and exit.

--interval

short form: -s; type: int; default: 0

Number of seconds to sleep between --iterations.

--iterations

short form: -i; type: int; default: 1

How many traces to gather and aggregate.

--lines

short form: -l; type: int; default: 0

Aggregate only first specified number of many functions; 0=infinity.

--pid

short form: -p; type: int

Process ID of the process to trace; overrides --binary.

--readnever

Pass option --readnever to gdb. With this option gdb will not read symbol files, thus produce stack traces way faster. However, such traces may not be sufficient for the diagnostic.

--save-samples

short form: -k; type: string

Keep the raw traces in this file after aggregation.

--tids

short form: -t; type: string; default: *

Extract traces only for specific tids.

This option uses regular expressions to select threads. For example, if the collected stack trace has data for threads:

[New Thread 0x52173940 (LWP 23846)]
[New Thread 0x52132940 (LWP 23845)]
[New Thread 0x520f1940 (LWP 23844)]
[New Thread 0x520b0940 (LWP 23798)]
[New Thread 0x5206f940 (LWP 23776)]
[New Thread 0x5202e940 (LWP 23775)]
[New Thread 0x51fed940 (LWP 23774)]
[New Thread 0x51fac940 (LWP 23728)]
[New Thread 0x51f6b940 (LWP 23727)]
[New Thread 0x51f2a940 (LWP 21264)]
[New Thread 0x51ee9940 (LWP 21263)]
[New Thread 0x51ea8940 (LWP 21201)]

-t 21 will print stack traces for threads 21264, 21263, 21201

-t 21201,23846 will print stack traces for threads 21201, 23846

-t 21201,237.8 will print stack traces for threads 21201, 23798, 23728

--version

Show version and exit.

ENVIRONMENT

This tool does not use any environment variables.

SYSTEM REQUIREMENTS

This tool requires Bash v3 or newer. If no backtrace files are given, then gdb is also required to create backtraces for the process specified on the command line.

BUGS

For a list of known bugs, see https://jira.percona.com/projects/PT/issues.

Please report bugs at https://jira.percona.com/projects/PT. Include the following information in your bug report:

  • Complete command-line used to run the tool

  • Tool --version

  • MySQL version of all servers involved

  • Output from the tool including STDERR

  • Input files (log/dump/config files, etc.)

If possible, include debugging output by running the tool with PTDEBUG; see “ENVIRONMENT”.

ATTENTION

Using <PTDEBUG> might expose passwords. When debug is enabled, all command line parameters are shown in the output.

DOWNLOADING

Visit http://www.percona.com/software/percona-toolkit/ to download the latest release of Percona Toolkit. Or, get the latest release from the command line:

wget percona.com/get/percona-toolkit.tar.gz

wget percona.com/get/percona-toolkit.rpm

wget percona.com/get/percona-toolkit.deb

You can also get individual tools from the latest release:

wget percona.com/get/TOOL

Replace TOOL with the name of any tool.

AUTHORS

Baron Schwartz, based on a script by Domas Mituzas (http://poormansprofiler.org/)

ABOUT PERCONA TOOLKIT

This tool is part of Percona Toolkit, a collection of advanced command-line tools for MySQL developed by Percona. Percona Toolkit was forked from two projects in June, 2011: Maatkit and Aspersa. Those projects were created by Baron Schwartz and primarily developed by him and Daniel Nichter. Visit http://www.percona.com/software/ to learn about other free, open-source software from Percona.

VERSION

pt-pmp 3.6.0