网站建设与管理简答题,上海网站搭建公司哪家好,营销型网站举例,wordpress 十大插件接上文解析从Linux零拷贝深入了解Linux-I/O#xff08;上#xff09; 大文件传输场景
零拷贝还是最优选吗
在大文件传输的场景下#xff0c;零拷贝技术并不是最优选择#xff1b;因为在零拷贝的任何一种实现中#xff0c;都会有「DMA 将数据从磁盘拷贝到内核缓存区——P…接上文解析从Linux零拷贝深入了解Linux-I/O上 大文件传输场景
零拷贝还是最优选吗
在大文件传输的场景下零拷贝技术并不是最优选择因为在零拷贝的任何一种实现中都会有「DMA 将数据从磁盘拷贝到内核缓存区——Page Cache」这一步但是在传输大文件GB 级别的文件的时候PageCache 会不起作用那就白白浪费 DMA 多做的一次数据拷贝造成性能的降低即使使用了 PageCache 的零拷贝也会损失性能。
这是因为在大文件传输场景下每当用户访问这些大文件的时候内核就会把它们载入 PageCache 中PageCache 空间很快被这些大文件占满且由于文件太大可能某些部分的文件数据被再次访问的概率比较低这样就会带来 2 个问题 PageCache 由于长时间被大文件占据其他「热点」的小文件可能就无法充分使用到 PageCache于是这样磁盘读写的性能就会下降了 PageCache 中的大文件数据由于没有享受到缓存带来的好处但却耗费 DMA 多拷贝到 PageCache 一次。 异步 I/O direct I/O
那么大文件传输场景下我们该选择什么方案呢让我们先来回顾一下我们在文章开头介绍 DMA 时最早提到过的同步 I/O 这里的同步 体现在当进程调用 read 方法读取文件时进程实际上会阻塞在 read 方法调用因为要等待磁盘数据的返回并且我们当然不希望进程在读取大文件时被阻塞对于阻塞的问题可以用异步 I/O 来解决即 它把读操作分为两部分 前半部分内核向磁盘发起读请求但是可以不等待数据就位就返回 于是进程此时可以处理其他任务 后半部分当内核将磁盘中的数据拷贝到进程缓冲区后进程将接收到内核的通知 再去处理数据
而且我们可以发现异步 I/O 并没有涉及到 PageCache使用异步 I/O 就意味着要绕开 PageCache因为填充 PageCache 的过程在内核中必须阻塞。
所以异步 I/O 中使用的是direct I/O对比使用 PageCache 的buffer I/O这样才能不阻塞进程立即返回。
direct I/O 应用场景常见的两种 应用程序已经实现了磁盘数据的缓存那么可以不需要 PageCache 再次缓存减少额外的性能损耗。在 MySQL 数据库中可以通过参数设置开启direct I/O默认是不开启 传输大文件的时候由于大文件难以命中 PageCache 缓存而且会占满 PageCache 导致「热点」文件无法充分利用缓存从而增大了性能开销因此这时应该使用direct I/O
当然由于direct I/O 绕过了 PageCache就无法享受内核的这两点的优化 内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中最后「合并 」成一个更大的 I/O 请求再发给磁盘这样做是为了减少磁盘的寻址操作 内核也会「预读 」后续的 I/O 请求放在 PageCache 中一样是为了减少对磁盘的操作
实际应用中也有类似的配置在 nginx 中我们可以用如下配置来根据文件的大小来使用不同的方式传输
location /video/ { sendfile on; aio on; directio 1024m; }
当文件大小大于 directio 值后使用「异步 I/O 直接 I/O」否则使用「零拷贝技术」。
使用 direct I/O 需要注意的点
首先贴一下我们的Linus(Linus Torvalds)对 O_DIRECT的评价 The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances. —Linus 一般来说能引得Linus开骂的东西那是一定有很多坑的。
在 Linux 的man page中我们可以看到O_DIRECT 下有一个 Note还挺长的这里我就不贴出来了。
总结一下其中需要注意的点如下
地址对齐限制
O_DIRECT 会带来强制的地址对齐限制这个对齐的大小也跟文件系统/存储介质 相关并且当前没有不依赖文件系统自身的接口提供指定文件/文件系统是否有这些限制的信息 Linux 2.6 以前 总传输大小、用户的对齐缓冲区起始地址、文件偏移量必须都是逻辑文件系统的数据块 大小的倍数这里说的数据块(block)是一个逻辑概念是文件系统捆绑一定数量的连续扇区而来因此通常称为 “文件系统逻辑块”可通过以下命令获取blockdev --getss Linux2.6以后对齐的基数变为物理上的存储介质的sector size扇区大小对应物理存储介质的最小存储粒度可通过以下命令获取blockdev --getpbsz
带来这个限制的原因也很简单内存对齐这件小事通常是内核来处理的而O_DIRECT 绕过了内核空间那么内核处理的所有事情都需要用户自己来处理这里贴一篇详细解释。
O_DIRECT 平台不兼容
这应该是大部分跨平台应用需要注意到的点O_DIRECT 本身就是Linux中才有的东西在语言层面 / 应用层面需要考虑这里的兼容性保证比如在Windows下其实也有类似的机制FILE_FLAG_NO_BUFFERIN 用法类似参考微软的官方文档再比如macOS下的F_NOCACHE 虽然类似O_DIRECT 但实际使用中也有差距参考这个issue。 不要并发地运行 fork 和 O_DIRECT I/O
如果O_DIRECT I/O中使用到的内存buffer是一段私有的映射虚拟内存如任何使用上文中提到过的mmap并以MAP_PRIVATE flag 声明的虚拟内存那么相关的O_DIRECT I/O不管是异步 I/O / 其它子线程中的 I/O都必须在调用fork系统调用前执行完毕否则会造成数据污染或产生未定义的行为实例可参考这个Page。
以下情况这个限制不存在 相关的内存buffer是使用shmat分配或是使用mmap以MAP_SHARED flag 声明的 相关的内存buffer是使用madvise以MADV_DONTFORK 声明的注意这种方式下该内存buffer在子进程中不可用。 避免对同一文件混合使用 O_DIRECT 和普通 I/O
在应用层需要避免对同一文件尤其是对同一文件的相同偏移区间内 混合使用O_DIRECT和普通I/O即使我们的文件系统能够帮我们处理和保证这里的一致性问题 总体来说整个I/O吞吐量也会比单独使用某一种I/O方式要小。
同样的应用层也要避免对同一文件混合使用direct I/O和mmap。 资料直通车Linux内核源码技术学习路线视频教程内核源码 学习直通车Linux内核源码内存调优文件系统进程管理设备驱动/网络协议栈 NFS 协议下的 O_DIRECT
虽然NFS文件系统就是为了让用户像访问本地文件一样去访问网络文件但O_DIRECT在NFS文件系统中的表现和本地文件系统不同比较老版本的内核或是魔改过的内核可能并不支持这种组合。
这是因为在NFS协议中并不支持传递flag 参数 到服务器所以O_DIRECT I/O实际上只绕过了本地客户端的Page Cache但服务端/同步客户端仍然会对这些I/O进行cache。
当客户端请求服务端进行I/O同步来保证O_DIRECT的同步语义时一些服务器的性能表现不佳尤其是当这些I/O很小时还有一些服务器干脆设置为欺骗客户端 直接返回客户端「数据已写入存储介质 」这样就可以一定程度上避免I/O同步带来的性能损失但另一方面当服务端断电时就无法保证未完成I/O同步的数据的数据完整性 了。
Linux的NFS客户端也没有上面说过的地址对齐的限制。 在 Golang 中使用 direct I/O
direct io 必须要满足 3 种对齐规则io 偏移扇区对齐长度扇区对齐内存 buffer 地址扇区对齐前两个还比较好满足但是分配的内存地址仅凭原生的手段是无法直接达成的。
先对比一下 c 语言libc 库是调用 posix_memalign 直接分配出符合要求的内存块但Golang中要怎么实现呢
在Golang中io 的 buffer 其实就是字节数组自然是用 make 来分配如下
buffer : make([]byte, 4096)
但buffer中的data字节数组首地址并不一定是对齐的。
方法也很简单就是先分配一个比预期要大的内存块然后在这个内存块里找对齐位置 这是一个任何语言皆通用的方法在 Go 里也是可用的。
比如我现在需要一个 4096 大小的内存块要求地址按照 512 对齐可以这样做 先分配 4096 512 大小的内存块假设得到的内存块首地址是 p1 然后在 [ p1, p1512 ] 这个地址范围找一定能找到 512 对齐的地址 p2 返回 p2 用户能正常使用 [ p2, p2 4096 ] 这个范围的内存块而不越界。
以上就是基本原理了 具体实现如下
// 从 block 首地址往后找到符合 AlignSize 对齐的地址并返回
// 这里很巧妙的使用了位运算性能upup
func alignment(block []byte, AlignSize int) int {return int(uintptr(unsafe.Pointer(block[0])) uintptr(AlignSize-1))
}// 分配 BlockSize 大小的内存块
// 地址按 AlignSize 对齐
func AlignedBlock(BlockSize int) []byte {// 分配一个大小比实际需要的稍大block : make([]byte, BlockSizeAlignSize)// 计算到下一个地址对齐点的偏移量a : alignment(block, AlignSize)offset : 0if a ! 0 {offset AlignSize - a}// 偏移指定位置生成一个新的 block这个 block 就满足地址对齐了block block[offset : offsetBlockSize]if BlockSize ! 0 {// 最后做一次地址对齐校验a alignment(block, AlignSize)if a ! 0 {log.Fatal(Failed to align block)}}return block
}所以通过以上 AlignedBlock 函数分配出来的内存一定是 512 地址对齐的唯一的一点点缺点就是在分配较小内存块时对齐的额外开销显得比较大。
开源实现
Github 上就有开源的Golang direct I/O实现ncw/directio
使用也很简单
O_DIRECT 模式打开文件
// 创建句柄
fp, err : directio.OpenFile(file, os.O_RDONLY, 0666)读数据// 创建地址按照 4k 对齐的内存块 buffer : directio.AlignedBlock(directio.BlockSize) // 把文件数据读到内存块中 _, err : io.ReadFull(fp, buffer)
内核缓冲区和用户缓冲区之间的传输优化
到目前为止我们讨论的 zero-copy技术都是基于减少甚至是避免用户空间和内核空间之间的 CPU 数据拷贝的虽然有一些技术非常高效但是大多都有适用性很窄的问题比如 sendfile()、splice() 这些效率很高但是都只适用于那些用户进程不需要再处理数据 的场景比如静态文件服务器或者是直接转发数据的代理服务器。
前面提到过的虚拟内存机制和mmap等都表明通过在不同的虚拟地址上重新映射页面可以实现在用户进程和内核之间虚拟复制和共享内存因此如果要在实现在用户进程内处理数据这种场景比直接转发数据更加常见之后再发送出去的话用户空间和内核空间的数据传输就是不可避免的 既然避无可避那就只能选择优化了。
两种优化用户空间和内核空间数据传输的技术
动态重映射与写时拷贝 (Copy-on-Write)缓冲区共享 (Buffer Sharing)
写时拷贝 (Copy-on-Write)
前面提到过过利用内存映射(mmap)来减少数据在用户空间和内核空间之间的复制通常用户进程是对共享的缓冲区进行同步阻塞读写的这样不会有线程安全 问题但是很明显这种模式下效率并不高而提升效率的一种方法就是异步地对共享缓冲区进行读写 而这样的话就必须引入保护机制来避免数据冲突 问题COW (Copy on Write) 就是这样的一种技术。
COW 是一种建立在虚拟内存重映射技术之上的技术因此它需要 MMU 的硬件支持MMU 会记录当前哪些内存页被标记成只读当有进程尝试往这些内存页中写数据的时候MMU 就会抛一个异常给操作系统内核内核处理该异常时为该进程分配一份物理内存并复制数据到此内存地址重新向 MMU 发出执行该进程的写操作。
下图为COW在Linux中的应用之一: fork / clonefork出的子进程共享父进程的物理空间当父子进程有内存写入操作时 read-only内存页发生中断将触发的异常的内存页复制一份 (其余的页还是共享父进程的)。 局限性
COW 这种零拷贝技术比较适用于那种多读少写从而使得 COW 事件发生较少的场景 而在其它场景下反而可能造成负优化因为 COW事件所带来的系统开销要远远高于一次 CPU 拷贝所产生的。
此外在实际应用的过程中为了避免频繁的内存映射可以重复使用同一段内存缓冲区因此你不需要在只用过一次共享缓冲区之后就解除掉内存页的映射关系而是重复循环使用从而提升性能。
但这种内存页映射的持久化并不会减少由于页表往返移动/换页和 TLB flush所带来的系统开销因为每次接收到 COW 事件之后对内存页而进行加锁或者解锁的时候内存页的只读标志 (read-ony) 都要被更改为 (write-only)。
COW 的实际应用
Redis 的持久化机制
Redis 作为典型的内存型应用一定是有内核缓冲区和用户缓冲区之间的传输优化的。
Redis 的持久化机制中如果采用 bgsave 或者 bgrewriteaof 命令那么会 fork 一个子进程来将数据存到磁盘中总体来说Redis 的读操作是比写操作多的在正确的使用场景下因此这种情况下使用 COW 可以减少 fork() 操作的阻塞时间。
语言层面的应用
写时复制的思想在很多语言中也有应用相比于传统的深层复制能带来很大性能提升比如 C 98 标准下的 std::string 就采用了写时复制的实现
std::string x(Hello);
std::string y x; // x、y 共享相同的 buffer
y , World!; // 写时复制此时 y 使用一个新的 buffer// x 依然使用旧的 bufferGolang中的string, slice也使用了类似的思想在复制 / 切片等操作时都不会改变底层数组的指向变量共享同一个底层数组仅当进行append / 修改等操作时才可能进行真正的copyappend时如果超过了当前切片的容量就需要分配新的内存。 缓冲区共享 (Buffer Sharing)
从前面的介绍可以看出传统的 Linux I/O接口都是基于复制/拷贝的数据需要在操作系统内核空间和用户空间的缓冲区之间进行拷贝。在进行 I/O 操作之前用户进程需要预先分配好一个内存缓冲区使用 read() 系统调用时内核会将从存储器或者网卡等设备读入的数据拷贝到这个用户缓冲区里而使用 write() 系统调用时则是把用户内存缓冲区的数据拷贝至内核缓冲区。
为了实现这种传统的 I/O 模式Linux 必须要在每一个 I/O 操作时都进行内存虚拟映射和解除。这种内存页重映射的机制的效率严重受限于缓存体系结构、MMU 地址转换速度和 TLB 命中率。如果能够避免处理 I/O 请求的虚拟地址转换和 TLB 刷新所带来的开销则有可能极大地提升 I/O 性能。而缓冲区共享就是用来解决上述问题的一种技术说实话我觉得有些套娃的味道了。
操作系统内核开发者们实现了一种叫 fbufs 的缓冲区共享的框架也即快速缓冲区 Fast Buffers 使用一个 fbuf 缓冲区作为数据传输的最小单位使用这种技术需要调用新的操作系统 API用户区和内核区、内核区之间的数据都必须严格地在 fbufs 这个体系下进行通信。fbufs 为每一个用户进程分配一个 buffer pool里面会储存预分配 (也可以使用的时候再分配) 好的 buffers这些 buffers 会被同时映射到用户内存空间和内核内存空间。fbufs 只需通过一次虚拟内存映射操作即可创建缓冲区有效地消除那些由存储一致性维护所引发的大多数性能损耗。
共享缓冲区技术的实现需要依赖于用户进程、操作系统内核、以及 I/O 子系统 (设备驱动程序文件系统等)之间协同工作 。比如设计得不好的用户进程容易就会修改已经发送出去的 fbuf 从而污染数据更要命的是这种问题很难 debug。虽然这个技术的设计方案非常精彩但是它的门槛和限制却不比前面介绍的其他技术少首先会对操作系统 API 造成变动需要使用新的一些 API 调用其次还需要设备驱动程序配合改动还有由于是内存共享内核需要很小心谨慎地实现对这部分共享的内存进行数据保护和同步的机制而这种并发的同步机制是非常容易出 bug 的从而又增加了内核的代码复杂度等等。因此这一类的技术还远远没有到发展成熟和广泛应用的阶段目前大多数的实现都还处于实验阶段 。 总结
从早期的I/O到DMA解决了阻塞CPU的问题而为了省去I/O过程中不必要的上下文切换和数据拷贝过程零拷贝技术就出现了。
所谓的零拷贝(Zero-copy)技术就是完完全全不需要在内存层面拷贝数据省去CPU搬运数据的过程。
零拷贝技术的文件传输方式相比传统文件传输的方式减少了 2 次上下文切换和数据拷贝次数只需要 2 次上下文切换和数据拷贝次数就可以完成文件的传输而且 2 次的数据拷贝过程都不需要通过 CPU2 次都是由 DMA 来搬运 。
总体来看零拷贝技术至少可以把文件传输的性能提高一倍以上 以下是各方案详细的成本对比 零拷贝技术是基于 PageCache 的PageCache 会缓存最近访问的数据提升了访问缓存数据的性能同时为了解决机械硬盘寻址慢的问题它还协助 I/O 调度算法实现了 I/O 合并与预读这也是顺序读比随机读性能好的原因之一这些优势进一步提升了零拷贝的性能。
但当面对大文件传输时不能使用零拷贝因为可能由于 PageCache 被大文件占据而导致「热点」小文件无法利用到 PageCache的问题并且大文件的缓存命中率不高这时就需要使用「异步 I/O direct I/O 」的方式在使用direct I/O时也需要注意许多的坑点 毕竟连Linus也会被 O_DIRECT disturbed 到。
而在更广泛的场景下我们还需要注意到内核缓冲区和用户缓冲区之间的传输优化 这种方式侧重于在用户进程的缓冲区和操作系统的页缓存之间的 CPU 拷贝的优化延续了以往那种传统的通信方式但更灵活。
I/O相关的各类优化自然也已经深入到了日常我们接触到的语言、中间件以及数据库的方方面面通过了解和学习这些技术和思想也能对日后自己的程序设计以及性能优化上有所启发。
