- The format of the log is:
-
-
-client_id transaction_no time script_no time_epoch time_us schedule_lag retries
-
-
- where
- client_id indicates which client session ran the transaction,
- transaction_no counts how many transactions have been
- run by that session,
- time is the total elapsed transaction time in microseconds,
- script_no identifies which script file was used (useful when
- multiple scripts were specified with or ),
- and time_epoch/time_us are a
- Unix-epoch time stamp and an offset
- in microseconds (suitable for creating an ISO 8601
- time stamp with fractional seconds) showing when
- the transaction completed.
- The schedule_lag field is the difference between the
- transaction's scheduled start time, and the time it actually started, in
- microseconds. It is only present when the option is used.
+ Each line in a log file describes one transaction.
+ It contains the following space-separated fields:
+
+
+
+ client_id
+
+ identifies the client session that ran the transaction
+
+
+
+
+
+ transaction_no
+
+ counts how many transactions have been run by that session
+
+
+
+
+
+ time
+
+ transaction's elapsed time, in microseconds
+
+
+
+
+
+ script_no
+
+ identifies the script file that was used for the transaction
+ (useful when multiple scripts are specified
+ with or )
+
+
+
+
+
+ time_epoch
+
+ transaction's completion time, as a Unix-epoch time stamp
+
+
+
+
+
+ time_us
+
+ fractional-second part of transaction's completion time, in
+ microseconds
+
+
+
+
+
+ schedule_lag
+
+ transaction start delay, that is the difference between the
+ transaction's scheduled start time and the time it actually
+ started, in microseconds
+ (present only if is specified)
+
+
+
+
+
+ retries
+
+ count of retries after serialization or deadlock errors during the
+ transaction
+ (present only if is not equal to one)
+
+
+
+
+
+
When both and are used,
the time for a skipped transaction will be reported as
skipped.
- retries is the sum of all retries after the
- serialization or deadlock errors during the current script execution. It is
- present only if the option is not equal to 1.
If the transaction ends with a failure, its time
will be reported as failed. If you use the
option, the
With the option, a different
- format is used for the log files:
-
-
-interval_start num_transactions sum_latency sum_latency_2 min_latency max_latency
-sum_lag sum_lag_2 min_lag max_lag skipped
-retried retries failures serialization_failures deadlock_failures
-
-
- where
- interval_start is the start of the interval (as a Unix
- epoch time stamp),
- num_transactions is the number of transactions
- within the interval,
- sum_latency is the sum of the transaction
- latencies within the interval,
- sum_latency_2 is the sum of squares of the
- transaction latencies within the interval,
- min_latency is the minimum latency within the interval,
- and
- max_latency is the maximum latency within the interval,
- failures is the number of transactions that ended
- with a failed SQL command within the interval.
-
- The next fields,
- sum_lag, sum_lag_2, min_lag,
- and max_lag, only meaningful if the
- option is used. Otherwise, they are all 0.0.
- They provide statistics about the time each transaction had to wait for the
- previous one to finish, i.e., the difference between each transaction's
- scheduled start time and the time it actually started.
- The next field, skipped,
- is only meaningful if the option is used, too. Otherwise it is 0.
- It counts the number of transactions skipped because they would have
- started too late.
-
- The retried
- and retries fields are only meaningful if
- the option is not equal to 1. Otherwise they
- are 0. They report the number of retried transactions and the sum of all
- retries after serialization or deadlock errors within the interval. Each
- transaction is counted in the interval when it was committed.
-
- failures is the sum of all failed transactions.
- If is specified, instead of the sum of
- all failed transactions you will get more detailed statistics for the
- failed transactions grouped by the following types:
- serialization_failures is the number of
- transactions that got a serialization error and were not retried after this,
- deadlock_failures is the number of transactions
- that got a deadlock error and were not retried after this.
- If is not
- specified, serialization_failures
- and deadlock_failures are always 0.
+ format is used for the log files. Each log line describes one
+ aggregation interval. It contains the following space-separated
+ fields:
+
+
+
+ interval_start
+
+ start time of the interval, as a Unix-epoch time stamp
+
+
+
+
+
+ num_transactions
+
+ number of transactions within the interval
+
+
+
+
+
+ sum_latency
+
+ sum of transaction latencies
+
+
+
+
+
+ sum_latency_2
+
+ sum of squares of transaction latencies
+
+
+
+
+
+ min_latency
+
+ minimum transaction latency
+
+
+
+
+
+ max_latency
+
+ maximum transaction latency
+
+
+
+
+
+ sum_lag
+
+ sum of transaction start delays
+ (zero unless is specified)
+
+
+
+
+
+ sum_lag_2
+
+ sum of squares of transaction start delays
+ (zero unless is specified)
+
+
+
+
+
+ min_lag
+
+ minimum transaction start delay
+ (zero unless is specified)
+
+
+
+
+
+ max_lag
+
+ maximum transaction start delay
+ (zero unless is specified)
+
+
+
+
+
+ skipped
+
+ number of transactions skipped because they would have started too late
+ (zero unless
+ and are specified)
+
+
+
+
+
+ retried
+
+ number of retried transactions
+ (zero unless is not equal to one)
+
+
+
+
+
+ retries
+
+ number of retries after serialization or deadlock errors
+ (zero unless is not equal to one)
+
+
+
+
+
+ failures
+
+ number of transactions that ended with a failed SQL command
+
+
+
+
+
+ serialization_failures
+
+ number of transactions that got a serialization error and were not
+ retried afterwards
+ (zero unless is specified)
+
+
+
+
+
+ deadlock_failures
+
+ number of transactions that got a deadlock error and were not
+ retried afterwards
+ (zero unless is specified)
+
+
+
+
- Here is some example output with following options:
+ Here is some example output generated with these options:
-pgbench --aggregate-interval=10 --time=20 --client=10 --log --rate=1000
---latency-limit=10 --failures-detailed --max-tries=10 test
+pgbench --aggregate-interval=10 --time=20 --client=10 --log --rate=1000 --latency-limit=10 --failures-detailed --max-tries=10 test
1649114136 5815 27552565 177846919143 1078 21716 2756787 7264696105 0 9661 0 7854 31472 4022 4022 0
1649114146 5958 28460110 182785513108 1083 20391 2539395 6411761497 0 7268 0 8127 32595 4101 4101 0
- Notice that while the plain (unaggregated) log file shows which script
- was used for each transaction, the aggregated log does not. Therefore if
+ Notice that while the plain (unaggregated) log format shows which script
+ was used for each transaction, the aggregated format does not. Therefore if
you need per-script data, you need to aggregate the data on your own.
projects / postgresql.git / commitdiff