存储系统时延问题分析与测量

11版权声明ODCC（开放数据中心委员会）发布的各项成果，受《著作权法》保护，转载、摘编或利用其它方式使用ODCC成果中的文字或者观点的，应注明对于未经著作权人书面同意而实施的剽窃、复制、修改、销售、改编、汇编和翻译出版等侵权行为，ODCC及有关单位将追究其法律责任，感谢各单位I编写组发生的范围是几千台服务器，数万个存储部一天发生几次，这个发生频率是实验室测试存储部件的时延问题是数据中心性能表现的一个基础问题。需V存储系统时延问题分析与测量 I II IV 1 2 6 15 21 1存储系统时延问题分析与测量存储系统时延问题分析与测量一、存储系统时延问题的历史和现状存储系统的时延，在客户-服务模型上表现为服务请求端发出命可能发生时延的部分，存在于存储系统的层级结构中的所有传访问控制，资源的申请/释放，纠错，重传等行为，由此导致的时延而对于时延问题的解法更多地表现为一个取舍的行为，这样就1存储系统时延问题分析与测量在以硬盘为主要载体的时期，存储系统的读写命令时延在1秒到30秒之间，这个时间主要由于切换读写操作位置需要进行磁盘的寻道操作，而寻道操作需要硬盘至少旋转一周才能完成。在SSD用户对时延的感知并非是直接的。由于用户是通过文件打开，关闭，读写的操作使用硬盘和SSD，通常的文件操作需要的时间远大于一个单一的读写指令完成的时间，因此用户对存储器的时延的感觉首先来自于存储部件的带宽。如拷贝一个文件尺寸为1G的文件通常需要10秒左右的时间。而此时主机与存储部件的命令和数据二、存储器时延的产生原因硬盘和SSD的命令时延的发生机理，与用户的普遍感知是不同的。在绝大多数状况下，硬盘和SSD的单个读写命令响应时间在1秒以内，但是硬盘和SSD的设计的最长命令响应时间并不是如此。使用sg_opcoeds-R指令可以看到SASSSD的每个指令的标准响应多数指令的最长响应时间为5秒，但是很多指令的最长响应时间能2这些最长命令响应时间发生几率很低，但是却是存储部件设计的必须。硬盘和SSD的数据存储机制的底层物理机制是一些模拟量3存储系统时延问题分析与测量这些模拟量的生成，保持和测量对应的是存储器的写入，存储和读取操作。这些操作对应的是大量连续的电压和电流的模拟量的信号处理过程，这些过程都会在各个环节发生抖动，偏移并在数模转换和模数转换过程中发生误码，这些误码需要相应的纠错机制进行处理。大多数的情况下处理过程是不会造成可测量到的时延，但是如果瞬时的误码较大，就会激发一系列的重试过程。这些重试过程对于硬盘和SSD的数据可靠性是必需的，但是也会发生相应的可下图示意的是一个硬盘的一次重试的流程图。这个重试的过程在设计中可以重复255次，如果每次平均是12实际应用中的问题在于，大多数的应用程序和驱动程序对这些硬盘和SSD设计中需要的命令最长响应时间的处理机制并不完善，4存储系统时延问题分析与测量常见的处理方法就是几次重试之后就丢弃文件或者丢弃存储卷，这在绝大多数的测试场景和用户使用场景，这些命令所对应的最长命令响应时间是不会遇到的。但是如果驱动程序的设计以及应用程序的设计没有考虑到对这些最大时延进行恰当处理，就会出现丢失数据甚至丢失存储卷的严重问题。在读写操作时根据可能的最大响应时间设计响应的延时处理机制和等待机制，是驱动程序设计和这种由于存储部件基于对数据读写一致性，数据安全性的保证而发生的时延是硬盘和SSD固件设计必须做的，因为读出和写入数5存储系统时延问题分析与测量三、时延测试方法，测试模型对时延的测试首先是测试与用户感知对应的文件操作的时延。在操作系统中对硬盘和SSD时延的测试工具分为内核态的测试工具在工程中还会采用分析仪来测量数据通道的指令，数据和状态在用户态基于文件系统读写指令完成时间的工具软件的测量原理是对某一个或一个系列的打开文件，进行文件读写，关闭文件等操作指令计时，或者打开一个裸设备进行读写操作并对指令完成时在内核态的测试工具是由操作系统提供的计数器接口实现的。6存储系统时延问题分析与测量其中，iozone可以测量文件系统下的文件操作命令响应时间。fio可以对通过文件系统的文件操作以及不通过文件系统直接调用内Linux系统中现有的测试工具是可以用来收集时延有关问题的状blocktrace工具包debugfssysstat工具里有iostat和sar工具可以用来监控读写的等待时间，我们可以使用sysstat工具来监视Linux系统的性能，包括磁盘I/O性能。sysstat是一个强大的日志记录和监视工具，可用于监视系统性能并解决问题。它可以记录和跟踪Linux系统中发生的几乎所7存储系统时延问题分析与测量数据分布状况，这个时延是从文件系统调用开始到设备的读写操作同时，我们可以从atop的历史测试数据获得主机到设备间的数使用blktrace可以获得更加详细的单步骤的命令响应时间。使用debugfs里面的nvmeeventtrace可以获得单个nvme指令iostat-x可以看到从系统加电以来的io状况。iostat-xmdn可以实时每n秒间的io状况。8iostat是一个用于监控CPU利用率和磁盘I/O活动的工具，它可以显示每个设备的平均服务时间（svctm）和平均等待时间），包括寻道时间、旋转延迟和数据传输时间。平均等待时间（await）我们可以使用sar工具来监控磁盘I/O活动并获取有关设备的平均等待时间（await）的信息。sar是sysstat工具包中的一个实用程要使用sar来监控磁盘I/O活动并获取有关设备的平均等待时间9存储系统时延问题分析与测量这个命令会每秒运行一次sar，并显示磁盘I/O活动的信息。在请注意，要使用sar工具，用户需要先安装sysstat软件包并启用数据收集。我们可以使用用户的发行版的包管理器来安装sysstat我们可以使用atop工具来监控SSD的实时性能参数。atop是一个用于监控系统资源使用情况的工具，它可以显示CPU、内存、磁atop工具可以实时监控系统块设备的io状态，同时监控cpu,内atop可以在后台运行，收集cpu,内存，存储器的使用率，占用情况。默认10分钟一个记录。记录可以看到每个进程的命令行要使用atop来监控SSD的实时性能参数，我们可以在终端中运运行atop命令后，用户将看到一个交互式界面，其中显示了系统资源的实时使用情况。我们可以按d键来切换到磁盘视图，查看在磁盘视图中，我们可以看到每个设备的读写速度、繁忙时间百分比和I/O请求队列长度等信息。这些信息可以帮助用户了解请注意，要使用atop工具，用户需要先安装atop软件包。我们可以使用用户的发行版的包管理器来安装atop软件包。HTOP可以进一步跟踪到进程的系统调用，IOTOP可以实时记录和显示系统的IO.可以定时记录io状态。这些软件包在发行版debugfsLinux的内核debugfs可以看到主机对nvme盘发出的nvme指Debugfs是一个文件系统，用于在Linux内核中提供调试信息。它允许用户查看文件系统的内部状态，包括文件系统的超级块、inode、mount-tdebugfsnone/sys/kernel/debdebugfs-R"stat<file>"/devdebugfs-R"dump<file><outfile>"/devblocktrace和blockmon使用blkiomon来动态显示IO栈情况，命令如下：。存储系统时延问题分析与测量一个I/O请求进入blocklayer之后，可能会经历下面的过程：Split:可能会因为I/O请求与扇区边界未对齐、或者size太大而Merge:可能会因为与其它I/O请求的物理位置相邻而合并被IOScheduler依照调度策略发送给driver被driver提交给硬件，经过HBA、电缆（光纤、网线等）、交换机（SAN或网络）、最后到达存储设备，设备完成IO请求之后G2I–IO请求进入IOScheduler所消耗的时间，包括merge的时D2C–IO请求在driver和硬件上所消耗的时间；Q2C–整个IO请求所消耗的时间(Q2I+I2D+D2C=Q2C)，相I2D的数值可以作为IOScheduler性能的指标。通常具有较大的Smartlog的意义在于记录盘的基本信息，部件的modulename,系列号，固件版本，读写量，如有出现过错误，会有错误类型的统Telemetrylog是通用的nvme盘的debug信息，如果在抓取之前出现过nvme盘的固件需要处理的异常，如不可恢复读错误，或者SSD内部由于误码，噪声，电压偏移造成的读错误是造成SSD命令响应时间变长的主要原因，而且随之SSD盘的写入量增加造成存储系统时延问题分析与测量的每个存储单元的平均retention时间减小，这种重读的发生几率会比较高。对系统中所有SSD的latency时间的跟踪可以发现这种变四、时延测试结果分析可能发生时延问题的节点，存在于存储系统的层级结构中的所访问控制，资源的申请/释放，纠错，重传等行为，由此导致的时延使用iostat看到的时延数据，在使用散碎数据块的状态下，使用libaio这个异步io引擎，记录了较高的时延。但是同时可以看到，系统在时延较高时iops并没有下降而且还有总体较高的数据吞吐量。这是因为异步io的设计思想就是通过数据的重排获得较高的带这个例子是在大数据块和小数据块同时传输时，由于S以同等优先级处理所有的队列，因此两个队列具有相同的iops。这样使用小数据块的队列由于没有做io合并，虽然命令队列是连续的iozone的测试结果以及分析：在运行用直接IO参数运行iozone的同时使用iostat抓取主机对SSD的读写指令，发现在运行iozone时，虽然iozone测试发生的读写数据量是对等的，但是在iostat中看到只有写数据没有读数据的操作。因此下表中的都操作的带宽差异以及对应的时延，是发生在主机的内存和文件系统的驱动之间，是由文件系统对内存中块设备读写缓存的操作导致，而不是块设备对SSD用fio进行jesd219数据块分布类型读写压力测试一天，运行过程中抓取iostat数据进行分析，可以看到读写操作的延时在逐渐增加。这个延时的增加与SSD内部数据的块分配表项目的不连续对一个使用了一段时间的SSD进行读性能扫描，可以得到如下的结果示意图图中可见SSD的读指令响应时间是弥散的。原因就是这种数据的离散以及后台进行的介质扫描和SSD的GC操作对硬盘和SSD的性能影响可以使用总线分析仪进行深入分析。总线分析仪的时延显示的是数据链路上数据传输特性。下图中蓝线表示的是数据传输时延。阶梯状的增加是当时总线上没有数据传输，而前面的数据传输所对应的时延随着时间的增加，进行非数据传输的信存储系统时延问题分析与测量总线分析仪看到的命令和信元的时延.使用总线分析仪抓取主机到存储器的命令序列是目前业界主流的debug方式。这种方式不能实时对大批量的生产状态的存储部件进行监控和命令流的抓取。存储系统时延问题分析与测量CentOS4.18及以下的版本内核存在一个跟NVMeSSD相关的漏洞，会概率性的导致IO阻塞问题。具体表现就是iostat的util一直显示100%，但是其他IO参数几乎都是0（除了队列深度这一项），经过检查kernel的更新文档，采用新版本的kernel或者修改NVMe五、减低时延的技术路线以及技术发展展望存储系统时延问题分析与测量避免，只能通过增加数据封装的复杂性，采用能容忍更小信噪比的数据解码算法来减少。对于硬盘，由于高温和振动会造成读数据过程的物理量抖动从而增加误码，那么减低硬盘的温度以及减少硬盘除了采用高速和高复杂