DMA 控制器的发展
无 DMA 控制器 IO 过程
DM_20230819122941_001.png
- 用户进程发起 read 调用，向操作系统发送 I/O 请求，进程进入阻塞状态；
- 操作系统收到请求后，CPU 发出对应的控制指令给磁盘控制器， CPU 释放执行其它任务。
- 磁盘控制器收到指令后，开始准备数据并将数据放入磁盘控制器的内部缓冲区，然后产生一个中断。
- CPU 收到中断信号后，将磁盘控制器缓冲区的数据读入寄存器，再从寄存器写入到内核缓冲区，这个过程 CPU 无法处理其它的事情。
- 当内核缓冲区中有足够多的数据后，CPU 将内核缓冲区的数据拷贝到用户缓冲区中。
DMA 控制器
- 如果 CPU 搬运的数据很小，那么问题并不大，但是如果需要拷贝大量数据肯定是不行的，因为 CPU 的资源十分宝贵。为了解决这个问题，于是出现了 DMA（Direct Memory Access，直接内存访问） 技术。
- 简单来说就是：在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务。
- 使用 DMA 控制器后，数据传输过程如下：
DM_20230819122946_001.png
- 用户进程发起 read 调用，向操作系统发送 I/O 请求，进程进入阻塞状态；
- 操作系统收到请求后，CPU 发送一个请求给 DMA , CPU 释放执行其它任务。
- DMA 进一步将 I/O 请求发送磁盘控制器，磁盘控制器收到指令后，开始准备数据并将数据放入磁盘控制器的内部缓冲区，然后产生一个中断。
- DMA 收到中断信号后将磁盘控制器缓冲区的数据拷贝到内核缓存区（此时不占用 CPU 资源，CPU 可以执行其它任务）。
- 当 DMA 读取到足够多的数据到内核缓冲区后，发送中断信号给 CPU ,CPU 将内核缓冲区的数据拷贝到用户缓冲区中。
注：早期 DMA 只存在于主板上，现在 I/O 设备越来越多，数据传输需求也越来越复杂，所以每个 I/O 设备中都有自己的 DMA 控制器。
传统文件传输性能有多糟糕？
- 现在，大家思考一下，如果我们服务器需要提供文件传输功能，应该怎么做？最简单的方式就是将磁盘上的文件读取出来，然后通过网络协议发送给客户端。通常涉及以下两个系统调用：
read(file, tmp_buf, len);
write(socket, tmp_buf, len);
- 具体流程图如下：
DM_20230819123006_001.png
- 我们来看看整个过程发生了什么，发生了 2 次系统调用（4 次上下文切换），4 次数据拷贝（2 次 CPU 拷贝，2 次 DMA 拷贝）。
- 虽然一次上下文切换的时间很短，几十纳秒到几微秒，但在高并发场景下，很容易影响性能。同时我们发现我们虽然只是传输了一份数据，但却拷贝了 4 次，毫无疑问过多的数据拷贝将会占用我们的 CPU 资源。
- 因此，如果我们想要优化整个文件传输过程，那么主要的优化思路就是减少用户态和内核态的上下文切换以及减少数据拷贝。
如何优化文件传输性能
- 上面我们说到想要优化整个文件传输过程，那么主要的优化思路就是减少用户态和内核态的上下文切换以及减少数据拷贝。
- 我们知道上下文切换其实是由于系统调用产生，因此减少系统调用就可以减少上下文切换。同时在文件传输场景中，我们用户进程并不会对数据进行加工，那么我们是不是可以不用将数据拷贝到用户空间呢？答案是可以，因此文件传输下，用户缓冲区没有存在的必要。
零拷贝技术
- 基于上述两点优化，发展出来了零拷贝技术，零拷贝技术一般有以下两种实现方案，下面我们就具体谈一谈它如何减少上下文切换和数据拷贝次数：
mmap + write
sendfile
mmap + write
- 在传统的文件 IO 过程中，我们需要使用 read 调用将内核缓冲区的数据读到用户缓存区，为了减少这一步的复制开销，我们使用 mmap() 代替 read():
buf = mmap(file, len);
write(sockfd, buf, len);
DM_20230819123011_001.png
- 用户进程调用 mmap() 方法后，DMA 将数据从磁盘拷贝到内核缓冲区，用户进程和内核共享这个缓冲区。
- 用户进程调用 read() 方法后，CPU 将数据从内核缓冲区拷贝到 Socket 缓冲区。
sendfile
- 上面整个过程虽然减少了 2 次数据拷贝，但仍然存在 4 次上下文切换。
- 在 Linux 内核版本 2.1 中，提供了一个专门发送文件的系统调用函数 sendfile()，函数形式如下，可以进一步减少系统调用：
#include <sys/socket.h>
// 前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
DM_20230819123024_001.png
- 这样，我们一次文件传输，只需要 3 次数据拷贝和 2 次上下文切换。
SG-DMA（The Scatter-Gather Direct Memory Access）
- 如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术（和普通的 DMA 有所不同），sendfile() 调用还会进一步优化，去掉了 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程，将数据直接从内核缓冲区拷贝到网卡中。
DM_20230819123030_001.png
- 这就是真正的零拷贝技术（zero-copy），因为我们全程没有使用 CPU 拷贝数据，而是通过 DMA 来进行传输。
零拷贝技术的应用
- 我们比较常用的 kafka 就使用了零拷贝技术，从而大幅提高了 I/O 的吞吐率，这也是 kafka 能处理海量数据的原因之一。
- kafka 传输部分实现底层调用 Java NIO 库里的 transferTo 方法，如果 Linux 系统支持 sendfile() 系统调用，那么 transferTo() 实际上最后就会使用到 sendfile() 系统调用函数。
@Overridepublic
long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
return fileChannel.transferTo(position, count, socketChannel);
}
- 在同样的硬件条件下，传统文件传输和零拷拷贝文件传输的性能差异测试，使用了零拷贝技术接近缩短了 65% 的时间，能够大幅提升我们的吞吐量：
DM_20230819123034_001.png
大文件传输应该用什么方式
- 在了解这个问题前，我们先了解两个概念 PageCache 和 直接 I/O。
PageCache（内核缓冲区） 的作用
- Write Buffer：写入数据时内核 I/O 算法会尽可能缓存更多的 I/O 请求在 PageCahe 中，最后合并为一个更大的 I/O 请求给磁盘，减少磁盘的寻址操作。
- Read Cache：内核会预读相邻的数据内容并缓存一些热点数据在 PageCahe 中，减少对磁盘的访问，提到访问速度。
直接 I/O
DM_20230819123037_001.png
直接 I/O 适用场景
- 应用本身已经实现了磁盘数据缓存，那么就可以不需要 PageCahe ，减少内核缓冲区的复制带来的消耗。比如在 MySQL 数据库中就可以开启直接 I/O，默认不开启。
- 数据本身过大，难以命中 PageCahe 缓存，同时会占满 PageCahe，导致其它热点数据失效，带来额外的性能开销。
综上所述
- 从上面两点我们可以看出：
- 对于小文件传输，我们可以使用零拷贝技术减少上下文的切换和数据拷贝次数提高性能。
- 但对于大文件，已经不适合使用基于 PageCahe 的零拷贝技术，而是应该使用直接 I/O 的方式，同时为了避免大文件直接 I/O 带来的长时间阻塞，我们可以使用 直接 I/O + 异步 I/O 的方式传输大文件。
DM_20230819123043_001.png
Nginx 中的零拷贝技术和直接 I/O
- 在 nginx 中，既支持 零拷贝技术，也支持 直接 I/O 我们可以根据文件大小这样配置：
location /file/ {
sendfile on;
aio on;
directio 1024m;
}
- 当文件大小小于 1024M 时使用零拷贝技术，当大于时使用直接 IO 技术。