数据库内核月报

数据库内核月报 - 2020 / 09

MySQL · 性能优化 · PageCache优化管理

Author: 子堪

背景

监控线上实例时,曾出现可用内存不足,性能发生抖动的情况。研究后发现是日志文件的page cache占用了大量的内存(200G+),导致系统可立即分配的内存不足,影响了系统性能。

查看linux内核文档发现,操作系统在内存的使用未超过上限时,不会主动释放page cache,以求达到最高的文件访问效率;当遇到较大的内存需求,操作系统会当场淘汰一些page cache以满足需求。由于page cache的释放较为费时,新的进程不能及时得到内存资源,发生了阻塞。

据此,考虑能否设计一个优化,在page cache占据大量内存前,使用linux内核中提供的posix_fadvise等缓存管理方法,由Mysql主动释放掉无用的page cache,来缓解内存压力。本文先介绍文件的page cache机制,并介绍应用程序级的管理方法,最后介绍针对Mysql日志文件的内存优化。

Page Cache机制

页面缓存(Page Cache)是Linux内核中针对文件I/O的一项优化,Linux从内存中划出了一块区域来缓存文件页,如果要访问外部磁盘上的文件页,首先将这些页面拷贝到内存中,再进行读写。由于硬件结构限制,磁盘的I/O速度比内存慢很多,因此使用Page cache能够大大加速文件的读写速度。

Page Cache的机制如上图所示,具体来说,当应用程序读文件时,系统先检查读取的文件页是否在缓存中;如果在,直接读出即可;如果不在,就将其从磁盘中读入缓存,再读出。此时如果内存有足够的内存空间,该页可以在page cache中驻留,其他进程再访问该部分数据时,就不需要访问磁盘了。

同样,在写文件之前,系统先检查对应的页是否已经在缓存中;如果在,就直接将数据写入page cache,使其成为脏页(drity page)等待刷盘;如果不在,就在缓存中新增一个页面并写入数据(这一页面也是脏页)。真正的磁盘I/O会由操作系统调用fsync等方法来实现,这一调用可以是异步的,保证磁盘I/O不影响文件读写的效率。 在Mysql中,我们说的写文件(write)通常是指将数据写入page cache中,而刷盘或落盘(fsync)才真正将数据写入磁盘中的文件。

程序将数据写入page cache后,可以主动进行刷脏(如调用fsync),也可以放手不管,等待内核帮忙刷脏。在linux内核中,有关自动刷脏的参数如下。

dirty_background_ratio
// 触发文件系统异步刷脏的脏页占总可用内存的最高百分比,当脏页占总可用内存的比例超过该值,后台回写进程被触发进行异步刷脏。

dirty_ratio
// 触发文件系统同步刷脏的脏页占总可用内存的最高百分比,当脏页占总可用内存的比例超过该值,生成新的写文件操作的进程会先执行刷脏。

dirty_background_bytes & dirty_bytes
// 上述两种刷脏条件还可通过设置最高字节数而非比例触发。如果设置bytes版本,则ratio版本将变为0,反之亦然。

dirty_expire_centisecs
// 这个参数指定了脏页多长时间后会被周期性刷脏。下次周期性刷脏时,脏页存活时间超过该值的页面都将被刷入磁盘。

dirty_writeback_centisecs 
// 这个参数指定了多长时间唤醒一次刷脏进程,检查缓存并刷下所有可以刷脏的页面。该参数设为零内核会暂停周期性刷脏。

Page Cache默认由系统调度分配,当free的内存高于内核的低水位线(watermark[WMARK_MIN])时,系统会尽量让用户充分使用缓存,因为它认为这样内存的利用效率最高;当低于低水位线时,就按照LRU的顺序回收page cache。正是这种策略,使得内存的free的部分越来越小,cache的部分越来越大,造成了文章开头提到的问题。

实际上,Mysql中许多文件有着固定的访问模式,它们的页面不会被短时间内多次访问,例如redo log和binlog文件。在实例正常运行的状态下,Redo log只是持久化每次操作的物理日志,写入文件后就没有读操作;binlog文件在写入后,也只会被dump线程所访问。

Page Cache监控与管理

vmtouch

vmtouch工具可以用来查看指定文件page cache使用情况,也可以手动将文件换入或换出缓存。下面是其常用功能的使用方法

# 显示文件的page cache使用情况
$ vmtouch -v [filename]

# 换出文件的page cache
# 即使换出成功,内核也可能在vmtouch命令完成时将页面分页回内存。
$ vmtouch -ve [filename]

# 换入文件的page cache
# 保证文件的page cache都换入内存,但是在vmtouch命令完成时,该页面可能被内核逐出
$ vmtouch -vt [filename]

posix_fadvise

posix_fadvise是linux上控制页面缓存的系统函数,应用程序可以使用它来告知操作系统,将以何种模式访问文件数据,从而允许内核执行适当的优化。其中一些建议可以只针对文件的指定范围,文件的其他部分不生效。 这一函数对内核提交的是建议,在特殊情况下也可能不会被内核所采纳。

函数在内核的mm/fadvise.c中实现,函数的声明如下:

SYSCALL_DEFINE(fadvise64_64)(int fd, loff_t offset, loff_t len, int advice)

其中fd是函数句柄;offset是建议开始生效的起始字节到文件头的偏移量;len是建议生效的字节长度,值为0时代表直到文件末尾;advice是应用程序对文件页面缓存管理的建议,共有六种合法建议。下面根据代码,对六种建议进行分析。

switch (advice) {    
    /*
    该文件未来的读写模式位置,应用程序没有关于page cache管理的特别建议,这是advice参数的默认值
    将文件的预读窗口大小设为下层设备的默认值
    */
    case POSIX_FADV_NORMAL:
        file->f_ra.ra_pages = bdi->ra_pages;
        spin_lock(&file->f_lock);
        file->f_mode &= ~FMODE_RANDOM;
        spin_unlock(&file->f_lock);
        break;
    
    /* 该文件将要进行随机读写,禁止预读 */
    case POSIX_FADV_RANDOM:
        spin_lock(&file->f_lock);
        file->f_mode |= FMODE_RANDOM;
        spin_unlock(&file->f_lock);
        break;
    
    /*
    该文件将要进行顺序读写操作(从文件头顺序读向文件尾)
    将文件的预读窗口大小设为默认值的两倍
    */
    case POSIX_FADV_SEQUENTIAL:
        file->f_ra.ra_pages = bdi->ra_pages * 2;
        spin_lock(&file->f_lock);
        file->f_mode &= ~FMODE_RANDOM;
        spin_unlock(&file->f_lock);
        break;
    
    /* 该文件只会被访问一次,收到此建议时,什么也不做 */    
    case POSIX_FADV_NOREUSE:
        break;
    
    /* 该文件将在近期被访问,将其换入缓存中 */
    case POSIX_FADV_WILLNEED:
        ...
        ret = force_page_cache_readahead(mapping, file,
                                         start_index,
                                         nrpages);
        ...
        break;
    
    /* 该文件在近期内不会被访问,将其换出缓存 */
    case POSIX_FADV_DONTNEED:
        if (!bdi_write_congested(mapping->backing_dev_info))
            __filemap_fdatawrite_range(mapping, offset, endbyte,
                                       WB_SYNC_NONE);
        ...
        if (end_index >= start_index)
            invalidate_mapping_pages(mapping, start_index,
                                     end_index);
        break;
    default:
        ret = -EINVAL;
}

针对POSIX_FADV_NORMAL,POSIX_FADV_RANDOM和POSIX_FADV_SEQUENTIAL这三个建议,内核会对文件的预读窗口大小做调整,具体调整策略见代码注释。这些建议的影响范围是整个文件(无视offset和len参数),但不影响该文件的其他句柄。针对POSIX_FADV_WILLNEED和POSIX_FADV_DONTNEED,内核会尝试直接对page cache做调整,这里不是强制的换入或换出,内核会根据情况采纳建议。

当建议为POSIX_FADV_WILLNEED时,内核调非阻塞读force_page_cache_readahead方法,将数据页换入缓存。这里根据内存负载的情况,内核可能会减少读取的数据量。

当建议为POSIX_FADV_DONTNEED时,内核先调用fdatawrite将脏页刷盘。这里刷脏页用的参数是非同步的WB_SYNC_NONE。刷完脏后,会调用invalidate_mapping_pages清除相关页面,该函数在mm/truncate.c中实现,代码如下。

unsigned long invalidate_mapping_pages(struct address_space *mapping,
        pgoff_t start, pgoff_t end)
{
    ...
    while (index <= end && pagevec_lookup(&pvec, mapping, index,
            min(end - index, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
        mem_cgroup_uncharge_start();
        for (i = 0; i < pagevec_count(&pvec); i++) {
            ...
            ret = invalidate_inode_page(page);
            ...
        }
        ...
    }
    return count;
}

int invalidate_inode_page(struct page *page)
{
    struct address_space *mapping = page_mapping(page);
    if (!mapping)
        return 0;
    if (PageDirty(page) || PageWriteback(page))
        return 0;
    if (page_mapped(page))
        return 0;
    return invalidate_complete_page(mapping, page);
}

可以看到,invalidate_mapping_pages调用了下层函数invalidate_inode_page,其中的判断逻辑是,如果页脏或页正在写回,则什么也不做;如果没有映射关系或页不再缓存中,则什么也不做。所以这里内核只会尽力而为,清除掉自己能清除的缓存,而不会等待刷脏完成后再清除文件的全部缓存。

因此,在使用POSIX_FADV_DONTNEED参数清除page cahce时,应当先执行fsync将数据落盘,这样才能确保page cache全部释放成功。posix_fadvise函数包含于头文件fcntl.h中,清除一个文件的page cache的方法如下:

#include <fcntl.h>
#include <unistd.h>
...
fsync(fd);
int error = posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
...

posix_fadvise成功时会返回0,失败时可能返回的error共有三种,分别是

EBADF  // 参数fd(文件句柄)不合法,值为9

EINVAL // 参数advise不是六种合法建议之一,值为22

ESPIPE // 输入的文件描述符指向了管道或FIFO,值为29

Mysql日志优化策略

Mysql中不同文件有着不同的访问行为,日志文件是一种顺序读写占绝大多数的文件,因此我们可以为binlog和redo log设计相应的管理策略,来清除暂时不会使用的page cache。

Page cache是系统资源,不属于某个进程管理,因此无法通过进程内存使用的情况来观察优化效果。我们可以使用vmtouch工具来查看page cache的使用情况。

Redo log

在Innodb层,Redo log的主要职责是数据持久化,实现先写日志再写数据的WAL机制。Redo log文件大小和个数固定,由innodb_log_file_size和innodb_log_files_in_group参数控制,这些文件连在一起,被Innodb当成一个整体循环使用。

Redo log写page cache和刷盘分别由线程log_writer和log_flusher异步执行,8.0版本中还实现了写log buffer的无锁化,其具体可参见往期月报:http://mysql.taobao.org/monthly/2019/02/05/

在正常运行的实例中,redo log只有写操作。在写入某个文件的某页后,需要较长的一段时间log_flusher才会再次推进到该页,因此无需保留page cache。

Redo Log的刷盘由log_flusher线程异步执行,因此可以将page cache的释放操作放在log_flusher线程上,每次flush刷脏后执行。这样每次需要释放的page cache较少,耗时较短;

Binlog

在mysql实例正常运行过程中,binlog主要用来做主从复制。Binlog文件的大小由参数max_binlog_size指定,数量没有限制。Binlog的刷盘由参数sync_binlog控制,当sync_binlog为0的时候,刷盘由操作系统负责,异步执行;当不为0的时候,其数值为定期sync磁盘的binlog commit group数,由主线程同步执行刷盘。

没有从库挂载时,binlog只有写操作,保留page cache意义不大。sync_binlog大于0时,刷盘操作以事务为单位,在主线程中拿LOCK_log锁同步执行,如果在每次刷盘后进行fadvise,会阻塞较多的主线程。

因此,将page cache的释放延后到rotate执行,即在关闭旧文件并且成功开启新文件,放掉LOCK_log锁后,释放旧文件的page cache。这样,fadvise操作只会阻塞负责rotate的线程,不会影响到其他线程(因为其他线程都在新的binlog文件中操作)。Rotate执行过程中会调用sync方法刷脏,因此在rotate后释放page cache无需提前刷脏。

有从库挂载时,每次binlog刷盘后,会有dump线程来读取binlog文件的更新,并将更新内容发送到从库。当binlog文件的最后写入位置与dump线程的读取位置比较近(如相距3个文件以内)时,在dump线程读完binlog后再释放page cache效率较高,因为dump可以从page cache中读到更新内容,无需磁盘I/O。这种情况下,将page cache的释放延后到dump线程rotate成功后执行。Dump线程切换binlog时,旧文件已被主线程刷脏,而dump线程只会做读操作,因此不会产生脏页,释放page cache前无需再次刷脏。

测试

测试机规格:96core,750GB memory 设置binlog的大小为1GB,redo log的大小为1GB,数量为10个;设置innodb_flush_log_at_trx_commit和sync_binlog为双1。使用sysbench工具进行压测,线程数为128,模式为OLTP_read_write,结果如下图所示。 上面两个图分别是有从库挂载和没有从库挂载时的性能测试结果,蓝色曲线是不加page cache优化时的QPS折线图,橙色曲线是加page cache优化时的QPS折线图。可以发现,释放page cache的优化基本不会导致性能的下降。使用write only模式sysbench压测也无明显性能损失,这里不再展开叙述。

使用vmtouch工具测试page cache释放的速度,如上图所示。在测试机上清理实例写满的1GB的redo log file的page cache约耗时0.28秒。

上面两个图是无从库挂载,无page cache优化时,压测300s后data文件夹的cache使用情况和系统的内存使用情况统计。使用vmtouch命令查看实例的data文件夹,可以看到不使用优化时,cache激增到20G。使用free命令查看系统内存的使用情况,发现大部分的内存被cache占用,比free的部分多6.8倍。

上面两个图是有page cache优化时,压测300s后内存的使用情况。可以看到,使用优化后,实例的data文件夹使用cache的大小显著减小。使用free命令,发现减少的cache全部计入了free中,可以被自由使用。

挂载从库进行同样的测试,可得到相同的结论。

总结

系统对page cache的管理,在一些情况下可能有所欠缺,我们可以通过内核提供的posix_fadvise予以干预。在几乎不损失性能的前提下,可以通过主动释放Mysql日志文件的page cache的方法,达到减缓内存压力的目的。对于极端内存需求的场景,这一优化能够很好的预防性能抖动的发生。