percona-discussion team mailing list archive
-
percona-discussion team
-
Mailing list archive
-
Message #00547
Re: simple optimizations
Hi Mark, Vadim,
On 28/04/2009, at 10:58 PM, MARK CALLAGHAN wrote:
Have you seen this bug report?
http://bugs.mysql.com/bug.php?id=19975
Also, have you done any experiments with the page checksum method for
InnoDB to make it faster or to change the algorithm and I realize that
changing the algorithm has a huge impact on deployed servers. Once you
begin doing a lot of IO on fast SSD systems, you will burn a lot of
CPU time doing checksum validation.
Note in buf/buf0buf.c that the old checksum is still used as well as
the new.
Would it be possible to remove the old, at least?
And what is actually going on in include/ut0rnd.ic with the homegrown
foo?
ut_fold_binary() is the function used for generating the checksum.
What kind of bit errors does the homegrown stuff detect, how does it
hold up to say CRC in terms of catching problems, and computational
complexity/speed?
Look, if we were to change algorithms... CRCs can be optimised, and
there are I believe also newer algorithms that can be even less
computationally intensive.
But there's an additional issue with the whole checksum foo. The
checksum is right next to the data, and while CRCs are decent at
detecting corruption, the proximity can also hide some occurrances.
ZFS has the nifty trick of storing checksums separately, and I think
that's quite brilliant. Not saying it's easy to do for InnoDB or even
if it's desirable - just want to put it out there so we can discuss.
Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com)
Affordable Training and ProActive Support for MySQL & related
technologies
Follow our blog at http://openquery.com/blog/
OurDelta: free enhanced builds for MySQL @ http://ourdelta.org
Follow ups
References