Innodb: 自动开启打印show engine status到err日志

简介: 这个问题是一个朋友问我的@刘加奇一、问题描述为什么我的err日志里面有大量的show engine innodb status的记录,我自己并没有开启innodb_status_output参数。

这个问题是一个朋友问我的@刘加奇

一、问题描述

为什么我的err日志里面有大量的show engine innodb status的记录,我自己并没有开启innodb_status_output参数。

二、问题分析

通过查看日志,发现如下输出:

2019-03-21T17:00:02.375231Z 1230497 [Warning] InnoDB: Difficult to find free blocks in the buffer pool (338 
search iterations)! 0 failed attempts to flush a page! Consider increasing the buffer pool size. It is also possible 
that in your Unix version fsync is very slow, or completely frozen inside the OS kernel. Then upgrading to a 
newer version of your operating system may help. Look at the number of fsyncs in diagnostic info below. 
Pending flushes (fsync) log: 0; buffer pool: 0. 1446962050 OS file reads, 545881917 OS file writes, 
376257282 OS fsyncs. Starting InnoDB Monitor to print further diagnostics to the standard output.

日志也写得很清楚。应该是free block不够了Innodb自动开启了。但是我们需要源码验证一下。

三、源码验证

在源码的buf_LRU_handle_lack_of_free_blocks函数中我们看到如下:

if ((current_ms > started_ms + 2000)
        && (current_ms > last_printout_ms + 2000)
        && srv_buf_pool_old_size == srv_buf_pool_size) {

        ib::warn() << "Difficult to find free blocks in the buffer pool"
            " (" << n_iterations << " search iterations)! "
               << flush_failures << " failed attempts to"
            " flush a page! Consider increasing the buffer pool"
            " size. It is also possible that in your Unix version"
            " fsync is very slow, or completely frozen inside"
            " the OS kernel. Then upgrading to a newer version"
            " of your operating system may help. Look at the"
            " number of fsyncs in diagnostic info below."
            " Pending flushes (fsync) log: "
               << fil_n_pending_log_flushes
               << "; buffer pool: "
               << fil_n_pending_tablespace_flushes
               << ". " << os_n_file_reads << " OS file reads, "
               << os_n_file_writes << " OS file writes, "
               << os_n_fsyncs
               << " OS fsyncs. Starting InnoDB Monitor to print"
            " further diagnostics to the standard output.";

        last_printout_ms = current_ms;
        *mon_value_was = srv_print_innodb_monitor;
        *started_monitor = true;
        srv_print_innodb_monitor = true;
        os_event_set(srv_monitor_event);

这里不仅打印出了日志同时设置了参数srv_print_innodb_monitor = true; 并且开始os_event_set(srv_monitor_event);开启了monitor打印线程。那我们看看srv_print_innodb_monitor 对应什么参数呢。如下:

static MYSQL_SYSVAR_BOOL(status_output, srv_print_innodb_monitor,
  PLUGIN_VAR_OPCMDARG, "Enable InnoDB monitor output to the error log.",
  NULL, innodb_status_output_update, FALSE);

实际上就是innodb_status_output被自动开了。当然如果查看调用可以在上层函数buf_LRU_get_free_block中查看到调用,实际上就是在free list找不到空闲的block的时候会做输出。buf_LRU_get_free_block还包含了一个块的分配流程大约如下,可自行参考:

  • If there is a block in the free list, take it .如果这里找不到就会自动开启innodb_status_output
  • If no block was in the free list, search from the end of the LRU list and try to free a block there.
  • No free block was found: try to flush the LRU list.

作者微信:gp_22389860

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
4月前
|
存储 SQL 关系型数据库
MySQL之深入InnoDB存储引擎——redo日志
我们知道数据的修改首先是在Buffer Pool中进行的,之后再定时刷到磁盘中。那么如果在事务提交后还没刷新到磁盘中,系统就崩溃了,那么此时数据就丢失了,这就不满足事务的持久性了。而如果我们考虑每次提交之后,都同步将事务中所有的页面刷新到磁盘,这样确实可以保证持久性,但是这种方法存在以下两种问题:
|
6月前
|
关系型数据库 MySQL 数据库
阿里云Mysql数据库物理全备文件恢复到自建数据库Mysql报错:InnoDB: Log file ./...xtrabacku
阿里云Mysql数据库物理全备文件恢复到自建数据库Mysql报错:InnoDB: Log file ./...xtrabacku
|
11月前
|
SQL NoSQL 安全
Percona 8.0.30中"show engine innodb status"导致coredump排查及分析
Percona 8.0.30中"show engine innodb status"导致coredump排查及分析
|
SQL 关系型数据库 MySQL
MySQL中ENGINE=InnoDB、AUTO_INCREMENT的意思
MySQL中ENGINE=InnoDB、AUTO_INCREMENT的意思
|
存储 关系型数据库 MySQL
InnoDB存储引擎的redo log(重做日志)
InnoDB存储引擎的redo log(重做日志)
85 0
InnoDB存储引擎的redo log(重做日志)
|
监控 算法 安全
MySQL:5.6 大事务show engine innodb status故障一例
MySQL:5.6 大事务show engine innodb status故障一例
172 0
MySQL:5.6 大事务show engine innodb status故障一例
|
关系型数据库
InnoDB redo log thread cpu usage
InnoDB 在8.0 里面把写redo log 角色的各个线程都独立出来, 每一个thread 都处于wait 状态, 同样用户thread 调用log_write_up_to 以后, 也会进入wait 状态.这里的wait 等待最后都是通过调用 os_event_wait_for 来实现, 而 os_event_wait_for 是先spin + wait 的方式实现.所以这里有两个参数会影响os_event_wait_for 函数:spins_limit,timeout.
111 0
|
存储 SQL 缓存
InnoDB之UNDO LOG介绍
undo log是InnoDB事务特性的重要组成部分。当对记录做增删改操作就会产生undo记录,undo记录会记录到单独的表空间中。 本文将从代码层面对undo log进行一个简单的介绍;主要从下面四个方面来介绍undo log:undo log组织形式与分配与记录,以及undo log的应用及其清理。从这四个方面出发,我们就可以基本了解undo log的整个生命周期。
640 1
|
存储 运维 关系型数据库
庖丁解InnoDB之Undo LOG
Undo Log是InnoDB十分重要的组成部分,它的作用横贯InnoDB中两个最主要的部分,并发控制(Concurrency Control)和故障恢复(Crash Recovery),InnoDB中Undo Log的实现亦日志亦数据。本文将从其作用、设计思路、记录内容、组织结构,以及各种功能实现等方面,整体介绍InnoDB中的Undo Log,文章会深入一定的代码实现,但在细节上还是希望用抽象的实现思路代替具体的代码。本文基于MySQL 8.0,但在大多数的设计思路上MySQL的各个版本都是一致的。
355 3
|
存储 缓存 安全
庖丁解InnoDB之REDO LOG
磁盘数据库为了在保证数据库的原子性(A, Atomic) 和持久性(D, Durability)的同时,还能以灵活的刷盘策略来充分利用磁盘顺序写的性能,会记录REDO和UNDO日志,即ARIES方法。本文将重点介绍REDO LOG的作用,记录的内容,组织结构,写入方式等内容,希望读者能够更全面准确的理解REDO LOG在InnoDB中的位置。本文基于MySQL 8.0代码。
921 1

热门文章

最新文章