From 67a875355e4a6db294e9652af5a883876ddeb4a5 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 2 Jan 2017 12:26:03 -0500 Subject: In pgbench logging, avoid assuming that instr_times match Unix timestamps. For aggregated logging, pg_bench supposed that printing the integer part of INSTR_TIME_GET_DOUBLE() would produce a Unix timestamp. That was already broken on Windows, and it's about to get broken on most other platforms as well. As in commit 74baa1e3b, we can remove the entanglement at the price of one extra syscall per transaction; though here it seems more convenient to use time(NULL) instead of gettimeofday(), since we only need integral-second precision. I took the time to do some wordsmithing on the documentation about pgbench's logging features, too. Discussion: https://postgr.es/m/8837.1483216839@sss.pgh.pa.us --- doc/src/sgml/ref/pgbench.sgml | 96 ++++++++++++++++++++++++------------------- 1 file changed, 54 insertions(+), 42 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 3a65729bf35..3fb29f8c1d4 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -355,7 +355,7 @@ pgbench options dbname - Write the time taken by each transaction to a log file. + Write information about each transaction to a log file. See below for details. @@ -572,13 +572,9 @@ pgbench options dbname - Length of aggregation interval (in seconds). May be used only together - with -l - with this option, the log contains - per-interval summary (number of transactions, min/max latency and two - additional fields useful for variance estimation). - - - This option is not currently supported on Windows. + Length of aggregation interval (in seconds). May be used only + with option. With this option, the log contains + per-interval summary data, as described below. @@ -618,8 +614,8 @@ pgbench options dbname - Set the filename prefix for the transaction log file created by - @@ -1128,38 +1124,44 @@ END; Per-Transaction Logging - With the , - pgbench writes the time taken by each transaction + With the option), + pgbench writes information about each transaction to a log file. The log file will be named prefix.nnn, where prefix defaults to pgbench_log, and nnn is the PID of the - pgbench process. If the The format of the log is: -client_id transaction_no time script_no time_epoch time_us schedule_lag +client_id transaction_no time script_no time_epoch time_us schedule_lag - where time is the total elapsed transaction time in microseconds, + 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 - Here is a snippet of the log file generated: + Here is a snippet of a log file generated in a single-client run: 0 199 2241 0 1175850568 995598 0 200 2465 0 1175850568 998079 @@ -1176,7 +1178,8 @@ END; 0 202 2038 0 1175850569 2663 - Another example with --rate=100 and --latency-limit=5 (note the additional + Another example with --rate=100 + and --latency-limit=5 (note the additional schedule_lag column): 0 81 4621 0 1412881037 912698 3005 @@ -1203,32 +1206,41 @@ END; Aggregated Logging - With the option, the logs use a bit different format: + With the option, a different + format is used for the log files: -interval_start num_of_transactions latency_sum latency_2_sum min_latency max_latency lag_sum lag_2_sum min_lag max_lag skipped_transactions +interval_start num_transactions sum_latency sum_latency_2 min_latency max_latency sum_lag sum_lag_2 min_lag max_lag skipped - where interval_start is the start of the interval (Unix epoch - format time stamp), num_of_transactions is the number of transactions - within the interval, latency_sum is a sum of latencies - (so you can compute average latency easily). The following two fields are useful - for variance estimation - latency_sum is a sum of latencies and - latency_2_sum is a sum of 2nd powers of latencies. The next two - fields are min_latency - a minimum latency within the interval, and - max_latency - maximum latency within the interval. A transaction is - counted into the interval when it was committed. The fields in the end, - lag_sum, lag_2_sum, min_lag, + 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. + The next fields, + sum_lag, sum_lag_2, min_lag, and max_lag, are only present if the - Here is example output: + Here is some example output: 1345828501 5601 1542744 483552416 61 2573 1345828503 7884 1979812 565806736 60 1479 @@ -1238,9 +1250,9 @@ END; - Notice that while the plain (unaggregated) log file contains a reference - to the custom script files, the aggregated log does not. Therefore if - you need per script data, you need to aggregate the data on your own. + Notice that while the plain (unaggregated) log file shows which script + was used for each transaction, the aggregated log does not. Therefore if + you need per-script data, you need to aggregate the data on your own. -- cgit v1.2.3