ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 资源供给:IO子系统之六

资源供给:IO子系统之六

原创 Linux操作系统 作者:sunsapollos 时间:2013-11-21 22:36:05 3 删除 编辑

       这个时候谈IO子系统,就不能不谈SSD,否则都没法生存了。可惜个人在ssd没有什么实践经验,甚至在知识上也非常欠缺。这里只能对于ssd的一些简单认识说些自己的看法,里面必然会有很多的缪论。这里要特别感谢@jametong的帮助,帮我理清了东西。
    
      为什么需要ssd,当然是磁盘系统不够让人满意,磁盘系统的顺序IO速度足够快,其问题主要在于机械设备导致的寻道和延迟。ssd作为数字电子设备,消除了机械设备的寻道和延迟,使其随机读的能力大幅度增强,即使具有非永久性存储介质的限制,也被业界开始大面积使用。

     从性能的角度出发,ssd,个人感觉要比较磁盘复杂,要获得一个优异的ssd性能,并不是把Oracle数据文件放到ssd上就可以的。
    下面的列表增加点感性认识,来自于新浪@明生78 刘明生的ppt:

     本文中不讲如何去选购SSD,而是在既定SSD的配置下的一些基本特性和变更。
     ssd的组织结构:
         page ==> PE Block ==> Plane ==> Die ==> Flash chip == > SSD Disk

       最小读写单元page,    page一般为4k或者8k,有设备决定
       最小擦除单元PE Block, 一般128page或者256 page,由设备决定
       控制操作单元plane,    每个plane同时只能有一个PE Block进行操作,一般有2048个PE Block
       plane是Die的组成单位,一般是两个。

      速度:
      目前的ONFI 2.0标准采用8bit位宽的133Mhz接口,单颗芯片带宽理论上可达到133MB/s。
      nand slc: 读取延迟:25us,写入延迟:250us 擦除延迟:2ms
    

      iops  达到几万甚至10几万,这是机械磁盘所无法想象的。
      至于吞吐量则可以说受限于主机接口。
     
     不同于机械磁盘,ssd在快速发展,其iops和吞吐量可能一年一变样。

      ssd不同于机械磁盘设备可以实现本地更新,由于其NAND特性无法进行本地更新,如果需要原地更新必须执行Earse操作,也就是擦除,可以看到擦除操作的速度很慢,甚至已经达到了机械磁盘的速度。ssd的内容组织结构为随机组织结构,页和页之间没有任何关联。
      /*所以其随机读和连续读没有太大的差异,随机写和连续写也没有太大的差异。*/
     修订:
     Very fast sequential read (up to 40 MB per second per flash chip).
  • Very fast random read performance (high number of IOPS).
  • Write is very slow and is done on a page level (usually 64 pages in a block, and current page size is 4 KB).
  • Sequential write performance is fast (about 20 MB per second per flash chip).
  • Random write is very slow.
       以上说明来自于:Mark Moshayedi, Patrick Wilkison的Enterprise SSDs的发布,http://queue.acm.org/detail.cfm?id=1413263。
       40m的数字是来自于第一代的ssd,不要太在意。

     这里说的快速的顺序写和可怜的随机写有些难以理解:
     ssd的组织不同于磁盘的堆组织,来自于主机的顺序写,比如写1MB,128个8k块,在ssd上不一定表现为连续性存在,似乎无法支持顺序写快的结论。

     我们来简单的看看,主机的逻辑数据块地址和ssd的物理地址需要通过ftl转换,我们来看最理想的情况:
   
     1M数据完全落在一个PE Block中,似乎也需要每次一个page的进行program或者写,如果确实如此,除了在空闲空间的搜索节省了时间将和随机写没有任何区别。特别是ssd很有可能所谓顺序写1M会落在很多个不同的PE Block中,在这种方式下更加看不出来顺序写和随机写会有什么区别。
     如果考虑没有并发情况下随机写和顺序写:
    顺序写:1次性写了1M,共128个8k Database Block,假设 ssd page也为为8k,则为128个page.
    随机写:按照次序写128次8k的page。
    在以上两种方式中,随机写多出的操作在于:FTL需要进行128次的操作陆续放置到ssd的dram中,而顺序写相信的优化ftl可以一次性的完成128个page放置到ssd dram中。两者之间的区别应该在于顺序写情况下ftl更加具有工作效率,一次一次的写不可避免的会引进在中间的上下文转换问题,最关键的问题可能是在于FTL对于顺序写只做一次Log Structured,对于随机写当然每次随机io就得做一次。 如果这个关于ftl的说法正确,似乎可以支持顺序写比较随机写快很多的说法。但Log structured似乎是针对每个页的寻址,似乎和顺序写和随机写也没有多大关系呀。另外的区别可能是来自于ftl对于顺序io并行的支持,每个颗粒一般有4个以上plane,每个plane可以发布io命令,如果ftl同时把顺序io同时忘这些plane送,则可以表现出比较随机写更好的性能。

      ssd由于设备性质导致其无法进行本地更新,在更新的时候总是读取该page更新后写到一个新的页中,老的页就被标记为无效页。而这个无效页要被重新使用必须进行擦除。为了提高擦除效率,擦除是基于PE Block进行的。
    
      从性能的角度考虑,我们可以认为earse为一种交换,体现为空闲空间不足的一种反应。earse操作不可避免,我们需要做的是尽可能使其对于前台业务操作不可见,也就是说在业务发起写操作的时候,让他总有空闲空间可用。降低影响业务写入
   
     当总是有空闲空间可用的情况下,ssd不会产生earse操作,也就是说我们需要给ssd磁盘足够的预留空间,或者可以认为ssd磁盘本身的缓存。
     即使预留再多的空间,随着写操作的不断进行总是会被写满,空闲空间将越来越少。

     为了保持性能,我们需要稳定的空闲空间,这个就需要依赖于gc清理来完成,也就是垃圾回收。
    可以看到,只要垃圾回收具有足够的效率,业务进程总能找到空闲空间,使业务进程避免擦除操作,避免擦除操作给业务带来的巨大性能冲击。

    SSD作为磁盘如何作用在数据库中:
   Online redo Log:如果是一个优秀的设计,Online Redo Log作用在独立的磁盘组上,SSD并不会带来多大的优势。遗憾的是很少有用户对于Online Redo Log采用独立磁盘组,而是和数据卷进行混合存放,导致Online Redo Log效率很差。从原理上讲,SSD不适合作为Online Redo Log的替代,采用独立的磁盘卷会更好。如果一定要放置在Online Redo Log之上,则需要保证以下两点:
   (1)、 足够的预留空间保证在Active期间不会产生擦除操作。
   (2)、在非Active期间对于Online Redo Log手工进行擦除。

    Undo Tablespace:
    /*Undo Tablespace是数据库中更新最为频繁的表空间之一,同时也是随机读相当频繁的表空间。足够的随机读可以使Undo Tablespace作为SSD的候选表空间,不过大量的随机写对于ssd是个考验。*/
     修订:
     Undo Tablespace是数据库中更新最为频繁的表空间之一,主要IO特征为随机读和顺序写。在Oracle buffer cache相对充分的情况下,绝大部分随机读都会被缓存在Buffer cache中,更新到磁盘的数据很少会被访问到。虽然在IO特征上以读为主,但是SSD Flash可以带来多大的收益还是有待考证。顺序写的IO ssd disk并不会带来多大优势。

    数据表空间:
    ssd适合大量的随机读和少量写的数据文件,大部分业务表空间都适合这种方案。

    日志类数据:
    日志类数据,比如电信的详单、实时话费等数据基本都更新一次,后续基本是读。会使一个比较好的ssd选择方案。

    事实上对于Oracle数据库而言,大部分情况下是不存在顺序写的,基本是随机写,也就是说即使进行擦除操作,进行了大规模的写放大,一般来说也会比较磁盘带来很大的性能提升。从这点上考虑而言,只有那些顺序写的设备对于是否采用ssd替代是需要考虑的,其他都可以采用ssd替代。
    Oracle数据库典型的顺序读写:
    Online Redo Log,Archive Log,Temporary Tablespace等等。
    顺序写:
    undo tablespace以及部分持续更新的Segment。
   事实上对于日志入库型表格虽然是顺序写也是ssd的良好候选之一,因为这些表格从来不进行更新。在足够Oracle buffer缓冲的前提下,基本可以保证很少进行更新写。

    FlashCache:
    相对于ssd用作磁盘,可能把ssd作为磁盘的缓存会是一种更好的选择,具有成本低廉,性能良好,通用性的特点。
    特别是Oracle自身,在Oracle Linux和Sun Solaries都提供了天然flashcache支持,使用户很方便就可以利用ssd完成性能改善。

   从我个人来说,比较推崇flashcache方案,或者说整体采用flashcache+个别的flashdisk。

   flashcache的wt和wb

   Oracle推荐是使用wt模式,主要是基于Oracle的一致化考虑,Oracle数据库的任何不一致都将会导致数据库无法打开,并不是简单的丢数据的问题。基于这个考虑能用wt就用wt吧,个别对于写很敏感的业务,可以加载ssd disk来避免wt所带来不良影响。

   wb方式具有最好的性能,换句话说,wb方式事实上等同于磁盘阵列的Cache。为什么Oracle可以认为写到磁盘阵列的cache就认为是写到磁盘上,而不认为写到flash disk上就写到磁盘上呢?估计是一下两个因素造成的:
   (1)、比较内存,flash chip更加容易损坏。
   (2)、flashcache体系可能还没有足够高的可靠性。

   对照磁盘阵列的体系,事实上也就是说flashcache的wb并非是不可用,而是目前的体系结构Oracle认为无法达到而已。采用wb模式,还要处理一些Oracle direct write的问题。不过对于temporary tablespace上的direct write还是建议wb模式,不同于内存结构,flashcache模式可以配置巨大的容量作为缓存,排序造成的干扰不会很大。排序造成干扰的最大问题是trim问题,如果不支持trim,在ssd disk上排序可能会造成很大的问题。
    只有实践才有话语权,flashcache的体系需要进一步实践和完善,我们将进行这方面的内部实践。

    另外关于混合读写负载的讨论,前面所讲很多是大量读少量写,或者大量写的负载特征。对于混合负载特征SSD会表现出什么特征呢?

    比如50%的读和50%的写。

    个人分析感觉混合读写是会带来比较大的问题的,主要的问题就来源于ssd随机读和随机写10倍左右的差距。

    每个plane每个时刻仅仅允许一个操作进行,大家想象一下当在执行写操作的时候,这个时候会涌进来大量的读IO,而这些读IO会被写IO堆积迅速的把ssd的dram充满,从而达到其性能拐点。也就是读会写阻塞,使读也降低到写的性能,甚至会更差(达到负载压力之后性能会迅速变差)。
    这个只是个猜测,但个人感觉具有一定的道理。也许ssd对于混合负载并不是十分的合适。
    

    对于Oracle数据库来说,另外一个大问题就是Drop,Truncate以及Temporary Segment的问题。
   Oracle是否可以让ssd知道发生了Drop操作,否则由于Drop等操作仅仅执行了元数据更新,ssd中依然把被drop的Segment作为有效数据,这样有可能会大幅度降低写性能,降低ssd的寿命。
   对于Undo Tablespace在某种程度上也存在同样问题,Undo Segment是一个循环使用的队列,频繁的更新会导致SSD不断的消耗空闲空间,相对的成本会比较其他数据表空间为大,结合上面描述的 Undo Tablespace的特性,undo tablespace是否适合作为ssd存储有些疑问。不过大量的搜索发现,他们都建议undo tablespace放置在ssd上,我估计很有可能都是些ssd应用早期的说法,从现在来说不一定正确。
    对于create tablespace和create datafile的疑问。

    create tablespace和create datafile都会进行数据块的格式化,这些格式化必然会在ssd磁盘上表现为已经使用的page。
   当在这些空闲的表空间上增加数据,就会导致在ssd上分配新的页面来存储这些变化。总感觉有些问题,就是空间的双倍浪费,尤其是在数据快速加载的时候。

    ssd对于我来说是个新课题,啰嗦了这么多,应该还有很多没有涉及。比如作为ssd核心ftl,也许那个东西需要专门阅读相关书籍。
      
   

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/92650/viewspace-777274/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
专注于Oracle,BI,Security,DR &^BCP,Performance tuning

注册时间:2013-10-15

  • 博文量
    68
  • 访问量
    725089