[mythtv-users] mythconverg_backup.pl inefficiencies

[Will Dormann]

On 11/19/15 8:49 AM, Will Dormann wrote:
> Got it.   So while the mythconverg_backup.pl script itself might take a
> long time, the database locking time is minimized.

Just out of curiosity, I ran some benchmarks by running mysqldump (with
the same params that mythconverg_backup.pl uses) to see if this is
actually the case.   I'm sure the answer is a big "it depends",
depending on: database size, CPU cores/speed, local disk speed, network
speed, etc.   But in my case:   (2.3GB mysql dump, 2-core ATOM, 7200RPM
SATA, 100Mbit)


mysqldump > NFS: 		7m6s
mysqldump | pigz > NFS: 	3m10s
mysqldump > localtmp:		5m45s
mysqldump | pigz > localtmp:    5m19s


These numbers represent the time that the mysql database will be locked
during backup with mythconverg_backup.pl execution.  Things that could
possibly be confusing to some:

1) Piping to pigz is faster than not running pigz at all
2) piping to pigz to a NFS share is faster than either option involving
the local disk

The answer to 1) is presumably the network bottleneck in my case, and
the answer to 2) is presumably the disk contention caused by reading
from and writing to the same spinning platters.

Now when you consider the total time that it takes to run
mythconverg_backup.pl (which takes into account compressing the dump in
a separate step) as opposed to just the time that the database will be
locked, the options that don't do inline compression will be even slower.

So at least with my setup, inline piping to pigz is the only option that
makes sense.


-WD