Provided by: bpfcc-tools_0.29.1+ds-1ubuntu7_all bug

NAME

       dbstat - Collect histograms of MySQL/PostgreSQL query latencies.

SYNOPSIS

       dbstat [-v] [-p PID [PID ...]] [-m THRESHOLD] [-u] [-i INTERVAL] {mysql,postgres}

DESCRIPTION

       This  traces queries served by a MySQL or PostgreSQL server, and collects a histogram of query latencies.
       The histogram is printed at the end of collection, or at specified intervals.

       This uses User Statically-Defined Tracing (USDT) probes, a feature added  to  MySQL  and  PostgreSQL  for
       DTrace support, but which may not be enabled on a given installation. See requirements.

       Since this uses BPF, only the root user can use this tool.

REQUIREMENTS

       CONFIG_BPF, bcc, and MySQL server with USDT probe support (when configuring the build: -DENABLE_DTRACE=1)
       or PostgreSQL server with USDT probe support (when configuring the build: --enable-dtrace).

OPTIONS

       -h Print usage message.

       -p PID Trace this PID. If no PID is specified, the tool will attempt to automatically detect the MySQL or
              PostgreSQL processes running on the system.

       -m THRESHOLD
              Minimum query latency (duration) to trace, in milliseconds.  Default is all queries.

       -u     Display query latencies in microseconds (default: milliseconds).

       -i INTERVAL
              Print summaries (histograms) at this interval, specified in seconds.

       {mysql,postgres}
              The database engine to trace.

EXAMPLES

       Display histogram of MySQL query latencies:
              # dbstat mysql

       Display histogram of PostgreSQL query latencies slower than 10ms in pid 408:
              # dbstat postgres -p 408 -m 10

       Display histogram of PostgreSQL query latencies at 3-second intervals:
              # dbstat postgres -i 3

OVERHEAD

       This  adds  low-overhead instrumentation to queries, and only emits output data from kernel to user-level
       if they query exceeds the threshold. If the server query rate is less than  1,000/sec,  the  overhead  is
       expected to be negligible. If the query rate is higher, test to gauge overhead.

SOURCE

       This is from bcc.

              https://github.com/iovisor/bcc

       Also  look  in  the bcc distribution for a companion _examples.txt file containing example usage, output,
       and commentary for this tool.

OS

       Linux

STABILITY

       Unstable - in development.

AUTHOR

       Sasha Goldshtein

SEE ALSO

       dbslower(8)