对于超低延迟SSD,IO调度器已经过时了吗?-part2

2024-01-24 02:12

本文主要是介绍对于超低延迟SSD,IO调度器已经过时了吗?-part2,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

为了进行这项研究,他们设计了一套严谨的实验方法论,包括在配备了高速Intel Optane P4801X Series NVMe SSD的服务器上执行一系列微观和宏观基准测试,同时监测系统能耗情况。这些测试涵盖了多种工作负载场景,从单一进程提交大量请求至多租户环境下的混合随机读写请求,旨在全面评估不同I/O调度器在实际应用场景中的表现。

图片

在研究中,实验工作负载的设计旨在全面评估I/O调度器对超低延迟存储设备性能和能源效率的影响。实验采用微观基准测试(Microbenchmarks)和宏观基准测试(Macrobenchmarks)两种方法来分析不同场景下的存储系统极限。

微观基准测试主要用于深入分析存储系统的极限性能,通过针对性地模拟单一或一组特定的I/O操作来测量系统的响应时间和吞吐量。例如,在本研究中,研究人员使用了Flexible IO Tester (fio) 工具生成了一系列针对不同I/O调度器的微基准工作负载,包括单租户和多租户场景下的随机读写请求,并且控制队列深度、IO类型和大小等因素,以精确衡量调度器对单个I/O请求处理的影响。

微观基准测试使用了灵活的IO测试工具fio版本3.31,并利用io_uring作为IO接口,该接口因其高效、异步IO能力及广泛应用而被选择。实验涉及四种不同的I/O调度器:none、mq-deadline、kyber和bfq,每个工作负载都针对这四种调度器重复执行并取五次测试结果的平均值以确保准确性。

图片

微观基准测试结果显示,实验通过使用单租户和多租户场景下的读、写以及混合(50%读取和50%写入)工作负载,对比了none、mq-deadline、kyber和bfq这四种Linux内核自带的I/O调度器在IOPS(每秒输入/输出操作次数)方面的表现。none模式表现出最佳的IOPS性能,这意味着采用I/O调度器并未带来预期的性能提升,反而可能降低了系统的吞吐能力。对于中位数延迟和尾部延迟等其他性能指标,研究也得出了相似的趋势。

图片

同时,通过测量完成100万次I/O操作时系统总能耗,结果显示无调度器none同样在能效方面具有优势或与其它调度器相当。在许多情况下,相比bfq调度器,无调度器none模式能够在每百万次I/O操作上节省大约200焦耳的能量消耗。这是因为无调度器可以更快地完成相同的工作负载,而非直接导致硬件执行阶段功耗降低,从而允许系统更早进入空闲状态,并有可能提前切换到更低功率的状态。

此外,研究还考虑了混合请求大小(4 KB和8 KB)、不同的I/O接口及读写比例的变化情况,但无论何种配置下,I/O调度器都没有为性能或能源效率提供任何明显益处。总的来说,基于Intel Optane SSD的实验数据表明,I/O调度器在ULL存储设备上的应用实际上削弱了系统性能并降低了能源效率。尽管如此,操作系统确保应用程序公平访问硬件资源的角色仍然重要,因此未来的研究需要进一步探讨I/O调度器在ULL存储环境中如何实现公平性以及其他技术如闪存基ULL SSD上的价值。

宏观基准测试则更侧重于实际应用环境中的表现。研究人员选择了RocksDB这一广泛使用的键值存储数据库作为真实应用场景,它特别适合模拟超低延迟环境下键值查找操作的优化,因此更能体现I/O调度器对ULL设备性能的影响。利用db_bench工具生成宏观基准测试数据,首先创建了一个接近饱和容量的RocksDB数据库,然后执行readrandom工作负载模拟大量数据库查询请求过程。除了记录数据库负载强度,研究者还通过Linux内核提供的`/proc/diskstats`接口精确测量来自设备层面的I/O请求数量和带宽,并结合Onset HOBO UX120-018 Data Logger监控整个实验过程中系统的能耗,以探究I/O调度器对系统能效的影响。

图片

研究者使用RocksDB键值存储作为宏观基准工具,进一步验证了I/O调度器对超低延迟(ULL)存储设备性能和能耗的影响。具体来说,他们运用db_bench工具生成随机读取键值查找的工作负载,并记录不同I/O深度下的性能表现(以IOPS衡量)以及能量消耗(每百万次IO操作的焦耳数)。结果显示,在各种不同的I/O强度条件下,无论是在读取、写入还是混合(50-50%读写比)场景下,无调度器none模式表现出最优的性能(即最高的IOPS),优于其他三种调度器mq-deadline、kyber和bfq的表现。

总的来说,研究团队通过实验证明,在现今超低延迟存储时代,传统的I/O调度策略不仅没有为性能优化带来帮助,反而增加了延迟并影响到吞吐率及能源效率。这提示我们,对于超低延迟存储设备,应当重新评估I/O调度器的作用,并根据具体应用场景和技术特性来决定是否继续使用它们以改善性能和能效。

小编每日撰文不易,如果您看完有所受益,欢迎点击文章底部左下角“关注”并点击“分享”、“在看”,非常感谢!

精彩推荐:

  • 浅析CXL P2P DMA加速数据传输的原理

  • HDD回暖于2024,与SSD决战于2028

  • 如何解决NAND系统性能问题?

  • 浅析NVMe key per IO加密技术

  • PCIe 6.0生态业内进展分析总结

  • 浅析PCIe 6.0功能更新与实现的挑战

  • 年度总结|存储随笔2023年度最受欢迎文章榜单TOP15

  • NVMe SSD IO压力导致宕机案例解读

  • 过度加大SSD内部并发何尝不是一种伤害

  • NVMe over CXL技术如何加速Host与SSD数据传输?

  • FIO测试参数与linux内核IO栈的关联分析

  • 为什么QLC NAND才是ZNS SSD最大的赢家?

  • SSD在AI发展中的关键作用:从高速缓存到数据湖

  • 浅析不同NAND架构的差异与影响

  • SSD基础架构与NAND IO并发问题探讨

  • 字节跳动ZNS SSD应用案例解析

  • SSD数据在写入NAND之前为何要随机化?

  • 深度剖析:DMA对PCIe数据传输性能的影响

  • NAND Vpass对读干扰和IO性能有什么影响?

  • HDD与QLC SSD深度对比:功耗与存储密度的终极较量

  • NVMe SSD:ZNS与FDP对决,你选谁?

  • 浅析Relaxed Ordering对PCIe系统稳定性的影响

  • 实战篇|浅析MPS对PCIe系统稳定性的影响

  • 浅析PCI配置空间

  • 浅析PCIe系统性能

  • 存储随笔《NVMe专题》大合集及PDF版正式发布!

这篇关于对于超低延迟SSD,IO调度器已经过时了吗?-part2的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/638241

相关文章

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

ActiveMQ—消息特性(延迟和定时消息投递)

ActiveMQ消息特性:延迟和定时消息投递(Delay and Schedule Message Delivery) 转自:http://blog.csdn.net/kimmking/article/details/8443872 有时候我们不希望消息马上被broker投递出去,而是想要消息60秒以后发给消费者,或者我们想让消息没隔一定时间投递一次,一共投递指定的次数。。。 类似

Java IO 操作——个人理解

之前一直Java的IO操作一知半解。今天看到一个便文章觉得很有道理( 原文章),记录一下。 首先,理解Java的IO操作到底操作的什么内容,过程又是怎么样子。          数据来源的操作: 来源有文件,网络数据。使用File类和Sockets等。这里操作的是数据本身,1,0结构。    File file = new File("path");   字

springboot体会BIO(阻塞式IO)

使用springboot体会阻塞式IO 大致的思路为: 创建一个socket服务端,监听socket通道,并打印出socket通道中的内容。 创建两个socket客户端,向socket服务端写入消息。 1.创建服务端 public class RedisServer {public static void main(String[] args) throws IOException {

一种改进的red5集群方案的应用、基于Red5服务器集群负载均衡调度算法研究

转自: 一种改进的red5集群方案的应用: http://wenku.baidu.com/link?url=jYQ1wNwHVBqJ-5XCYq0PRligp6Y5q6BYXyISUsF56My8DP8dc9CZ4pZvpPz1abxJn8fojMrL0IyfmMHStpvkotqC1RWlRMGnzVL1X4IPOa_  基于Red5服务器集群负载均衡调度算法研究 http://ww

Java基础回顾系列-第七天-高级编程之IO

Java基础回顾系列-第七天-高级编程之IO 文件操作字节流与字符流OutputStream字节输出流FileOutputStream InputStream字节输入流FileInputStream Writer字符输出流FileWriter Reader字符输入流字节流与字符流的区别转换流InputStreamReaderOutputStreamWriter 文件复制 字符编码内存操作流(

Golang进程权限调度包runtime

关于 runtime 包几个方法: Gosched:让当前线程让出 cpu 以让其它线程运行,它不会挂起当前线程,因此当前线程未来会继续执行GOMAXPROCS:设置最大的可同时使用的 CPU 核数Goexit:退出当前 goroutine(但是defer语句会照常执行)NumGoroutine:返回正在执行和排队的任务总数GOOS:目标操作系统NumCPU:返回当前系统的 CPU 核数量 p

MySQL主从同步延迟原理及解决方案

概述 MySQL的主从同步是一个很成熟的架构,优点为: ①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力; ②在从主服务器进行备份,避免备份期间影响主服务器服务; ③当主服务器出现问题时,可以切换到从服务器。 相信大家对于这些好处已经非常了解了,在项目的部署中也采用这种方案。但是MySQL的主从同步一直有从库延迟的问题,那么为什么会有这种问题。这种问题如何解决呢? MyS

android java.io.IOException: open failed: ENOENT (No such file or directory)-api23+权限受权

问题描述 在安卓上,清单明明已经受权了读写文件权限,但偏偏就是创建不了目录和文件 调用mkdirs()总是返回false. <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/><uses-permission android:name="android.permission.READ_E

文章解读与仿真程序复现思路——电力自动化设备EI\CSCD\北大核心《考虑燃料电池和电解槽虚拟惯量支撑的电力系统优化调度方法》

本专栏栏目提供文章与程序复现思路,具体已有的论文与论文源程序可翻阅本博主免费的专栏栏目《论文与完整程序》 论文与完整源程序_电网论文源程序的博客-CSDN博客https://blog.csdn.net/liang674027206/category_12531414.html 电网论文源程序-CSDN博客电网论文源程序擅长文章解读,论文与完整源程序,等方面的知识,电网论文源程序关注python