MySQL8.0 - 新特性 - 说说InnoDB Log System的隐藏参数

InnoDB在设计lock-free的log system时，除了已有的参数外，还经过宏控制隐藏了一些参数，若是你使用源码编译时，打开cmake选项-DENABLE_EXPERIMENT_SYSVARS=1, 就能够看到这些参数了。本文主要简单的过一下这些隐藏的参数所表明的含义

A.
innodb_log_write_events
innodb_log_flush_events
二者的含义相似，表示用来唤醒等待log write/flush的event的个数，默认值都是2048
好比你要等待的位置在lsnA，那么计算的slot为:
slot = (lsnA - 1) /OS_FILE_LOG_BLOCK_SIZE & (innodb_log_write/flush_events - 1)
这意味着：若是事务的commit log的end lsn落在相同block里，他们可能产生event的竞争
固然若是不在同一个block的时候，若是调大参数，就能够减小竞争，但也会有无效的唤醒
唤醒操做一般由后台线程log_write_notifier 或者log_flush_notifier异步来作，但若是推动的log write/flush还不足一个block的话，那就log_writter/flusher
本身去唤醒了。

B.
innodb_log_recent_written_size, 默认1MB
表示recent_written这个link_buf的大小，其实控制了并发往log buffer中同时拷贝的事务日志量，向前由新的日志加入，后面由log writer经过写日志向前推动，若是写的慢的话，那这个link_buf极可能用满，用户线程就得spin等待。再慢io的系统上，咱们能够稍微调大这个参数

innodb_Log_recent_closed_size, 默认2MB
表示recent closed这个link_buf的大小，也是维护能够并发往flush list上插入脏页的并罚度，若是插入脏页速度慢，或者lin_buf没有及时合并推动，就会spin wait

简单说下link_buf, 这本质上是一个数组，但使用无锁的使用方式来维护lsn的推动，好比得到一个lsn开始和结束，那就
经过设置buf[start_lsn] = end_lsn的相似方式来维护lsn链，基于lsn是连续值的事实，最终必然不会出现空洞，因此在演化的过程当中，能够从尾部
推动连续的lsn，头部插入新的值.
若是新插入的值超过了尾部，表示buf满了，就须要spin wait了

C.
innodb_log_wait_for_write_spin_delay， 
innodb_log_wait_for_write_timeout

从8.0版本开始用户线程再也不本身去写redo，而是等待后台线程去写，这两个变量控制了spin以及condition wait的timeout时间，当spin一段时间还没推动到某个想要的lsn点时，就会进入condition wait

另外两个变量
innodb_log_wait_for_flush_spin_delay
innodb_log_wait_for_flush_timeout
含义相似，可是是等待log flush到某个指定lsn

注意在实际计算过程当中，最大spin次数，会考虑到cpu利用率，以及另外两个参数:
innodb_log_spin_cpu_abs_lwm
innodb_log_spin_cpu_pct_hwm

若是是等待flush操做的话，还收到参数innodb_log_wait_for_flush_spin_hwm限制，该参数控制了等待flush的时间上限，若是平均等待flush的时间超过了这个上限的话, 就不必去spin，而是直接进入condition wait

关于spin次数的计算方式在函数log_max_spins_when_waiting_in_user_thread中":

函数的参数即为配置项innodb_log_wait_for_write_spin_delay或innodb_log_wait_for_flush_spin_delay值

static inline uint64_t log_max_spins_when_waiting_in_user_thread(
    uint64_t min_non_zero_value) {
  uint64_t max_spins;

  /* Get current cpu usage. */
  const double cpu = srv_cpu_usage.utime_pct;

  /* Get high-watermark - when cpu usage is higher, don't spin! */
  const uint32_t hwm = srv_log_spin_cpu_pct_hwm;

  if (srv_cpu_usage.utime_abs < srv_log_spin_cpu_abs_lwm || cpu >= hwm) {
    /* Don't spin because either cpu usage is too high or it's
    almost idle so no reason to bother. */
    max_spins = 0;

  } else if (cpu >= hwm / 2) {
    /* When cpu usage is more than 50% of the hwm, use the minimum allowed
    number of spin rounds, not to increase cpu usage too much (risky). */
    max_spins = min_non_zero_value;

  } else {
    /* When cpu usage is less than 50% of the hwm, choose maximum spin rounds
    in range [minimum, 10*minimum]. Smaller usage of cpu is, more spin rounds
    might be used. */
    const double r = 1.0 * (hwm / 2 - cpu) / (hwm / 2);

    max_spins =
        static_cast<uint64_t>(min_non_zero_value + r * min_non_zero_value * 9);
  }

  return (max_spins);
}

D. 如下几个参数是后台线程等待任务时spin及condition wait timeout的值
log_writer线程：
innodb_log_writer_spin_delay,
innodb_log_writer_timeout

log_flusher线程：
innodb_ log_flusher_spin_delay
innodb_log_flusher_timeout

log_write_notifier线程：
innodb_ log_write_notifier_spin_delay
innodb_log_write_notifier_timeout

log_flush_notifier线程
innodb_log_flush_notifier_spin_delay
innodb_log_flush_notifier_timeout

log_closer线程（用于推动recent_closed这个link_buf的专用线程）
innodb_log_closer_spin_delay
innodb_log_closer_timeout

E
innodb_ log_write_max_size
表示容许一个write操做最大的字节数，默认为4kb， 这个是在推动recent_written这个link buf时计算的，我的认为这个限制过小了，能够适当调大这个参数。（然而8.0的最大写入限制还受到innodb_log_write_ahead_size限制，二者得综合起来看）

F
innodb_log_checkpoint_every
默认1000毫秒（1秒），表示至少每隔这么长时间log_checkpointer线程会去尝试作一次checkpoint. 固然是否作checkpoint还受到其余因素的影响，具体见函数log_should_checkpoint:

a) more than 1s elapsed since last checkpoint
b) checkpoint age is greater than max_checkpoint_age_async
c) it was requested to have greater checkpoint_lsn,
             and oldest_lsn allows to satisfy the request

G. 参考：
MySQL8.0.16源代码

原文连接 本文为云栖社区原创内容，未经容许不得转载。