相对于纳秒级的内存访问延时,普通的机械盘达到了毫秒级的随机访问延时,对于OLTP应用来说,物理IO绝对是目前数据库管理系统的最大性能杀手,所以增加内存的大小,提高IO的命中率无疑可以作为一种降低时延的常用优化手段。

    针对使用InnoDB引擎的MySQL实例来说,增加buffer pool的大小,尽可能的提高buffer pool的命中率,减少物理IO的概率,能极大的提升系统的吞吐量。

    但是,随着内存越来越大,面临着一个很严重的问题:当内存突然失效,或者实例异常crash后,面对相同的请求压力,或者突然的大压力,系统由于内存未命中会耗尽IO资源,并导致request响应变慢,形成雪崩效应。

    Warmup特性

    MySQL 5.6 Innodb提供了warmup的功能,并增加了三个控制参数:

    工作原理

    1. 当系统startup的时候,如果innodb_buffer_pool_load_at_startup=on,并且存在innodb_buffer_pool_file,会读取元信息,进行异步IO读取数据加载到buffer pool中。

    那么问题来了

    1. Warmup是否影响startup的速度:

      不影响.启动的时候,读取innodb_buffer_pool_file, 排序后,进行异步IO,不影响startup的速度。但现实的情况是:如果你是在业务高峰期出现crash,其实对于系统来说,先warmup后,再开放提供服务,更合适。

    2. dump是否导致系统抖动

      dump的过程,会持有mutex,扫描LRU链表,读取元数据,如果在系统业务高峰期,可能会产生抖动。 改进

    MySQL 5.7 又增强了warmup功能的使用:

    1. 控制load过程中,防止过量使用IO资源,如果单机多实例的情况下,同时启动实例,会使IO过载。