长春做商业平台网站,常熟专业做网站,做网站工作量怎么算,网站开发使用的技术系统性能优化-4 磁盘
磁盘作为计算机中速度最慢的硬件之一#xff0c;常常是系统的性能瓶颈#xff0c;优化磁盘一般能得到明显的提升~
文章以如何高效的传输文件来讨论针对磁盘的优化技术#xff0c;如零拷贝、直接 IO、异步 IO等。 最简单的网络传输 最简单的方式的当然…系统性能优化-4 磁盘
磁盘作为计算机中速度最慢的硬件之一常常是系统的性能瓶颈优化磁盘一般能得到明显的提升~
文章以如何高效的传输文件来讨论针对磁盘的优化技术如零拷贝、直接 IO、异步 IO等。 最简单的网络传输 最简单的方式的当然是找到文件存储的路径创建一个固定的大小的缓冲区每次读取缓冲区大小的文件内容再通过网络 API 发送给客户端重复上述流程直到把文件发送完成。
顺便一提缓冲区的设置还是有必要的java 有单字节的读取写入方式FileInputStream.read()这样会很慢缓冲区可以有效的提升读取文件的性能。
但是这样的性能依旧不是很高原因是这需要进行多次的内容拷贝会导致大量的上下文切换 每次读取发送都经历了 4 次用户态与内核态的上下文切换每次发送的缓存区内容被拷贝了 4 次
接下来就从减少上下文切换次数和减少内存拷贝次数来进行优化
零拷贝
读取磁盘或者操作网卡都由操作系统内核完成。内核负责管理系统上的所有进程它的权限最高工作环境与用户进程完全不同。只要我们的代码执行 read 或者 write 这样的系统调用一定会发生 2 次上下文切换首先从用户态切换到内核态当内核执行完任务后再切换回用户态交由进程代码执行。
因此如果要减少上下文切换次数就要减少系统调用次数。解决方案就是把 read 和 write 系统调用合二为一直接在内核中完成文件的读取和发送可以把原本的 4 次上下文切换减少为 2 次。
那如何减少内存拷贝次数呢对于常见的文件下载场景我们并不需要进程对文件进行处理如添加公司信息等那么用户缓冲区就没有存在的必要直接由 PageCache 拷贝到 Socket 缓冲区就可以这可以把原本的 4 次内容拷贝缩短为 3 次 如果 网卡支持 DMA SG-DMAThe Scatter-Gather Direct Memory Access那么 PageCache 可以直接拷贝到网卡可以再减少一次内存拷贝。 其实这就是零拷贝技术它是操作系统提供的新函数同时接收文件描述符和 TCP socket 作为输入参数这样执行时就可以完全在内核态完成内存拷贝既减少了内存拷贝次数也降低了上下文切换次数。
零拷贝使用户无需关心 socket 缓冲区的大小因为 socket 缓冲区是动态变化的它既用于 TCP 滑动窗口也用于应用缓冲区还受到整个系统内存的影响。综合种种优点零拷贝可以极大的提升文件传输性能。
PageCache 磁盘高速缓存
正常读取文件时是先把磁盘文件拷贝到 PageCache 上再拷贝到进程中。原因是磁盘的读取速度是最慢的而在内存中的 PageCache 速度就会快很多那选择哪些数据复制到内存呢根据时间局部性原理刚被访问的数据在短时间内再次被访问的概率很高用 PageCache 缓存最近访问的数据当空间不足时淘汰最久未被访问的缓存即 LRU 算法。读磁盘时优先到 PageCache 中找一找如果数据存在便直接返回这便大大提升了读磁盘的性能。
对于机械硬盘来说需要旋转磁头到数据所在的扇区再开始顺序读取数据。其中旋转磁头耗时很长为了降低它的影响PageCache 使用了预读功能。也就是即使你可能目前只读 32KB 数据但内核会把后续的部分数据也读取到 PageCache因为这个读取成本很低而如果后续一段时间访问到了这些数据带来的收益是很值得的。
PageCache 在 90% 以上场景下都会提升磁盘性能但在某些情况下PageCache 会不起作用甚至由于多做了一次内存拷贝造成性能的降低。
先说结论在读取大文件时不应使用 PageCache进而也不应使用零拷贝技术处理。
当用户访问大文件时内核就会把它们载入到 PageCache 中这些大文件很快会把有限的 PageCache 占满。一方面这些大文件被再次访问的概率其实很低耗费 CPU 多拷贝到 PageCache 一次另一方面大文件占用 PageCache 会导致热点小文件无法被加载到 PageCache 中读取的速度变慢。
比如视频文件通常按时间顺序播放播放器只会按需加载一定长度的视频数据。虽然文件本身很大但只有少部分数据会在某一时间点内被访问到其余的数据部分在播放过程中可能根本不会被访问到。某些大数据库文件也是按顺序或按块读取的而数据库的查询操作通常集中在特定区域或范围内。大文件的其他部分可能在较长时间内不会被访问导致它们在 PageCache 中的缓存效果差。
那么高并发场景下该怎么处理大文件呢
异步 IO 直接 IO
高并发场景处理大文件时应当使用异步 IO 和直接 IO 来替换零拷贝技术。
当调用 read 方法读取文件时实际上 read 方法会在磁盘寻址过程中阻塞等待导致进程无法并发地处理其他任务如下图所示 异步 IO异步 IO 既可以处理网络 IO也可以处理磁盘 IO这里我们只关注磁盘 IO把读操作分为两部分前半部分向内核发起读请求但不等待数据就位就立刻返回此时进程可以并发地处理其他任务。当内核将磁盘中的数据拷贝到进程缓冲区后进程将接收到内核的通知再去处理数据这是异步 IO 的后半部分。如下图所示 异步 IO 并没有把数据拷贝到 PageCache 中这其实是异步 IO 实现上的缺陷。经过 PageCache 的 IO 我们称为缓存 IO它与虚拟内存系统耦合太紧导致异步 IO 从诞生起到现在都不支持缓存 IO。绕过 PageCache 的 IO 是个新物种我们把它称为直接 IO。对于磁盘异步 IO 只支持直接 IO。
直接 IO 的应用场景为
应用程序已经实现了磁盘文件的缓存不需要 PageCache 再次缓存引发额外的性能消耗。比如 MySQL 等数据库就使用直接 IO高并发下传输大文件
缺点为无法享受 PageCache 造成的性能提升内核会缓存尽量多的连续IO在 PageCache 中合并为一个更大的 IO 发给磁盘减少磁盘的寻址操作内核也会预读后续的 IO 放在 PageCache 中减少磁盘操作
总结
零拷贝技术基于 PageCache缓存最近读的数据合并读取和发送的系统调用能够有效减少传输文件过程中的上下文切换次数和内存拷贝次数同时最大程度利用 socket 缓冲区。但缺点是用户进程无法对文件做任何修改比如压缩后再发送。当文件大小超过某个阈值后PageCache 还可能引发副作用因此实践中通常会设定一个文件大小阈值针对大文件使用异步 IO 和直接 IO而对小文件使用零拷贝( 例如 Nginx 的 directio 指令)。
文件传输场景中的优化可以大概分为三个方向
减少磁盘工作量PageCache减少 CPU 工作量 直接 IO提高内存利用率零拷贝
