Linux系统中的page cache和buffer cache的概念、机制及kafka、redis等产品如何利用page cache1 page cache & buffer cache

1 page cache & buffer cache

1.1 概念

Page cache缓存文件的页以优化文件IO。

Buffer cache缓存块设备的块以优化块设备IO。

页是逻辑上的概念，因此page cache是与文件系统同级的；块是物理上的概念，因此buffer cache是与块设备驱动程序同级的。

• 在Linux 2.4版本的内核之前，page cache与buffer cache是完全分离的。但是，块设备大多是磁盘，磁盘上的数据又大多通过文件系统来组织，这种设计导致很多数据被缓存了两次，浪费内存。
• 在2.4版本内核之后，两块缓存近似融合在了一起：如果一个文件的页加载到了page cache，那么同时buffer cache只需要维护块指向页的指针就可以了。只有那些没有文件表示的块，或者绕过了文件系统直接操作（如dd命令）的块，才会真正放到buffer cache里。因此，我们现在提起page cache，基本上都同时指page cache和buffer cache两者，本文之后也不再区分，直接统称为buffer cache。

无论如何内核要对块设备执行基于块的IO而不是虚拟内存page。由于绝大部分的块表示文件的数据部，所以大部分的buffer cache都可由page cache表达，但是有少量的比如文件元数据仍然是保留在buffer cache中来缓存。

1.1.1 Page Cache(页缓存)

• 由内存中的物理page组成，其内容对应磁盘上的block。
• page cache的大小是动态变化的。
• backing store:cache缓存的存储设备
• 一个page通常包含多个block, 而block不一定是连续的。

读Cache

• 当内核发起一个读请求时, 先会检查请求的数据是否缓存到了page cache中。
  • 如果有，那么直接从内存中读取，不需要访问磁盘, 此即 cache hit(缓存命中)
  • 如果没有, 就必须从磁盘中读取数据, 然后内核将读取的数据再缓存到cache中, 如此后续的读请求就可以命中缓存了。
• page可以值缓存一个文件的部分内容, 而不需要把整个文件都缓存进来。

写Cache

• 当内核发起一个写请求时, 也是直接往cache中写入, 后备存储中的内容不会直接更新。
• 内核会将被写入的page标记为dirty, 并将其加入到dirty list中。
• 内核会周期性地将dirty list中的page写回到磁盘上, 从而使磁盘上的数据和内存中缓存的数据一致。

Cache回收

• Page cache的另一个重要工作是释放page, 从而释放内存空间。
  • cache回收的任务是选择合适的page释放
  • 如果page是dirty的, 需要将page写回到磁盘中再释放。

LRU算法

LRU(Least Recently used): 最近最少使用算法, Redis中也有此策略, 该算法在Java中可以使用LinkedHashMap进行实现。

Two-List策略

• Two-List策略维护了两个list: active list && inactive list
  • 在active list上的page被认为是hot的，不能释放。
  • 只有inactive list上的page可以被释放的。
• 首次缓存的数据的page会被加入到inactive list中，已经在inactive list中的page如果再次被访问，就会移入active list中。
• 两个链表都使用了伪LRU算法维护，新的page从尾部加入，移除时从头部移除
• 如果active list中page的数量远大于inactive list，那么active list头部的页面会被移入inactive list中，从而实现两个表的平衡。

1.1.2 Buffer Cache

• buffer cache就是一块含有许多数据块的内存区域，这些数据块主要都是数据文件里的数据块内容的拷贝。
• 从buffer cache中读取一个数据块一般需要100ns左右，从一般的存储硬盘中读取一个数据块需要10ms；所以大概算一下，从内存中读取数据块比从硬盘中快近十万倍。
• 每一个数据块在被读入buffer cache时，都会先在buffer cache中构造一个buffer header，buffer header与数据块一一对应(buffer header 中有指定buffer 具体内存地址的信息）。
• 值得注意的是在Linux2.4中，buffer cache和 page cache之间是独立的
  • 前者使用老版本的buffer_head进行存储，这导致了一个磁盘block可能在两个cache中同时存在，造成了内存的浪费。
  • 2.6内核中将两者合并到了一起，使buffer_head只存储buffer-block的映射信息，不再存储block的内容, 从而减少了内存浪费。

1.1.3 Flusher Threads

• Page Cache推迟了文件写入后备存储的时间, 但是dirty page最终还是要被写回磁盘的。
• 内核会在以下三种情况下将dirty page 写回磁盘:
  • 用户进程调用sync() 和 fsync()系统调用
  • 空闲内存低于特定的阈值(threshold)
  • Dirty数据在内存中驻留的时间超过一个特定的阈值
• 线程群的特点是让一个线程负责一个存储设备(比如一个磁盘驱动器)，多少个存储设备就用多少个线程, 从而避免阻塞或者竞争的情况，提高效率。
• 当空闲内存低于阈值时，内核就会调用wakeup_flusher_threads()来唤醒一个或者多个flusher线程，将数据写回磁盘。
• 为了避免dirty数据在内存中驻留过长时间(避免在系统崩溃时丢失过多数据)，内核会定期唤醒一个flusher线程，将驻留时间过长的dirty数据写回磁盘。

1.2 作用

page cache与buffer cache的共同目的都是加速数据I/O：

• 写数据时首先写到缓存，将写入的页标记为dirty，然后向外部存储flush，也就是缓存写机制中的write-back（另一种是write-through，Linux未采用）；
• 读数据时首先读取缓存，如果未命中，再去外部存储读取，并且将读取来的数据也加入缓存。

操作系统总是积极地将所有空闲内存都用作page cache和buffer cache，当内存不够用时也会用LRU等算法淘汰缓存页。

缓存（cache）与缓冲(buffer)的主要区别

• Buffer的核心作用是用来缓冲，缓和冲击。比如你每秒要写100次硬盘，对系统冲击很大，浪费了大量时间在忙着处理开始写和结束写这两件事嘛。用个buffer暂存起来，变成每10秒写一次硬盘，对系统的冲击就很小，写入效率高了。
• Cache的核心作用是加快取用的速度。比如一个很复杂的计算做完了，下次还要用结果，就把结果放手边一个好拿的地方存着，下次不用再算了。加快了数据取用的速度。
• page cache用于优化文件系统的I/O，buffer cache用于优化磁盘的I/O
• page cache常用于读操作的时候，将常常读取的file缓存起来；buffer cache则是将要写入磁盘的内容缓冲（零存整取）。

1.3 缓存大小如何查看

执行free命令，注意到会有一列名为buff/cache【在centos 7.2上执行】，

buff/cache即表示当前页、块缓存的大小，如截图，占用了43GB

1.4 IO流

如下图：

• IO控制流就是带着元数据的流转，driver中会管理着buffer cache、文件的元数据信息；
• 数据直接按照数据流从page cache刷入disk的cache(磁盘也是有自己的cache的)。

  

  对于具体的Linux文件系统，会以block(磁盘块)的形式组织文件，为了减少对物理块设备的访问，在文件以块的形式调入内存后，使用块高速缓存进行管理。每个缓冲区由两部分组成，第一部分称为缓冲区首部，用数据结构buffer_head表示，第二部分是真正的存储的数据。由于缓冲区首部不与数据区域相连，数据区域独立存储。因而在缓冲区首部中，有一个指向数据的指针和一个缓冲区长度的字段。

  

1.5 两类缓存的逻辑关系

从linux-2.6.18的内核源码来看， Page Cache和Buffer Cache是一个事物的两种表现：对于一个Page而言，对上，它是某个File的一个Page Cache，而对下，它同样是一个Device上的一组Buffer Cache 。

File在地址空间上，以4K(page size)为单位进行切分，每一个4k都可能对应到一个page上（这里 可能 的含义是指，只有被缓存的部分，才会对应到page上，没有缓存的部分，则不会对应），而这个4k的page，就是这个文件的一个Page Cache。

而对于落磁盘的一个文件而言，最终这个4k的page cache，还需要映射到一组磁盘block对应的buffer cache上，假设block为1k，那么每个page cache将对应一组(4个)buffer cache，而每一个buffer cache，则有一个对应的buffer cache与device block映射关系的描述符：buffer_head，这个描述符记录了这个buffer cache对应的block在磁盘上的具体位置。

2 大数据产品针对page cache的利用

2.1 Kafka对page cache的利用

Kafka为什么不自己管理缓存，而非要用page cache？原因有如下三点：

• JVM中一切皆对象，数据的对象存储会带来所谓object overhead，浪费空间；
• 如果由JVM来管理缓存，会受到GC的影响，并且过大的堆也会拖累GC的效率，降低吞吐量；

• 一旦程序崩溃，自己管理的缓存数据会全部丢失。

  Kafka三大件（broker、producer、consumer）与page cache的关系可以用下面的简图来表示。

  

  producer生产消息发到Server端时，会调用writeFullyTo【会调用Java NIO中是FileChannel.write() API】按偏移量写入数据，并且都会先写入page cache里。consumer消费消息时，会使用sendfile()系统调用【对应FileChannel.transferTo() API】，零拷贝地将数据从page cache传输到broker的Socket buffer，再通过网络传输。

  具体参见 org.apache.kafka.common.record.FileRecords中的

public int append(MemoryRecords records) throws IOException {
        if (records.sizeInBytes() > 2147483647 - this.size.get()) {
            throw new IllegalArgumentException("Append of size " + records.sizeInBytes() + " bytes is too large for segment with current file position at " + this.size.get());
        } else {
            int written = records.writeFullyTo(this.channel);
            this.size.getAndAdd(written);
            return written;
        }
    }

 public int writeFullyTo(GatheringByteChannel channel) throws IOException {
        this.buffer.mark();

        int written;
        for(written = 0; written < this.sizeInBytes(); written += channel.write(this.buffer)) {
        }

        this.buffer.reset();
        return written;
    }
 @Override
    public long writeTo(GatheringByteChannel destChannel, long offset, int length) throws IOException {
        long newSize = Math.min(channel.size(), end) - start;
        int oldSize = sizeInBytes();
        if (newSize < oldSize)
            throw new KafkaException(String.format(
                    "Size of FileRecords %s has been truncated during write: old size %d, new size %d",
                    file.getAbsolutePath(), oldSize, newSize));

        long position = start + offset;
        int count = Math.min(length, oldSize);
        final long bytesTransferred;
        if (destChannel instanceof TransportLayer) {
            TransportLayer tl = (TransportLayer) destChannel;
            bytesTransferred = tl.transferFrom(channel, position, count);
        } else {
            bytesTransferred = channel.transferTo(position, count, destChannel);
        }
        return bytesTransferred;
    }
           

图中没有画出来的还有leader与follower之间的同步，这与consumer是同理的：只要follower处在ISR【同步的replica，相对的就有out of sync replica，也就是跟不上同步节奏的replica】中，就也能够通过零拷贝机制将数据从leader所在的broker page cache传输到follower所在的broker。

同时，page cache中的数据会随着内核中flusher线程的调度以及对sync()/fsync()的调用写回到磁盘，就算进程崩溃，也不用担心数据丢失。另外，如果consumer要消费的消息不在page cache里，才会去磁盘读取，并且会顺便预读出一些相邻的块放入page cache，以方便下一次读取。

如果Kafka producer的生产速率与consumer的消费速率相差不大，那么就能几乎只靠对broker page cache的读写完成整个生产-消费过程，磁盘访问非常少。这个结论俗称为“读写空中接力”。并且Kafka持久化消息到各个topic的partition文件时，是只追加的顺序写，充分利用了磁盘顺序访问快的特性，效率高。

2.2 redis AOF对page cache的利用

当 Redis 开启 AOF 时，需要配置 AOF 的刷盘策略。

基于性能和数据安全的平衡，你肯定会采用 append fsync everysec 这种方案。

这种方案的工作模式为，Redis 的后台线程每间隔 1 秒，就把 AOF page cache 的数据，刷到磁盘（fsync）上。

这种方案的优势在于，把 AOF 刷盘的耗时操作，放到了后台线程中去执行，避免了对主线程的影响。

AOF everysec 真的不会阻塞主线程吗？

Redis 后台线程在执行 AOF page cache 刷盘（fysnc）时，如果此时磁盘 IO 负载过高，那么调用 fsync 就会被阻塞住。

此时，主线程仍然接收写请求进来，那么此时的主线程会先判断，上一次后台线程是否已刷盘成功。

如何判断呢？

后台线程在刷盘成功后，都会记录刷盘的时间。

主线程会根据这个时间来判断，距离上一次刷盘已经过去多久了。整个流程是这样的：

• 主线程在写 AOF page cache（write系统调用）前，先检查后台 fsync 是否已完成？
  • fsync 已完成，主线程直接写 AOF page cache
  • fsync 未完成，则检查距离上次 fsync 过去多久？
    • 如果距离上次 fysnc 成功在 2 秒内，那么主线程会直接返回，不写 AOF page cache
    • 如果距离上次 fysnc 成功超过了 2 秒，那主线程会强制写 AOF page cache（write系统调用）

由于磁盘 IO 负载过高，此时，后台线程 fynsc 会发生阻塞，那主线程在写 AOF page cache 时，也会发生阻塞等待（操作同一个 fd，fsync 和 write 是互斥的，一方必须等另一方成功才可以继续执行，否则阻塞等待）

通过分析可以发现，即使你配置的 AOF 刷盘策略是 appendfsync everysec，也依旧会有阻塞主线程的风险。

其实，产生这个问题的重点在于，磁盘 IO 负载过高导致 fynsc 阻塞，进而导致主线程写 AOF page cache 也发生阻塞。

所以，你一定要保证磁盘有充足的 IO 资源，避免这个问题。

3 page cache相关的参数

page cache中的数据会随着内核中flusher线程的调度写回磁盘。与它相关的有以下4个参数，必要时可以调整。

• /proc/sys/vm/dirty_writeback_centisecs：flush检查的周期。单位为0.01秒，默认值500，即5秒。每次检查都会按照以下三个参数控制的逻辑来处理。
• /proc/sys/vm/dirty_expire_centisecs：如果page cache中的页被标记为dirty的时间超过了这个值，就会被直接刷到磁盘。单位为0.01秒。默认值3000，即半分钟。
• /proc/sys/vm/dirty_background_ratio：如果dirty page的总大小占空闲内存量的比例超过了该值，就会在后台调度flusher线程异步写磁盘，不会阻塞当前的write()操作。默认值为10%。
• /proc/sys/vm/dirty_ratio：如果dirty page的总大小占总内存量的比例超过了该值，就会阻塞所有进程的write()操作，并且强制每个进程将自己的文件写入磁盘。默认值为20%。

由此可见，调整空间比较灵活的是参数2、3，而尽量不要达到参数4的阈值，代价太大了。

使用sysctl -a | frep dirty命令可以查看默认配置

参考

Page Cache(页缓存)

Linux文件系统(五)—三大缓冲区之buffer块缓冲区

【kafka】源码分析-Producer过程全解

Kafka 源码解析：Server 端的运行过程

KAFKA进阶：【十一】总结一下，KAFKA的高并发、高吞吐等特性？

颠覆认知——Redis会遇到的15个“坑”，你踩过几个？