《通过调整AIX的IO来提高数据库性能》15页10000字.docx

《通过调整AIX的IO来提高数据库性能》15页10000字.docx

《《通过调整AIX的IO来提高数据库性能》15页10000字.docx》由会员分享，可在线阅读，更多相关《《通过调整AIX的IO来提高数据库性能》15页10000字.docx（14页珍藏版）》请在冰豆网上搜索。

《通过调整AIX的IO来提高数据库性能》15页10000字

读书笔记ImprovingDatabasePerformanceWithAIXConcurrentI/O

http:

//www.D

作者:

koko

转载请注明出处

注：

来自IBM官方文档并加上自己的理解

1简介

AIX5.2.0.10（maintenancelevel01announcedMay27,2003.）在JFS2里引入了一个新功能ConcurrentI/O（CIO）,这个新功能可以改善许多环境，特别是商业用途数据库系统。

在许多情况下，数据库在使用了CIO以后可以达到和使用RawLV媲美的性能。

长久以来，文件系统就是UNIX系统存储管理的核心。

操作和管理存储在文件中的数据的命令和界面被UNIX世界中的各个阶层的用户熟知和使用。

对与应用的轻便性而言，通过者中浅而易懂的机制来管理持久型数据更是十分关键。

和其他所有抽取数据的方法一样，文件系统在性能和使用方便之间做了一个折衷。

在物理存储（比如disk）和应用之前传输数据最块的方法就是直接访问更加原始的界面（或者说媒介）比如RawLV。

使用文件存储数据的方式会导致花费一些额外的开销在串行访问，缓冲和数据拷贝上，而这些都会影响性能。

使用RawLV就不会出现这些开销，但它又需要具有教高的技能水平才能实施并且要对使用它的人做培训，因为数据的管理越来越应用化。

而且，操作RawLV是需要系统权限的，但文件系统就不需要。

总而言之，由于RawLV卓越的性能表现，数据库类型的应用都情愿使用RawLV而不是文件系统。

随着JFS2中ConcurrentI/O的引入，数据库应用在文件系统上的性能也能和在RawLV上的性能一较高下。

2　采用文件系统的数据库应用

对于数据库应用而言，RawLV比文件系统有优势是因为文件系统的下列３个特征：

Thefilebuffercache（文件缓冲）

Theper-filewritelock,orinodelock（文件级别的inode锁）

Thesyncdaemon　（后台同步）

这些特征是为了使文件系统能保证数据一致性和提供容错，在很多情况下还能改善应用的性能（这里应该是指Filebuffercache后面会提到）。

但是这些特征经常导致数据库应用的性能产生瓶颈，下面就来逐一介绍。

2.1Filebuffercache

从最基本的层面上来讲，文件不过是存储在物理媒介上的一些bit的集合。

当一个进程希望访问文件中的数据时，操作系统把数据引入到主要内存中（这里应该是指物理内存），然后进程就可以检查数据，修改数据进而发出请求要求把数据写回磁盘。

对每个请求而言，操作系统可以直接对磁盘进行读写数据操作，但是响应的时间和吞吐量却受到磁盘本身的限制。

为了尽可能少的访问磁盘，操作系统采用了将数据缓冲在内存中的方法，这一内存中缓冲结构（或叫缓冲区？

）叫做Filebuffercache．当收到一个读文件的请求时，文件系统先在Filebuffercache中寻找．如果没找到，文件系统才从磁盘去读，并把读到的数据放在Filebuffercache中．

同样，写文件也会被缓存起来为了使接下来的读操作可以不用访问磁盘，从而降低了磁盘写操作的频率．如果缓冲区的命中率很高的话，Filebuffercache是非常有效的．它同样使提前读和延后写成为可能，同样可以降低磁盘的I/O频率．

Filebuffercache的另一个优点是可以使写文件变成异步，因为应用可以在发出写操作之后继续执行其他操作而不必等待写磁盘操作完成．

尽管Filebuffercache改善了I/O性能，但同时消耗了大量的内存．AIX的JFS2可以通过参数控制Filebuffercache在内存中的使用比例－maxclient%，这个参数可以通过vmo来调整，范围是1-100，默认是80，就是说内存的80%可以用做Filebuffercache．

调整命令：

vmo–omaxclient%=50

相对于文件系统，RawLV并没有采用系统级别的缓存来处理应用的数据，所有就不存在duplicationnordouble-copying的问题

（实际上Oracle内存管理的很多概念和操作系统是大同小异的，Oracle是把操作系统中一些成功的概念借鉴了过来）

2.1.1DirectI/O

对于一些应用而言，他们从Filebuffercache中得不到一点好处，因为他们访问数据的方式决定了不可能重用Filebuffercache中的数据，导致缓冲区的命中率十分低下．数据库就是个例子，他们在应用层的级别上缓冲了数据，所以不再需要文件系统再提供这个功能．事实上在这种情况下，采用了Filebuffercache以后会导致不可预料的开销，因为数据先从磁盘移到Filebuffercache然后再从Filebuffercache移到应用自己的buffer．这种double-copying数据会导致额外的CPU消耗和内存的消耗，使应用可用的内存减小，从而进一步导致系统在管理内存方面的消耗．（估计是指pageinpageout等）

对于这种希望绕开这个功能的应用，JFS2提供了一个选项－DirectI/O，如果文件采用了DirectI/O，数据可以直接从磁盘传到应用自己的Buffer而不必再经过Filebuffercache．（2道贩？

）

2.1.1.1DirectI/O的使用

有２种方法可以使用DirectI/O，

1在mount文件系统的时候指定mount–odio

2在用系统调用函数open（）打开文件的时候以O_DIRECT作为OFlag参数

对与第一种方法，如果一个文件系统用了mount–odio选项，那么文件系统下的所有文件都会以DirectI/O的方式访问，或者也可以指定在文件级别使用DirectI/O选项，比如：

mount–vnamefs–odio/somefs/subsomefs/somefs.

这个命令就可以将/somefs/subsomefs文件夹下的所有文件以DirectI/O的方式挂到/somefs下，并换了名字叫namefs．

DirectI/O对应用的I/O的带宽和长度有最小限制（不知道此处译的对不对），满足不了这个限制的I/O将会以传统的CacheI/O的方式读写，但是在数据传输到应用的buffer以后，这些数据将会从Filebuffercache丢掉．文件系统的提前读的特性也不会在DirectI/O中发生．

下表就是DirectI/O对I/O的限制

为了避免一致性的问题,比如一些进程希望通过CacheI/O的方式访问一个文件,而同时其他的一些进程希望通过DirectI/O方式访问,这时候文件还是会以CacheI/O的方式被访问,

同样的如果文件是通过系统调用函数shmat（）或mmap（）影射到内存中,也是以CacheI/O的方式,一旦最后一次非DirectI/O方式访问结束（比如用系统调用函数close（）,munmap（）,shmdt（））,文件会被转为DirectI/O模式,这个转化的代价是相当高的,因为在转换的那一刻,所有以CacheI/O模式下修改的此文件的数据会被刷回磁盘.

2.1.1.2DirectI/O的性能

由于DirectI/O减少了CPU的消耗而且没有copy数据２次的额外开销，应用可以从中得到不少好处．但是还有些因素会影响DirectI/O的性能．

每个DirectI/O的读都会引起一次磁盘的同步读．不象普通的CacheI/O有些读是可以直接在Cache中完成的．这就会导致那些在普通的CacheI/O中愿意待在内存中的数据（或者说经常可以通过Filebuffercache得到的数据）采用CacheI/O时就会降低性能．

而且DirectI/O绕过了JFS2的提前读（read-ahead）.文件系统的read-ahead对连续访问文件的操作有极大的性能提升．操作系统通过观察进程访问文件的方式来预先读取将来可能会访问到的文件中的连续数据到Cache中．如果一个进程连续２次成功得到了一个文件的page（4096bytes）,操作系统就假定这个程序会继续读剩下的部分，就预先把这些内容读到Cache中来，以在程序需要读他们的时候可以直接在Cache中找到，而不是等进程发出指令给系统之后再进行I/O．预先读取的page受到下面２个参数的控制：

1．j2_minPageReadAhead默认是2

当操作系统第一次探测到进程在连续访问一个文件时,操作系统将读取j2_minPageReadAhead个page（2个page）到Cache中，如果进程继续访问，下一次预读入Cache的page数就是2*j2_minPageReadAhead（4个page），再下次就是4*j2_minPageReadAhead个page（8个page）,

依次递增．

2j2_maxPageReadAhead默认是8

当系统预读入Cache的page数达到j2_maxPageReadAhead后就不再增长，持续以这个数读入page.

这２个参数可以通过ioo调整．

下面这个表对CacheI/O和DirectI/O分别做了性能测试做出比较

Blocksize为4k

j2_minPageReadAhead　默认为２

j2_maxPageReadAhead　默认为８

解释：

１　第一行表示进程每次以1byte的量访问一个大小为1M的文件，

对于CacheI/O来说，可以从read-ahead受益，因为系统预读入Cache比程序每次需

读取的数据量大，因而基本上所有的数据都在Cache能找到（系统预读入了）．

但DirectI/O就没这么幸运了，由于没有满足DirectI/O对I/O的限制（上一节讲到的），

文件读入进程Buffer时仍然采用传统的CacheI/O，而且最要命的是，在从Cache读到进程buffer以后，Cache中的数据会被丢掉，这就导致了下一个byte的访问要重新从disk读取一个page到Cache,但实际上这个page刚刚从Cache中丢掉．这也就是第一行DirectI/O为何一共读取了4194320=4096*（1M/1byte）的原因.

2第二行表示进程每次以4K的量访问一个大小问1G的文件

对于CacheI/O,依然可以从read-ahead受益.

对于DirectI/O,虽然I/O已经满足了限制,但是由于read-ahead的出色表现,DirectI/O还是在性能上差于CacheI/O很多.

3第三行表示进程每次以10M的量访问一个大小问1G的文件

可以看到,这次DirectI/O在性能上大大超过了CacheI/O,原因就是由于read-ahead

达到8个page后不再增长,导致每次预读入Cache的数据量（8*4096）远远小于进程每次需要读取的数据量（10M=2560*4096）,也就是说虽然有read-ahead,但每次进程访问的时候还是会产生I/O.而且这个时候douple-copy所产生的额外开销所带来的性能下降也突显出来.

这个实验可以看出,应用不是只从DirectI/O中受益.但是如果一个应用可以从RawLV中受益的话,它同样可以从DirectI/O中受益,因为RacLV同样对I/O有限制,512byte的带宽和512byte的长度.因而使用RawLV的应用实际上执行了这些I/O的限制.如果我们采用合适的blocksize（比如512byte）,这些应用同样可以在DirectI/O中受益.

（这里的512byte的带宽和512byte的长度不知道从何而来）

2.2Inodelocking

从应用的角度看,文件就是一些连续的数据流,但其实文件并不是这样存储在磁盘上.事实上,一个文件只是作为一些数据块的集合存储在磁盘上（很可能不是连续的）.每个文件都自己维护着一个数据结构（或者叫列表?

）,叫做inode（怎么这么象Oracle的segmentheader?

或者ITL?

越来越觉得Oracle象个操作系统）.

这个inode包含了所有访问这个文件所要得到的信息,比如文件的所有者信息,访问权限,文件大小,上一次访问或修改的时间,和文件中数据在磁盘上的对应位置（从这里看,象是Oracle里的Segmentheader）.因为文件的数据是散布在磁盘上的,所以inode有一个”文件内容表”来帮助定位这些数据.修改文件的内容和修改文件的inode的内容是有区别的（废话,不然要它干吗?

）.修改文件的内容只发生在写操作的时候,但修改文件inode的内容发生在:

文件的内容发生改变,或文件的所有者,访问权限,或任何一个由inode的维护的信息发生改变.所以文件内容的改变会导致文件inode内容的改变,但文件inode内容的改变却不会导致文件内容的改变（饶口令么?

）.由于可能会发生多个线程（注意是是线程）同时去修改一个inode的情况,从而导致inode的状态不一致,为了避免这种情况的发生,inode受到lock的保护,称之为inodelock.这个lock避免并发修改inode情况的发生（从这里看象是Oracle里的block头的ITL）.

当一个文件被读时,inode内容是不会被改变的,只有在写的时候才会改变（同时文件内容也改变了）,因此JFS2采用了读不加锁,而写加排他锁的机制,允许并发读,但必须串行写.就是说一个进程正在写的时候（加写排他锁）,其他想读或者写的进程必须等.（注意读和写都不行）.

但如果一个进程只是读（读共享锁）,其他进程是可以并发读的（写不行）.

（这部分怎么如此象Oracle的数据访问控制中的加锁方式，Oracle在很早的版本就提出这个概念了，是AIX借鉴Oracle的吗？

还是说AIX早就有这概念了？

）

2.2.1ConcurrentI/O

Inode强制写操作在文件级别串行化，串行的写访问保证了不会出现数据的矛盾性，串行的读和写保证了不会读到脏数据，（其实Oracle的概念是写也不妨碍读，这得归功于Oracle利用undo的方法实现了Pastimage,不过那又要一篇文章才能说明）其实有些数据库在应用级别同样会实现他们自己的数据完整性的工作,而且在比文件更小的粒度.所以他们并不需要文件系统执行这些工作.事实上inodelock在某些情况下会降低性能,比如对一些不存在争用的数据也做串性化访问.因此AIX5.2ML01（maintenancelevel01）提供了ConcurrentI/O（CIO）选项.在CIO模式下,多线程可同时对共享文件执行读和写的操作.这个选项（或功能）主要是提供给关系型数据库的应用.而且很多这些应用本身在使用CIO的时候不需要做任何改动.

2.2.1.1ConcurrentI./O的使用

同样也是2种方式

1在mount文件系统的时候指定mount–ocio

2在用系统调用函数open（）打开文件的时候以O_CIO作为OFlag参数

同样也有个命令可以指定在文件级别使用ConcurrentI./O选项

mount–vnamefs–ocio/somefs/subsomefs/somefs.（参照DIO）

使用CIO会隐式的采用DIO,CIO对I/O也有限制,同样CIO也会有DIO那样的一致行问题,如果有些进程采用CIO有些不采用,文件还是以CacheI/O的方式Load到内存,最后一次以非CIO模式访问文件结束后,文件会转换成CIO模式访问,转换模式同样会刷数据会磁盘.

在CIO模式下,文件的读和写操作都只加read-shareinode锁,但是有些情况还是需要获得inode的writeexclusive锁,比如文件tracate或者extend的时候,这些都会导致inode中的”文件内容表”发生变化,作完改动后,锁就会自动降为read-share模式.这是一个强大的功能,因为在shrink和extend操作之后不用关闭和重新打开文件,使得CIO下文件的shrink和extend操作对应用而言是透明的,（……这个….也不用王婆卖瓜吧?

）.

2.2.1.2ConcurrentI./O的性能

由于CIO的使用会隐式使用DIO,因此DIO那节的测试同样适用于CIO.如果应用可以从文件系统的read-ahead,或者高的缓冲命中率中受益,那么他们会在CIO中看到性能的恶化,就象在DIO中看到的那样.而且CIO也不会给那些大部分操作都是读的应用任何好处,因为inode的

read-share,writeexclusive锁机制已经提供给他们了.

采用RawLV的应用不会有inode锁的问题,因为应用访问的不是文件.

2.3TheSyncDaemon

SyncDaemon（/usr/sbin/syncd）会定时写脏page（和Oracle中的dirtybuffer一样的概念）回磁盘,默认是60秒激活一次,如果系统的内存很大,修改过的脏page也很多,有可能导致在SyncDaemon运行时I/O会达到很高的峰值.

由于DIO绕过了Filebuffercache直接写磁盘,因此采用DIO（同样包括CIO）会大大降低SyncDaemon刷脏page回磁盘所带来的那部分I/O,RawLV也同样适用.

后面几节作者做了测验对RawLV,DIO,CIO做了比较,分别从以下几个方面:

吞吐量,磁盘I/O,CPU使用,锁统计

具体的测试方法和配置请参阅原文,下面给出测试后的结果:

1Throughput

2DiskI/O

3CPUusage

4Lockstatistics

根据IBM自己的测试,DIO已经有了200%的吞吐量提升,而CIO的吞吐量是DIO的3倍,与RawLV只差8%,而性能方面,CIO已经比较接近RawLV了,按照IBM的原话,CIO已经包含了所有RawLV所具有的优点,而且还有RawLV所不具备的优点,那就是数据库管理起来方便.