首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >你所不知道到的NVMe

你所不知道到的NVMe

作者头像
Linux阅码场
发布2019-06-04 11:28:53
2.7K0
发布2019-06-04 11:28:53
举报
文章被收录于专栏:LINUX阅码场LINUX阅码场

来自内核月谈 | 查斌 马涛

NVMe SSD具有高性能、低时延等优点,是目前存储行业的研究热点之一,但在光鲜的性能下也同样存在一些没有广为人知的问题,而这些问题其实对于一个生产系统而言至关重要,例如:

  • QoS无法做到100%保证;
  • 读写混合情况下,与单独读相比,性能下降严重,且读长尾延迟比较严重;

所以如何利用好NVMe盘的性能,并更好的为业务服务,我们需要从硬件,Linux内核等多个角度去剖析和解决。

从内核中NVMe IO框架来看其中存在的问题

当前Linux内核中对NVMe SSD的访问是通过MQ框架来实现的,接入NVMe驱动后直接略过IO调度器,具体实现上来说是从block layer中的通用块层回调make_request从而打通上下层IO通路。示意图如下,这里面有几个关键的点:

IO发送过程

MQ的框架提升性能最主要的将锁的粒度按照硬件队列进行拆分,并与底层SSD的队列进行绑定,理想的情况每一个CPU都有对应的硬件发送SQ与响应CQ,这样可以并发同时彼此之前无影响。按照NVMe SPEC协议中的标准,硬件最多支持64K个队列,所以理想情况下硬件队列个数将不会是我们需要担心的地方。但是实际情况又如何呢?由于硬件队列的增加会给NVMe SSD带来功耗的增加,所以不同的厂商在设计硬件队列个数时的考量是不同的,比如intel P3600支持32个队列,intel最新的P4500支持16384个,但是SUMSUNG PM963却只支持到8个。那么当CPU的个数超过硬件的队列个数,就会出现多个CPU共用一个硬件队列的情况,对性能就会产生影响。

下面使用SUMSUNG PM963做一个简单的测试:

也就是整个IOPS可以达到50w

如果使用同一个硬件队列

整个IOPS只有44w,性能下降12%,主要原因是多个CPU共用硬件队列进行发送的时候会有自旋锁争抢的影响。所以对于共用硬件队列的情况下,如何绑定CPU是需要根据业务的特点来确定的。

IO响应过程

IO响应过程中最主要问题是中断的balance,由于默认linux中并没有对NVMe的中断进行有效的绑定,所以不同的绑定策略会带来截然不同的性能数据。不过在我们的实际测试中,虽然我们没有做中断的绑定,但是貌似不管是性能还是稳定性的下降并没有那么严重,什么原因呢?根据我们的分析,这里面最主要的原因是(后面也会提到),我们并没有大压力的使用NVMe盘,所以实际的应用场景压力以及队列深度并不大。

从应用本身的IO Pattern来看使用NVMe问题

我们在评测一个NVMe SSD的性能的时候,往往都是通过benchmark工具,例如见1, 见2。

然而这些测试的结果与业务实际使用NVMe SSD看到的性能相比差距很大。原因是因为这些性能测试存在两个比较大的误区,因而并不能反映生产系统的真实情况。

1. 片面夸大了NVMe盘的性能

从上面两篇文章中的测试中我们可以看到,大多数压测中使用的队列深度为128,并且是用libaio这样的异步IO模式来下发IO。但是在实际应用场景中很少有这么大的队列深度。在这种场景下,根据“色子效应”,并不会将NVMe盘的并发性能充分发挥出来。

2. 低估了NVMe的长尾延迟

然而在另外一些场景下,队列深度又会非常高(比如到1024甚至更高),在这种情况下NVMe SSD带来的QoS长尾延迟影响比上面的benchmark的测试又严重得多。

所以综合起来看,这种评测选择了一个看上去没啥大用的场景做了测试,所以得出的结果也对我们实际的应用基本没有参考价值。那么问题出在什么地方么?

问题分析

首先让我们再次强调一下一般评测文章中benchmark进行的测试场景的特点:

  1. 大多是fio工具,开启libaio引擎增加IO压力
  2. 队列深度到128或者256

在这种场景下确实基本都可以将NVMe盘的压力打满。

在展开分析问题的原因之前,我们先看看Linux内核的IO栈。

在实际应用中,VFS提供给应用的接口,从IO的特点来分类,大致上可以分为两类:direct IO与buffer IO。使用direct IO的业务大多在应用本身就已经做了一层cache,不依赖OS提供的page cache。其他的情况大多使用的都是buffer IO。linux kernel中的block layer通过REQ_SYNC与~REQ_SYNC这两种不同的标志来区分这两类IO。大家常用的direct IO这个类型,内核要保证这次IO操作的数据落盘,并且当响应返回以后,应用程序才能够认为这次IO操作是完成的。所以是使用了这里的REQ_SYNC标志,而对应的buffer IO,则大量使用了~REQ_SYNC的标志。让我们一个一个看过去。

direct IO

由于在实际使用方式中AIO还不够成熟,所以大多使用direct IO。但是direct IO是一种SYNC模式,并且完全达不到测试用例中128路并发AIO的效果。 这主要两个方面原因:

direct io在下发过程中可能会使用文件粒度的锁inode->i_mutex进行互斥。

前面说的IO SYNC模式

也就是说,我们很难通过direct IO来达到压满NVMe盘的目的。如果一定要打满NVMe盘,那么一方面要提高进程并发,另外一方面还要提高多进程多文件的并发。而这是生产系统中很难满足的。

buffer IO

我们再来看看buffer IO的特点。下面我使用了比较简单的fio通过buffer IO的模式下发,而且通过rate限速,我们发现平均下来每秒的数据量不到100MB,整个IO的特点如下:

抓取了下submit_bio在每秒的调用次数并分析可以得出,buffer IO在下刷的时候并不会考虑QD的多少,而是类似aio那样,kworker将需要下发的脏页都会bio形式下发,而且不需要等待某些bio返回。注意这里面有一个细节从qusize观察到IO最大值986,并没有达到百K,或者几十K,这个原因是由本身MQ的框架中tag机制nr_request决定,目前单Q设置默认值一般为1024。总之buffer IO这样特点的结果就是突发量的高iops的写入,buffer IO对于应用程序来说是不可见的,因为这是linux kernel的本身的刷脏页行为。但是它带给应用的影响确实可见的,笔者曾经总结过异步IO的延时对长尾的影响,如下图所示,分别是buffer IO与direct IO在相同带宽下延时表现,可以看出这延迟长尾比我们简单的通过fio benchmark测试严重的多,特别是盘开始做GC的时候,抖动更加严重;而且随着盘的容量用着越来越多,GC的影响越来越大,长尾的影响也是越来越严重。

在HDD的时代上面的问题同样会存在,但是为什么没有那么严重,原因主要是HDD大多使用CFQ调度器,其中一个特性是同步、异步IO队列分离。并且在调度过程中同步优先级比较高,在调度抢占、时间片等都是同步优先。

解决问题

前面描述了使用NVMe硬盘的严重性,下面介绍一下如何解决这些问题。 (1)MQ绑定的问题,需要根据当前业务的特点,如果硬件的队列小于当前CPU的个数,尽量让核心业务上跑的进程分散在绑定不同硬件队列的CPU上,防止IO压力大的时候锁资源的竞争。

(2)中断绑定CPU,建议下发的SQ的CPU与响应的CQ的CPU保持一致,这样各自CPU来处理自己的事情,互相业务与中断不干扰。

(3)解决direct IO状态下长尾延迟,因为长尾延迟是本身NVMe SSD Controller带来,所以解决这个问题还是要从控制器入手,使用的方法有WRR(Weight Round Robin),这个功能在当前主流厂商的最新的NVMe SSD中已经支持。

(4)解决buffer IO状态下长尾延迟,可以通过控制NVMe SSD处理的QD来解决,使用的NVME多队列IO调度器,充分利用了MQ框架,根据同步写、读延迟动态调整异步IO的队列,很好的解决buffer io带来的长尾延迟。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-04-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Linux阅码场 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 从内核中NVMe IO框架来看其中存在的问题
  • 从应用本身的IO Pattern来看使用NVMe问题
  • 问题分析
    • direct IO
      • buffer IO
      • 解决问题
      相关产品与服务
      对象存储
      对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档