pt-mysql-summary : bad size of transaction logs

Reported by Frederic Descamps on 2012-02-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Toolkit
Undecided
Daniel Nichter
2.0
Undecided
Daniel Nichter
2.1
Undecided
Daniel Nichter

Bug Description

The output of pt-mysql-summary displays wrong value in calculation for InnoDB log files:

       Log File Size | 2 * 1G = 2.9G

in my.cnf:

innodb_log_file_size = 1500M

mysql> show global variables like 'innodb_log_file%';
+---------------------------+------------+
| Variable_name | Value |
+---------------------------+------------+
| innodb_log_file_size | 1572864000 |
| innodb_log_files_in_group | 2 |
+---------------------------+------------+

tags: added: pt-mysql-summary wrong-output
Changed in percona-toolkit:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Brian Fraser (fraserbn)
milestone: none → 2.0.4
Daniel Nichter (daniel-nichter) wrote :

The real value is/should be 3_145_728_000, or 3.1G.

Brian Fraser (fraserbn) wrote :

Code fixed in 2.0.4, but we weren't able to test it properly because pt-mysql-summary conflates gathering data and reporting it, and the only way to get it right would be to create a 1.5GB log file for the test. In 2.1.x, pt-mysql-summary will get a reorganization, so tests for this fix will go there.

Changed in percona-toolkit:
status: Confirmed → Fix Committed
Brian Fraser (fraserbn) on 2012-03-03
Changed in percona-toolkit:
status: Fix Committed → In Progress
Brian Fraser (fraserbn) on 2012-03-07
Changed in percona-toolkit:
status: In Progress → Fix Committed
Daniel Nichter (daniel-nichter) wrote :

Not fixed yet, so I have untargeted from 2.0.4 so the release may proceed.

Changed in percona-toolkit:
status: Fix Committed → In Progress
milestone: 2.0.4 → none
Daniel Nichter (daniel-nichter) wrote :

Turns out, "Log File Size | 2 * 1G = 2.9G" is correct. Here's the comment that's now in shorten():

   # By default Mebibytes (MiB), Gigibytes (GiB), etc. are used because
   # that's what MySQL uses. This may create odd output for values like
   # 1500M * 2 (bug 937793) because the base unit is MiB but the code
   # see 1,572,864,000 * 2 = 3,145,728,000 which is > 1 GiB so it uses
   # GiB as the unit, resulting in 2.9G instead of 3.0G that the user
   # might expect to see. There's no easy way to determine that
   # 3,145,728,000 was actually a multiple of MiB and not some weird GiB
   # value to begin with like 3.145G. The Perl lib Transformers::shorten()
   # uses MiB, GiB, etc. too.

Daniel Nichter (daniel-nichter) wrote :

See bug 993436 for a fixed version of shorten().

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers