学步园

说说IO（一）- IO的分层  

IO
性能对于一个系统的影响是至关重要的。一个系统经过多项优化以后，瓶颈往往落在数据库；而数据库经过多种优化以后，瓶颈最终会落到
IO
。而
IO
性能的发展，明显落后于
CPU
的发展。
Memchached
也好，
NoSql
也好，这些流行技术的背后都在直接或者间接地回避
IO
瓶颈，从而提高系统性能。

IO

系统的分层：

 

1.   
   
   三层结构

上图层次比较多，但总的就是三部分。磁盘
（存储）、
VM

（卷管理）和文件系统
。专有名词不好理解，打个比方说：磁盘就相当于一块待用的空地；
LVM
相当于空地上的围墙（把空地划分成多个部分）；文件系统则相当于每块空地上建的楼房（决定了有多少房间、房屋编号如何，能容纳多少人住）；而房子里面住的人，则相当于系统里面存的数据。

 

• 文件系统—数据如何存放？

 

对应了上图的
File
System
和
Buffer Cache
。

File
System

（文件系统）：解决了空间管理的问题

，即：数据如何存放、读取。

Buffer
Cache

：解决数据缓冲的问题。对读，进行
cache
，即：缓存经常要用到的数据；对写，进行
buffer
，缓冲一定数据以后，一次性进行写入。

 

• VM
  —磁盘空间不足了怎么办？

 

对应上图的
Vol Mgmt
。

VM
其实跟
IO
没有必然联系。他是处于文件系统和磁盘（存储）中间的一层。
VM

屏蔽了底层磁盘对上层文件系统的影响

。当没有
VM
的时候，文件系统直接使用存储上的地址空间，因此文件系统直接受限于物理硬盘，这时如果发生磁盘空间不足的情况，对应用而言将是一场噩梦，不得不新增硬盘，然后重新进行数据复制。而
VM
则可以实现动态扩展，而对文件系统没有影响。另外，
VM
也可以把多个磁盘合并成一个磁盘，对文件系统呈现统一的地址空间，这个特性的杀伤力不言而喻。

• 存储—数据放在哪儿？如何访问？如何提高IO
  速度？

 

对应上图的
Device Driver
、
IO Channel
和
Disk Device

数据最终会放在这里，因此，效率、数据安全、容灾是这里需要考虑的问题。而提高存储的性能，则可以直接提高物理
IO
的性能

 

    2. Logical IO vs Physical IO

 

逻辑
IO
是操作系统发起的
IO
，这个数据可能会放在磁盘上，也可能会放在内存（文件系统的
Cache
）里。

物理
IO
是设备驱动发起的
IO
，这个数据最终会落在磁盘上。

       逻辑
IO
和物理
IO
不是一一对应的。

 

说说IO（二）- IO模型

这部分的东西在网络编程经常能看到，不过在所有
IO
处理中都是类似的。

IO

请求的两个阶段


：

      

等待资源阶段

：
IO
请求一般需要请求特殊的资源（如磁盘、
RAM
、文件），当资源被上一个使用者使用没有被释放时，
IO
请求就会被阻塞，直到能够使用这个资源。

      

使用资源阶段

：真正进行数据接收和发生。

      


举例说就是排队
和服务。

 

在等待数据

阶段，
IO
分为阻塞
IO
和非阻塞
IO
。

      


阻塞
IO

：资源不可用时，
IO
请求一直阻塞，直到反馈结果（有数据或超时）。

      


非阻塞
IO

：资源不可用时，
IO
请求离开返回，返回数据标识资源不可用

 

在使用资源

阶段，
IO
分为同步
IO
和异步
IO
。

      


同步
IO

：应用阻塞在发送或接收数据的状态，直到数据成功传输或返回失败。

      

异步
IO

：应用发送或接收数据后立刻返回，数据写入
OS
缓存，由
OS
完成数据发送或接收，并返回成功或失败的信息给应用。

 

 

按照
Unix

的
5

个
IO

模型划分

 

• 阻塞
  IO
• 非阻塞
  IO
• IO
  复用
• 信号驱动的
  IO
• 异步
  IO

从性能上看，异步
IO
的性能无疑是最好的。

 

各种
IO

的特点

• 阻塞IO
  
  ：使用简单，但随之而来的问题就是会形成阻塞，需要独立线程配合，而这些线程在大多数时候都是没有进行运算的。
  Java
  的
  BIO
  使用这种方式，问题带来的问题很明显，一个
  Socket
  需要一个独立的线程，因此，会造成线程膨胀。
• 非阻塞IO
  
  ：采用轮询方式，不会形成线程的阻塞。
  Java
  的
  NIO
  使用这种方式，对比
  BIO
  的优势很明显，可以使用一个线程进行所有
  Socket
  的监听（
  select
  ）。大大减少了线程数。

 

• 同步IO
  
  ：同步
  IO
  保证一个
  IO
  操作结束之后才会返回，因此同步
  IO
  效率会低一些，但是对应用来说，编程方式会简单。
  Java
  的
  BIO
  和
  NIO
  都是使用这种方式进行数据处理。
• 异步IO
  
  ：由于异步
  IO
  请求只是写入了缓存，从缓存到硬盘是否成功不可知，因此异步
  IO
  相当于把一个
  IO
  拆成了两部分，一是发起请求，二是获取处理结果。因此，对应用来说增加了复杂性。但是异步
  IO
  的性能是所有很好的，而且异步的思想贯穿了
  IT
  系统放放面面。

说说IO（三）- IO性能的重要指标

最重要的三个指标

 

IOPS

IOPS
，即每秒钟处理的
IO
请求数量。
IOPS
是随机访问类型业务（

OLTP

类
）很重要的一个参考指标。

 

 

• 一块物理硬盘能提供多少
  IOPS
  
  ？
  

从磁盘上进行数据读取时，比较重要的几个时间是：寻址时间
（找到数据块的起始位置），旋转时间
（等待磁盘旋转到数据块的起始位置），传输时间
（读取数据的时间和返回的时间）。其中寻址时间是固定的（磁头定位到数据的存储的扇区即可），旋转时间受磁盘转速的影响，传输时间受数据量大小的影响和接口类型的影响（不用硬盘接口速度不同），但是在随机访问类业务中，他的时间也很少。因此，在硬盘接口相同的情况下，
IOPS
主要受限于寻址时间和传输时间。以一个
15K
的硬盘为例，寻址时间固定为
4ms
，传输时间为
60s/15000*1/2=2ms
，忽略传输时间。
1000ms/6ms=167
个
IOPS
。

 

• OS
  
  的一次
  IO
  
  请求对应物理硬盘一个
  IO
  
  吗？
  

在没有文件系统、没有
VM
（卷管理）、没有
RAID
、没有存储设备的情况下，这个答案还是成立的。但是当这么多中间层加进去以后，这个答案就不是这样了。物理硬盘提供的
IO
是有限的，也是整个
IO
系统存在瓶颈的最大根源。所以，如果一块硬盘不能提供，那么多块在一起并行处理，这不就行了吗？确实是这样的。可以看到，越是高端的存储设备的

cache
越大，硬盘越多，一方面通过cache
异步处理IO
，另一方面通过盘数增加，尽可能把一个OS
的IO

分布到不同硬盘上，从而提高性能
。文件系统则是在
cache
上会影响，而
VM
则可能是一个
IO
分布到多个不同设备上（
Striping
）。

所以，一个

OS
的IO
在经过多个中间层以后，发生在物理磁盘上的IO

是不确定的。可能是一对一个，也可能一个对应多个
。

 

• IOPS
  
  能算出来吗？
  

对单块磁盘的
IOPS
的计算没有没问题，但是当系统后面接的是一个存储系统时、考虑不同读写比例，
IOPS
则很难计算，而需要根据实际情况进行测试。主要的因素有：
  

• • 存储系统本身有自己的缓存
    。缓存大小直接影响
    IOPS
    ，理论上说，缓存越大能
    cache
    的东西越多，在
    cache
    命中率保持的情况下，
    IOPS
    会越高。
  • RAID
    
    级别
    。不同的
    RAID
    级别影响了物理
    IO
    的效率。
  • 读写混合比例
    。对读操作，一般只要
    cache
    能足够大，可以大大减少物理
    IO
    ，而都在
    cache
    中进行；对写操作，不论
    cache
    有多大，最终的写还是会落到磁盘上。因此，
    100%
    写的
    IOPS
    要越是小于
    100%
    的读的
    IOPS
    。同时，
    100%
    写的
    IOPS
    大致等同于存储设备能提供的物理的
    IOPS
    。
  • 一次IO
    
    请求数据量的多少
    。一次读写
    1KB
    和一次读写
    1MB
    ，显而易见，结果是完全不同的。

当时上面
N
多因素混合在一起以后，
IOPS
的值就变得扑朔迷离了。所以，一般需要通过实际应用的测试才能获得。
 

 

IO Response Time

即
IO
的响应时间。
IO
响应时间是从操作系统内核发出一个
IO
请求到接收到
IO
响应的时间。因此，
IO Response time
除了包括磁盘获取数据的时间，还包括了操作系统以及在存储系统内部
IO
等待的时间。一般看，随
IOPS
增加，因为
IO
出现等待，
IO
响应时间也会随之增加。对一个
OLTP
系统，
10ms
以内的响应时间，是比较合理的。下面是一些
IO
性能示例：

• 一个8K
  的
  IO
  会比一个
  64K
  的
  IO
  
  速度快
  ，因为数据读取的少些。
• 一个64K
  的
  IO
  会比
  8
  个
  8K
  的
  IO
  
  速度快
  ，因为前者只请求了一个
  IO
  而后者是
  8
  个
  IO
  。
• 串行IO
  会比随机
  IO
  
  快
  ，因为串行
  IO
  相对随机
  IO
  说，即便没有
  Cache
  ，串行
  IO
  在磁盘处理上也会少些操作。

 

需要注意，
IOPS
与
IO Response
Time
有着密切的联系。一般情况下，
IOPS
增加，说明
IO
请求多了，
IO Response Time
会相应增加。但是会出现
IOPS
一直增加，但是
IO Response Time
变得非常慢，超过
20ms
甚至几十
ms
，这时候的
IOPS
虽然还在提高，但是意义已经不大，因为整个
IO
系统的服务时间已经不可取。

 

Throughput

为吞吐量。这个指标衡量标识了最大的数据传输量。如上说明，这个值在顺序访问或者大数据量访问的情况下会比较重要
。尤其在大数据量写的时候。

吞吐量不像
IOPS
影响因素很多，吞吐量一般受限于一些比较固定的因素，如：网络带宽、
IO
传输接口的带宽、硬盘接口带宽等。一般他的值就等于上面几个地方中某一个的瓶颈。

 
 

一些概念

 
IO Chunk Size

即单个
IO
操作请求数据的大小。一次
IO
操作是指从发出
IO
请求到返回数据的过程。
IO Chunk Size
与应用或业务逻辑有着很密切的关系。比如像
Oracle
一类数据库，由于其
block size
一般为
8K
，读取、写入时都此为单位，因此，
8K
为这个系统主要的
IO
Chunk Size
。
IO Chunk Size

小，考验的是
IO
系统的
IOPS
能力；
IO Chunk Size

大，考验的时候
IO
系统的
IO
吞吐量。

 

Queue Deep

熟悉数据库的人都知道，
SQL
是可以批量提交的，这样可以大大提高操作效率。
IO
请求也是一样，
IO
请求可以积累一定数据，然后一次提交到存储系统，这样一些相邻的数据块操作可以进行合并，减少物理
IO
数。而且
Queue Deep
如其名，就是设置一起提交的
IO
请求数量的。一般
Queue Deep
在
IO
驱动层面上进行配置。

Queue Deep
与
IOPS
有着密切关系。
Queue Deep
主要考虑批量提交
IO
请求，自然只有
IOPS
是瓶颈的时候才会有意义，如果
IO
都是大
IO
，磁盘已经成瓶颈，
Queue Deep
意义也就不大了。一般来说，
IOPS
的峰值会随着
Queue
Deep
的增加而增加
(
不会非常显著
)
，
Queue Deep
一般小于
256
。

 

随机访问（随机IO

）、顺序访问（顺序IO


）

随机访问的特点是每次

IO

请求的数据在磁盘上的位置跨度很大
（如：分布在不同的扇区），因此
N个
非常小的
IO
请求（如：
1K
），必须以
N
次
IO
请求才能获取到相应的数据。

顺序访问的特点跟随机访问相反，它请求的数据在磁盘的位置是连续的
。当系统发起
N个
非常小的
IO
请求（如：
1K
）时，因为一次
IO
是有代价的，系统会取完整的一块数据（如
4K
、
8K
），所以当第一次
IO
完成时，后续
IO
请求的数据可能已经有了。这样可以减少
IO
请求的次数。这也就是所谓的预取。

随机访问和顺序访问同样是有应用决定的。如数据库、小文件的存储的业务，大多是随机
IO
。而视频类业务、大文件存取，则大多为顺序
IO
。

 
 

选取合理的观察指标：

以上各指标中，不用的应用场景需要观察不同的指标，因为应用场景不同，有些指标甚至是没有意义的。

随机访问和IOPS


:
在随机访问场景下，
IOPS
往往会到达瓶颈，而这个时候去观察
Throughput
，则往往远低于理论值。

顺序访问和Throughput


：在顺序访问的场景下，
Throughput
往往会达到瓶颈（磁盘限制或者带宽），而这时候去观察
IOPS
，往往很小。

 

说说IO（四）- 文件系统

 

 

说说IO（七）- RAID

Raid
很基础，但是在存储系统中占据非常重要的地位，所有涉及存储的书籍都会提到
RAID
。
RAID
通过磁盘冗余的方式提高了可用性和可高性，一方面增加了数据读写速度，另一方面增加了数据的安全性。

 

RAID 0

 

对数据进行条带化。使用两个磁盘交替存放连续数据。因此可以实现并发读写，但带来的问题是如果一个磁盘损坏，另外一个磁盘的数据将失去意义。
RAID 0
最少需要
2
块盘。

 

 

 

 

RAID 1

 

对数据进行镜像。数据写入时，相同的数据同时写入两块盘。因此两个盘的数据完全一致，如果一块盘损坏，另外一块盘可以顶替使用，
RAID 1
带来了很好的可靠性。同时读的时候，数据可以从两个盘上进行读取。但是
RAID 1
带来的问题就是空间的浪费。两块盘只提供了一块盘的空间。
RAID 1
最少需要
2
块盘。

 

 

 

 

RAID 5 
和 RAID 4

使用多余的一块校验盘。数据写入时，
RAID 5
需要对数据进行计算，以便得出校验位。因此，在写性能上
RAID 5
会有损失。但是
RAID 5
兼顾了性能和安全性。当有一块磁盘损坏时，
RAID 5
可以通过其他盘上的数据对其进行恢复。

 

如图可以看出，右下角为
p
的就是校验数据。可以看到
RAID 5
的校验数据依次分布在不同的盘上，这样可以避免出现热点盘（因为所有写操作和更新操作都需要修改校验信息，如果校验都在一个盘做，会导致这个盘成为写瓶颈，从而拖累整体性能，
RAID 4
的问题）。
RAID 5
最少需要
3
块盘。

 

 

RAID 6

 

RAID 6
与
RAID 5
类似。但是提供了两块校验盘（下图右下角为
p
和
q
的）。安全性更高，写性能更差了。
RAID 0
最少需要
4
块盘。

 

 

 

 

 

RAID 10
（Striped mirror
）

 

RAID 10
是
RAID 0 
和
RAID 1
的结合，同时兼顾了二者的特点，提供了高性能，但是同时空间使用也是最大。
RAID 10
最少需要
4
块盘。

 

 

 

需要注意，使用
RAID 10
来称呼其实很容易产生混淆，因为
RAID 0+1
和
RAID 10
基本上只是两个数字交换了一下位置，但是对
RAID
来说就是两个不同的组成。因此，更容易理解的方式是“
Striped mirrors
”，即：条带化后的镜像——
RAID 10
；或者“
mirrored stripes
”，即：镜像后的条带化。比较
RAID 10
和
RAID 0+1
，虽然最终都是用到了
4
块盘，但是在数据组织上有所不同，从而带来问题。
RAID 10
在可用性上是要高于
RAID 0+1
的：

 

• RAID 0+1 
  任何一块盘损坏，将失去冗余。如图
  4
  块盘中，右侧一组损坏一块盘，左侧一组损坏一块盘，整个盘阵将无法使用。而
  RAID 10
  左右各损坏一块盘，盘阵仍然可以工作。
• RAID 0+1 
  损坏后的恢复过程会更慢。因为先经过的
  mirror
  ，所以左右两组中保存的都是完整的数据，数据恢复时，需要完整恢复所以数据。而
  RAID 10
  因为先条带化，因此损坏数据以后，恢复的只是本条带的数据。如图
  4
  块盘，数据少了一半。