零拷贝

DevLGQ

ComputerBasics

发布于：2021年10月5日

次浏览

字数：3.9k字

时长：13分钟

零拷贝

硬盘可以说是计算机系统中最慢的硬件之一。针对硬盘优化的技术很多，比如零拷贝，直接I/O，异步I/O等，这些目的都是为了提高系统的吞吐量，操作系统内核中的磁盘高速缓存区，也可以有效减少磁盘的访问次数。

DMA技术

没有MDA技术之前，IO的过程：

CPU 发出对应的指令给磁盘控制器，然后返回；
磁盘控制器收到指令后，开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断；
CPU 收到中断信号后，停下手头的工作，然后把磁盘控制器缓冲区的内容一个个字节读进寄存器，再把寄存器里的数据写入内存，而数据传输期间，CPU 是无法执行其它任务的。

整个过程都需要CPU参与搬运，而且不能去做其它事情。

当数据量越来越大，CPU肯定是忙不过来的，所以直接内存访问（Direct Memory Access）技术应运而生。

DMA技术，在进行IO设备和内存的数据传输时，数据搬运的工作全部交给 DMA 控制器，而CPU不再参与任何与数据搬运相关的事情，这样CPU就可以去做其它事情了。

用户调用read()方法，向OS发起IO请求，请求读取数据到自己的内存缓冲区，进程进入阻塞状态
OS收到请求后，进一步把IO请求发送给DMA，然后让CPU去执行其它任务
DMA再把IO请求转发给硬盘
硬盘收到DMA的请求，把数据从硬盘读到硬盘控制器的缓冲区，当缓冲区满了之后，向DMA发出中断信号，告知缓冲区满了
DMA收到请求后，将硬盘控制器中的缓冲区的数据拷贝到内核的缓冲区，注意，这个时候是占用CPU的
当DMA读取的数据到一定的数据，就会向CPU发起中断信号，告知CPU数据准备好了
CPU收到DMA的信号，把数据从内核缓冲区拷贝到用户缓冲区

CPU还是必不可少的，需要CPU告知DMA传输什么数据，传输到哪里。

早期的DMA只在主板上，现在每个IO设备都有自己对应的DMA控制器。

传统的文件传输

传统的IO工作方式，一般都有以下两个调用

read(file, tmp_buf, len);
write(socket, tmp_buf, len);

可以看到，期间发生了四次用户态和内核态的切换，因为发生了两次系统调用，一次是read()，一次是write()。每次调用都得先从用户态切换到内核态，等内核完成任务后，再从内核态切回用户态。

上下文切换的成本不小，一次切换十几纳秒到几微秒，在高并发的情况下，这类时间就很容易被累积和放大，影响系统性能。

其次，还发生了4次数据的拷贝。

通过DMA把磁盘中的数据拷贝到系统内核的缓冲区里。
通过CPU把内核缓冲区的数据拷贝到用户缓冲区。
通过CPU把用户缓冲区的数据拷贝到socket缓冲区。
通过DMA把socket缓冲区的数据拷贝到网卡缓冲区。

所以，要提高文件传输的性能，就需要减少[用户态与内核态的切换]和[内存拷贝]的次数。

优化文件传输性能

第一，减少[用户态与内核态的切换]的切换次数

读取磁盘数据的时候，因为用户态没有权限操作磁盘，而内核态的权限是最高的，所以需要操作这些资源，需要进行上下文的切换。

一次的系统调用必然会发生2次上下文的切换：首先是切换到内核态，当内核执行完任务后，再切换回用户态交由进程代码执行。

所以，想要减少上下文的切换，就要减少系统调用。

第二，减少[内存拷贝]的次数

传统的方式，经历了四次拷贝，在这四次里面，内核缓冲区到用户缓冲区和从用户缓冲区到socket缓冲区是没有必要的。

因为在文件传输的应用场景，在用户空间不会对数据进行加工，所以实际数据上可以不用拷贝到用户空间，因此用户缓冲区是没有必要存在的。

零拷贝的实现

通常两种实现方式

mmap + write
sendfile

mmap + write

read()系统调用的过程会把内核缓冲数据拷贝到用户缓冲区里，为了减少这个开销，可以使用mmap()代替read()系统调用。

read(file, tmp_buf, len);
write(socket, tmp_buf, len);

具体流程如下

应用调用了mmap()之后，DMA会把磁盘的数据拷贝到内核缓冲区。然后应用进程和操作系统内核[共享]这个缓冲区；
应用进程调用write()，操作系统通过CPU直接将内核的数据拷贝到socket缓冲区，这个过程发生在内核态；
最后，通过DMA把socket缓冲区的数据拷贝到网卡缓冲区。

可以知道使用mmap()代替read()，可以减少一次数据拷贝。

但是仍然不理想，上下文切换还是4次，也还需要CPU把内核缓冲区的数据拷贝到socket缓冲区。

sendfile

在Linux内核版本2.1中，提供了一个专门发送文件的系统调用函数sendfile()。

#include <sys/socket>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

前两个参数是目的端和源端的文件描述符，后两个是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

但是这个还不是真正的零拷贝技术，如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术，可以进一步减少通过CPU把内核缓冲区的数据拷贝到socket缓冲区的过程。

可以使用以下指令查看是否支持

ethtool -k eth0 | grep scatter-gather

所以，从Linux 2.4版本开始，对于网卡支持 SG—DMA 技术的情况下，sendfile()系统调用的过程发生了变化，具体如下

通过DMA将磁盘数据拷贝到内核缓冲区
缓冲区描述符和数据长度传到socket缓冲区，网卡的 SG-DMA 控制器可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到socket缓冲区。

这也就是所谓的零拷贝（Zero-Copy）技术，因为没有在内存层面进行数据的拷贝，也就是说全程都没有通过CPU来进行数据的搬运，所有数据都是通过DMA来进行传输的。

零拷贝技术的文件传输方式相比传统的方式，减少了2次上下文切换和数据拷贝，只需要2次上下文切换和数据拷贝就可以完成文件的传输，而且两次拷贝都不需要通过CPU，都是通过DMA传输的。

使用零拷贝的项目

Kafka这个项目就是利用了[零拷贝]技术，从而大幅度提升了IO的吞吐量，这也是Kafka在处理海量数据还可以这么快的原因之一。

如果看源码，可以发现，最终调用了 Java NIO 库里的 transferTo 方法：

@Override
public long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
    return fileChannel.transferTo(position, count, socketChannel);
}

如果Linux系统支持 sendfile 系统调用，那么 transferTo() 实际最后会调用 sendfile 系统函数。

曾经有人专⻔写程序测试过，在同样的硬件条件下，传统⽂件传输和零拷⻉⽂件传输的性能差异，使⽤了零拷⻉能够缩短 65% 的时间，可以⼤幅度提升了机器传输数据的吞吐量。

另外Nginx也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下

http {
    sendfile on
}

想使用 sendfile 的话， Linux的内核版本要在 2.1 以上。

PageCache作用

内核缓冲区实际上是磁盘高速缓存（PageCache）。

零拷贝技术使用了 PageCache 技术，使得零拷贝的性能进一步提升。

读写磁盘相⽐读写内存的速度慢太多了，所以应该想办法把[读写磁盘]替换成[读写内存]。通过 DMA 把磁盘⾥的数据搬运到内存⾥，这样就可以⽤读内存替换读磁盘。但是，内存空间远⽐磁盘要⼩，内存注定只能拷⻉磁盘⾥的⼀⼩部分数据。

根据程序局部性原理，通常刚被访问到的数据，在短时间内被再次访问的概率很高，所以可以用 PageCache 来缓存最近被访问的数据，当空间不足时淘汰掉最久未被访问的缓存。

当读取磁盘数据时，先在 PageCache 中找，如果数据存在则直接返回即可；如果没有，则从磁盘中读取，然后缓存到 PageCache。

还有⼀点，读取磁盘数据的时候，需要找到数据所在的位置，但是对于机械磁盘来说，就是通过磁头旋转到数据所在的扇区，再开始[顺序]读取数据，但是旋转磁头这个物理动作是⾮常耗时的，为了降低它的影响，PageCache 使⽤了预读功能。⽐如，假设 read ⽅法每次只会读 32 KB 的字节，虽然 read 刚开始只会读 0 ～ 32 KB 的字节，但内核会把其后⾯的 32～64 KB 也读取到 PageCache，这样后⾯读取 32～64 KB 的成本就很低，如果在 32～64 KB 淘汰出 PageCache 前，进程读取到它了，收益就会⾮常⼤。

综上，PageCache 的优点有两个：

缓存最近被访问的数据
预读功能

但是，PageCache 对于大文件是不起作用的（GB级别的文件）。大文件很容易把 PageCache 占满，另外由于文件大，部分文件被再次访问的概率低，会带来2个问题

PageCache 由于长时间被大文件占据，其它热点的小文件可能就无法充分使用到 PageCache
PageCache 中的大文件数据，由于没有享受到缓存带来的好处，但却耗费DMA拷贝到 PageCache 一次

所以，针对大文件传输，不应该使用 PageCache，也就是说不应该使用零拷贝技术。

大文件的传输方式

使用read()调用读取，进程会阻塞，等待磁盘数据返回。

具体过程：

当调用 read 方法时，会阻塞，此时内核会向磁盘发起IO请求，便会寻址，当磁盘数据准备好了，就会向内核发起IO中断，告知内核磁盘数据已经准备好
内核收到IO中断信号后，将数据从磁盘控制器拷贝到PageCache
最后，内核再把 PageCache 中的数据拷贝到用户缓冲区，read调用就正常返回

对于阻塞，使用异步IO来解决问题

分两部分：

前部分，内核向磁盘发起请求，但是不等待数据准备好就返回，之后进程可以去处理其它任务
后部分，当内核将磁盘中的数据拷贝到进程缓冲区之后，进程将接收到内核的通知，再去处理数据

可以发现，异步IO并没有涉及到PageCache，所以异步IO可以绕开PageCache。

绕开PageCache的IO叫做直接IO，使用PageCache的IO则叫缓存IO。通常来说，异步IO只支持直接IO。

大文件传输不应该PageCache，因为由于PageCache被大文件占用，会导致热点小文件无法利用PageCache。

在高并发的场景下，针对大文件的传输方式，应该使用[异步IO+直接IO]来代替零拷贝技术。

直接IO的应用场景

应⽤程序已经实现了磁盘数据的缓存，那么可以不需要 PageCache 再次缓存，减少额外的性能损耗。在 MySQL 数据库中，可以通过参数设置开启直接 I/O，默认是不开启；
传输⼤⽂件的时候，由于⼤⽂件难以命中 PageCache 缓存，⽽且会占满 PageCache 导致热点⽂件⽆法充分利⽤缓存，从⽽增⼤了性能开销，因此，这时应该使⽤直接 I/O。

绕过PageCache的直接IO，无法享受内核的两点优化

内核的IO调度算法会缓存尽可能的IO请求在PageCache中，最后合成一个更大的IO请求再发送给磁盘，这样是为了减少磁盘的选址操作；
内核也预读后续IO请求放在PageCache中，也是为了减少对磁盘的操作。

在传输文件的时候，要根据文件的大小来使用IO传输方式

传输大文件的时候，使用异步IO+直接IO
传输小文件的时候，使用零拷贝技术

在nginx中，可以根据文件的大小选择不同的方式

location /video/ {
    sendfile on;
    aio on;
    directio 1024m;
}

当文件大小大于directio值后，使用异步IO+直接IO ，否则使用零拷贝技术。

总结

为了解决早期数据传输特别浪费CPU资源的情况，每个IO设备都拥有自己的DMA控制器，通过DMA控制器，CPU只需要告诉DMA控制器，要传输什么数据，从哪里来，到那里去，就可以不管了。后续的实际传输工作，交由DMA控制器完成。

传统IO的工作模式，从硬盘读数据然后再通过网卡向外发送，需要进行4次上下文切换和4次数据拷贝，其中2次数据拷贝发生在内存里的缓冲区和对应硬件设备之间，由DMA完成的。另外2次发生到内核态和用户态之间，这个数据的拷贝由CPU完成。

为了提高文件传输的性能，使用零拷贝技术，通过一次系统调用（sendfile）合并了磁盘读取与网络发送两个操作，降低了上下文的切换次数。而数据的拷贝发生在内核中，降低了数据拷贝的次数。

Kafka和Nginx都实现了零拷贝技术，大大提高了文件传输的性能。

零拷贝技术基于PageCache的，PageCache会缓存最近访问的数据，提升访问缓存数据的性能，同时为了解决机械硬盘寻址慢的问题，协助IO调度算法实现IO合并与预读，这也是顺序读比随机读性能好的原因。

需要注意的是，零拷贝技术不允许进程对文件内容进行加工，比如数据压缩再发送。

而发送大文件时，不能使用零拷贝技术，因为可能由于PageCache被大文件占用，而导致热点小文件就无法利用到PageCache，并且大文件的缓存命中率不高，就需要使用异步IO+直接IO 的方式。

更新于：2021年10月5日

ComputerBasics

单点登录

单点登录单点登录又称之为 Single Sign On, 简称SSO，实现基于用户会话的共享。提供用户效率提高开发人员的效率简化管理单点登录的实现方式单机部署：web单系统应用分...

ElasticSearch读写原理

ElasticSearch读写原理写数据过程 client 通过 hash 选择一个 node 发送请求，这个 node 被称作为 coordinating node（协调节点）协调节点对 d...