关于InnoDB中buf_page_is_corrupted的优化

本文探讨InnoDB中buf_page_is_corrupted函数的工作原理及优化方法。该函数用于检查页数据的完整性。Percona版对其进行了改进,通过调整ut_fold_binary函数的步进来提升效率。在64位系统上,进一步的优化可以减少计算时间。
部署运行你感兴趣的模型镜像

函数buf_page_is_corrupted (innodb_plugin/buf/buf0buf.c)这个函数,是在InnoDB中获取page数据后,对page作校验,判断内容是否损坏。

在压力测试中发现,innodb.so最耗费cpu的就是这个buf_page_is_corrupted

       Percona对这个函数作了优化。本文介绍与此有关的配置、优化原理以及进一步的优化空间。(当前版本5.1.48 innodb-plugin 1.0.9)

1、函数主流程

每个page头部的前四个字节是本pagechecksum page写入时计算得到。因此函数主流程如下:

a)        读前四个字节得到checksum_field

b)        page重新计算checksum, buf_calc_page_new_checksum(read_buf)

c)        ab的结果相同则认为page未损坏。

 

2、              函数瓶颈

              显然函数主要计算时间在buf_calc_page_new_checksum中,后者直接调用ut_fold_binary(实现位置 ./include/ut0rnd.ic)。我们来看这个ut_fold_binary的函数实现:

UNIV_INLINE
ulint
ut_fold_binary(
/*===========*/
        const byte*     str,    /*!< in: string of bytes */
        ulint           len)    /*!< in: length */
{
        const byte*     str_end = str + len;
        ulint           fold = 0;
        ut_ad(str || !len);
        while (str < str_end) {
                fold = ut_fold_ulint_pair(fold, (ulint)(*str));
                str++;
        }   
        return(fold);
}

  

 

 

说明:其中ut_fold_ulint_pair的第二个参数表明,在该函数中,是以一个uint方式使用的(如下)。该函数在同一个文件中,通过两个uint的异或和移位得到返回值。但在第13行中的str++ 使得每个字节都被使用了4次。

ut_fold_ulint_pair(
/*===============*/
        ulint   n1,     /*!< in: ulint */
        ulint   n2)     /*!< in: ulint */
{
        return(((((n1 ^ n2 ^ UT_HASH_RANDOM_MASK2) << 8) + n1)
                ^ UT_HASH_RANDOM_MASK) + n2);
}

 

 

      

3、              优化

Percona版本的改进中,将实现了一个新的函数ut_fold_ulint_pair_32, 将步进修改为4个字节。

实际上,将16k数据签名成4个字节,使用前后两种方法的信息损失是相同的,因此优化版本概率上并不损失准确性。

 

64位机器上,若每次直接取两个unsigned longut_fold_ulint_pair操作(当然需要为此写一个ut_fold_ulint_pair_64函数),计算速度相同,但步进长度加倍,能够进一步优化此函数性能。

代码上需要作如下修改

a)        ./include/ut0rnd.ic ./include/ut0rnd.h 中增加ut_fold_binary_64的定义和声明

b)        buf/buf0buf.c中增加buf_calc_page_new_checksum_64, 并在buf_page_is_corrupted增加调用

c)        buf_flush_init_for_writing(buf/buf0flu.c)中,写入page前换用buf_calc_page_new_checksum_64得到checksum

 

4、              测试结果

sysbench作压力,并计算三种buf_calc_page_new_checksum的平均执行时间。得益于神器SystemTap,不需要再另外统计时间的代码(痛苦回忆中)

函数

平均执行时间

buf_calc_page_new_checksum

65ms

buf_calc_page_new_checksum_32

24ms

buf_calc_page_new_checksum_64

16ms

             

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型,相比 3.0 版本,它提升了图像质量、运行速度和硬件效率

InnoDB: Assertion failure in thread 140369212495616 in file log0recv.cc line 2097 InnoDB: Failing assertion: !page || (ibool)!!page_is_comp(page) == dict_table_is_comp(index->table) InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 02:55:51 UTC - xtrabackup got signal 6 ; This could be because you hit a bug or data is corrupted. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0 thread_stack 0x10000 innobackupex(my_print_stacktrace+0x35)[0xda1de5] innobackupex(handle_fatal_signal+0x273)[0xbb0313] /lib64/libpthread.so.0(+0xf630)[0x7faa45dcc630] /lib64/libc.so.6(gsignal+0x37)[0x7faa44118387] /lib64/libc.so.6(abort+0x148)[0x7faa44119a78] innobackupex[0x75f7df] innobackupex[0x8dd07f] innobackupex(_Z22recv_recover_page_funcmP11buf_block_t+0x867)[0x8de657] innobackupex(_Z20buf_page_io_completeP10buf_page_tb+0x44d)[0x8d4e0d] innobackupex(_Z12fil_aio_waitm+0xe2)[0x8f20a2] innobackupex(io_handler_thread+0x30)[0x9d9f70] /lib64/libpthread.so.0(+0x7ea5)[0x7faa45dc4ea5] /lib64/libc.so.6(clone+0x6d)[0x7faa441e0b0d] 增量报错
最新发布
08-29
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值