如何快速debug定位SSD延迟问题？

2022-11-19 184

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： IO延迟分析是一项复杂而有趣的工程，需要带着好奇深挖每一个信息，总会有不同的风景。

一块固态硬盘设计背后，有硬件控制器，NAND闪存颗粒、DRAM，还有固件FTL算法等。SSD设计的本身其实是一件特别复杂的过程，需要考虑各种客户需求且要保证可靠性、性能、稳定性。

针对SSD的相关性能测试，SNIA也有专门针对SSD相关测试SPEC，同时各个SSD厂商也有很多独有的测试用例（一家SSD厂商的测试用例很多也是靠多年的填坑积累完善的）。现在看似SSD行业门槛很低，随便买个主控、NAND/DRAM颗粒就可以组装了（的确市场上有鱼龙混杂，有投机倒把之辈）。但是，如何真心要做出一款性能稳定的SSD，不但需要强大的技术实力，更需要丰富的经验积累。

SSD出厂之前经过了严格的测试，到了用户手里，是不是就不会有延迟问题呢？答案是否定的。比如下面一幅图就是业内最经典案例，4KB随机写最开始性能会很高，因为SSD内部还没启动GC，当SSD随机预测完全后，此时4KB随机写才是稳态的性能。很多客户在拿到SSD后测试的数据和经过一段时间测试后的会出现明显的差异，再不了解SSD随机预热稳态的机理时，就会出现很多误解。用户使用方式，对延迟问题的定义也会有存在很大的差异。经常会出现一种情况：“IO延迟，在某些场景，是一种不是问题的问题！”

不同的客户的业务场景，千差万别，SSD的设计也不无法100%兼顾所有复杂的IO负载类型。出现延迟问题并不可怕，可怕的是无从入手，不能快速debug定位延迟的来源。

IO延迟定位前，我们先了解下Windows和Linux内核中的IO堆栈，简单理解IO的产生、流动过程、最终目的地。

第一图：Windows环境中IO堆栈

第二图：Linux环境中IO堆栈

从上面的IO堆栈示意图来看：

Windows和Linux IO堆栈的基本逻辑是一致的
IO在软件层产生，经过文件系统、内核模块、驱动层，最终达到硬件存储设备SSD。

IO延迟通常是应用客户先感知到，用户也是从最上层感知，但是经过这么层的路径，最终的延迟来源是再哪一层？这个并不能很清晰的展示，这也导致很多场景下，SSD也成为了背锅侠，不管什么原因导致的IO异常，首先都会被先扣在SSD头上。所以，快速IO定界也是帮助SSD解放“背锅”压力的有效办法。

目前用于IO延迟定界场景的软件，也有多种：

在Windows场景下：开源的工具有perfmon，以及SNIA SSSI Workload I/O Capture Program (WIOCP) 推荐的hiomon，可以记录随机读写、顺序读写的延迟、队列深度QD，IO延迟统计等。

Linux场景下，常用的经典开源工具也有blktrace，可以记录从IO产生，到最终返回的时间，跟IO分析工具iostat的延迟来源保持一致，与iostat一起搭配定位延迟问题最为合适。在与硬件定位过程中，I2D代表进入内核IO workqueue队列到发送给硬件的时间。D2C代表驱动IO下发到硬件完成IO返回的时间。