Comment 5 for bug 1093385

I can confirm that using POSIX_FADV_NOREUSE with no range specified
generates more IO compared with the case when range is specified.

On my system with datafile ~886M Xtrabackup 2.0 reads ~980M, but with
ranges specified to only discard what we just read, this number becomes
~886M.

On Mon, Feb 24, 2014 at 3:36 PM, Launchpad Bug Tracker <
<email address hidden>> wrote:

> ** Branch linked: lp:~sergei.glushchenko/percona-xtrabackup/2.0-xb-
> bug1093385
>
> --
> You received this bug notification because you are a member of Percona
> core, which is subscribed to Percona XtraBackup.
> https://bugs.launchpad.net/bugs/1093385
>
> Title:
> xtrabackup 2.0 generates a lot of IO compared to 1.6
>
> Status in Percona XtraBackup:
> Triaged
> Status in Percona XtraBackup 2.0 series:
> Triaged
> Status in Percona XtraBackup 2.1 series:
> Triaged
> Status in Percona XtraBackup 2.2 series:
> Triaged
>
> Bug description:
> After a migration from XtraBackup 1.6.4 to 2.0.x we noticed that
> execution time for backups increased by a factor of ~2.5 on all the
> systems where was deployed (independently from the size from the
> backups, that could range from tens to hundreds of GB).
>
> ===
>
> How to reproduce:
>
> mkdir /data/rene_tmp
> cd /data/rene_tmp
> wget
> http://www.percona.com/redir/downloads/XtraBackup/XtraBackup-1.6.4/Linux/binary/x86_64/xtrabackup-1.6.4.tar.gz
> tar -zxf xtrabackup-1.6.4.tar.gz
>
> http://www.percona.com/redir/downloads/XtraBackup/XtraBackup-2.0.4/binary/Linux/x86_64/percona-xtrabackup-2.0.4-484.tar.gz
> tar -zxf percona-xtrabackup-2.0.4-484.tar.gz
>
> With 1.6.4:
> export
> PATH=/data/rene_tmp/xtrabackup-1.6.4/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/ec2/bin:/opt/iam/bin:/root/bin:/opt/ec2/bin:/opt/iam/bin
> xtrabackup-1.6.4/bin/innobackupex-1.5.1 --defaults-file /etc/my.cnf
> --user=root --password=XXXX --slave-info --stream=tar /data/mysql-tmp
> 2>/tmp/innobackupex-log > /dev/null
>
> With 2.0.4:
> export
> PATH=/data/rene_tmp/percona-xtrabackup-2.0.4/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/ec2/bin:/opt/iam/bin:/root/bin:/opt/ec2/bin:/opt/iam/bin
> percona-xtrabackup-2.0.4/bin/innobackupex-1.5.1 --defaults-file
> /etc/my.cnf --user=root --password=XXXX --slave-info --stream=tar
> /data/mysql-tmp 2>/tmp/innobackupex-log > /dev/null
>
> ===
>
> Attached are the output of "vmstat 10" and " iostat -k -d -x 10
> /dev/sd[fihg] " , for XtraBackup-1.6.4 and XtraBackup-2.0.4 .
>
> Note: all the instances are EC2 instances with EBS volumes configured
> on RAID10 . We noticed the same behavior with 4 or 8 EBS volumes, and
> with chunks of 64kB or 256kB
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/1093385/+subscriptions
>