【译】Linux不同的IO访问方式中,Scylla的选择和依据

【原文】http://www.scylladb.com/2017/10/05/io-access-methods-scylla/
【译文】
大多数服务应用开发者考虑IO时会重点考虑网络IO,因为他们访问的主要资源都是基于网络的,如数据库、对象存储或其他微服务。而数据库开发者则必须考虑文件IO。本文描述了候选方式和如何权衡,以及为什么Scylla选择异步direct IO(AIO/DIO)作为访问访问。

一、访问文件的候选方式

一般Linux服务器有四种访问文件的方式:read/write, mmap, Direct I/O (DIO) read/write, 和异步直接direct I/O (AIO/DIO).

1.1 传统read/write

应用已久的传统方式是使用read和write两个系统调用。在现代的实现中,系统调用read(或其变种pread,readv,preadv等)访问内核,读取一段文件,拷贝数据至调用的进程地址空间。如果所有要访问的数据都在页缓存中,内核会直接拷贝,并立即返回;否则,它需要调度磁盘以读取所需的数据到页缓存中,并阻塞调用线程,当数据可用时,它会恢复线程,并拷贝数据。另一方面,系统调用write会拷贝数据到页缓存中,内核会在某个时间将页缓存写回到磁盘。

传统read/write

1.2 Mmap

一种更现代的替代方案是,以内存映射的方式,使用mmap系统调用,将文件映射到应用程序地址空间中。该操作的效果是,一段地址空间直接对应包含文件数据的页缓存。这个准备步骤完成后,应用程序可以使用进程内存读写指令来访问文件数据。如果请求的数据碰巧在缓存中,内核完全被旁路,读写以内存级速度完成。如果缓存没有需要的数据,则会触发页错误,内核将活动线程变成休眠状态,因为此时该线程需要去读取数据到内存页中。当数据最终可用时,内存管理器受程序控制,最新读取到数据可访问时,相应线程会被唤醒。

mmap

1.3 Direct IO(DIO)

传统的read/write和mmap都需要内核页缓存和内核调度IO。当应用程序希望自己调度IO时(原因稍后解释),它可以使用direct IO。这需要使用标志O_DIRECT来打开文件;进一步的工作是使用通用的读写系统调用,但它们的行为现在会有变化;不访问内存后,会该用直接访问磁盘,这意味着调用线程会被无条件的置为休眠状态。而且磁盘控制器会直接拷贝数据到用户空间,即旁路内核。

Direct IO

1.4 异步Direct IO(AIO/DIO)

异步Direct IO相对于Direct IO有改进,其行为相似,但不阻塞调用线程。应用程序线程使用io_submit系统调用调度direct IO操作,但该线程并不会被阻塞;IO操作与线程执行同时进行。使用独立的系统调用io_getevents来等待结果,并在IO操作完成后收集结果。像DIO一样,内核页缓存也被旁路,磁盘控制器负责拷贝数据到用户空间。

异步Direct IO

二、理解取舍平衡

不同访问方法拥有一些相同的特征,也有一些差异。表1总结来这些特征,具体见下表。

Characteristic R/W mmap DIO AIO/DIO
Cache control kernel kernel user user
Copying yes no no no
MMU activity low high none none
I/O scheduling kernel kernel mixed user
Thread scheduling kernel kernel kernel user
I/O alignment automatic automatic manual manual
Application complexity low low moderate high

2.1 缓存控制

对于read/write和mmap,缓存是内核的职责。大部分系统内存被交给页缓存。内核决定在内存不足时哪个页被淘汰,哪些页需要回写至磁盘,哪些需要预读。应用程序可以使用madvise和fadvise来为内核提供一些指示。

由内核控制缓存的最大优势在于,内核开发者们已经投入几十年和巨大精力以优化缓存算法。这些算法已经被成千上万的不同应用程序使用,且整体而已都是很有效的。然而不足是,这些算法是面向通用目标,没有针对具体应用而优化。内核必须猜测应用程序下一步的动作,既是应用程序知道完全不同,它也没有办法帮助内核猜的更准确。结果是页被错误的淘汰,IO以错误的顺序调度,或者预读的数据在近期不会被访问。

2.2 拷贝和MMU活动

mmap方式的一个好处是,如果数据在内存中,内核会被彻底跳过。内核不需要从内核空间拷贝数据到用户空间或反向拷贝,这样就能减少处理器周期的消耗。这还会改善负载,最大化利用缓存(例如,当存储大小比RAM大小接近1:1)。

当数据不在缓存中,mmap会表现较差。当存储大小比RAM大小明显大于1:1时,这种现象尤会发生。每个载入缓存的页都会引起另一页的淘汰。这些页必须插入页表或从中移除,内核必须扫描页表来找到非活动的页,并把它们作为待淘汰的候选。另外,mmap需要为页表分配内存。在x86处理器上,这会需要0.2%的映射文件大小的内存。这看起来很小,但如果应用程序使用的存储与内存的比达到100:1时,结果是,20%的内存被用来存储页表(0.2% * 100)。

2.3 IO调度

内核控制缓存(mmap和read/write)的问题之一是,应用程序失去对IO调度的控制。内核选择它任何合适的数据块,调度对其的读写。这会导致以下的问题:

  • 写风暴:当内核规划大规模写时,磁盘会忙一段时间,进而导致读延迟。
  • 内核不能区分重要和不重要的IO。后台IO任务会挤垮前台任务,导致它们的延迟。

借助绕开内核页缓存,应用程序会承担IO调度的压力。这并不意味着问题被解决,但意味着问题可以被解决,只要投入足够的重视和努力。

使用Direct IO时,每个线程控制何时执行IO。而内核控制线程运行,以便内核和应用程序共同承担IO工作。使用AIO/DIO,应用程序完成控制何时执行IO。

2.4 线程调度

IO密集型应用程序使用mmap或read/write时不能猜出其缓存的命中率。因此,必须运行大量线程(显著大于所运行的机器的核数)。使线程过少时,它们可能都在等待磁盘运动,处理器利用率会很低。由于每个线程都需要等待磁盘IO,运行的线程数大致为存储子系统并发数乘以一个小系数,以保持磁盘能满负荷运转。如果缓存命中率很高时,这些大数量的线程彼此之间会竞争有限的CPU核数。

使用direct IO,这个问题会得到一定缓和,因为应用程序知道何时线程被IO阻塞、何时能运行,所以应用程序可以根据运行环境,调整运行的线程数。

使用AIO/DIO,应用程序完全控制运行的线程和等待的IO(二者完全隔离),所以它能轻松调整内存、磁盘的使用。

2.5 IO对齐

存储设备属性之一是块尺寸,所有IO必须以块大小的整数倍运行,通常是512或4096字节。使用read/write或mmap时,内核自动对齐;小规模读写会被内核扩展至整个块。
使用DIO时,由应用程序来对齐块。这带来了一定的复杂度,但也提供了一个好处:当512字节对齐就足够时,内核通常需要4096字节对齐,但用户应用程序使用DIO就可以用512字节对齐的方式读取,从而节省小对象的传输带宽。

2.6 应用程序复杂度

前面讨论IO密集型应用程序优先选择AIO/DIO,这个方式伴随着一个显著的成本:复杂度。为应用程序设置缓存管理职责,意味着它能比内核更好的做出选择,做出这些选择需要更少的成本。然而,这些算法需要编写和测试。使用异步IO需要应用程序支持回调方式、协程、或其他相似的方法,经常需要降低很多可用库的复用性。

三、Scylla和AIO/DIO

对于Scylla,我们选择更高性能的选项,AIO/DIO。为了隔离一些涉及的复杂度,我们写了Seastar,这是一个面向IO密集型应用的高性能框架。Seastar抽象了执行AIO的细节,为网络、磁盘、多核通讯提供了通用API。它也提供了回调、协程风格的声明管理,以适应不同的使用用例。

不同领域的Scylla关注不同IO使用方式:

  • 压缩使用应用级预读和后写以提高吞吐量,但绕开应用级缓存是缘于设定其低命中率,同时避免冷数据的冲击)。
  • 查询使用应用控制预读和应用级缓存。应用控预读阻止提前预读,是由于我们提前知道数据在磁盘上的边界。应用级缓存使我们不只可以缓存从磁盘读取的数据,也可以将多个文件的数据合并成一个缓存项。
  • 小规模读按512字节对齐,以减少总线数据传输和延迟。
  • Seastar IO调度器允许我们动态控制压缩和查询的IO率,以满足用户服务等级协议SLA。
  • 独立的IO调度类使commitlog获得需要的带宽,而不会被读抢占。

如果应用直接驱动NVMe以绕过内核,那么AIO/DIO将会是一个好的起点。这也是未来Seastar的特性。

四、结论

我们介绍了在Linux上四种不同类型的磁盘IO的方法,及之间不同的取舍与平衡。使用传统read/write很容易上手,使用mmap会获得内存级性能,但为了获取顶级性能和控制,我们为Scylla选择异步IO。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,529评论 5 475
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,015评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,409评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,385评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,387评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,466评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,880评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,528评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,727评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,528评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,602评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,302评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,873评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,890评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,132评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,777评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,310评论 2 342

推荐阅读更多精彩内容