读书笔记 Improving Database Performance With AIX Concurrent I/O

最新推荐文章于 2022-04-23 18:19:08 发布

congyuji4066

最新推荐文章于 2022-04-23 18:19:08 发布

阅读量102

点赞数

AIX 5.2.0.10 (maintenance level 01 announced May 27, 2003.)在JFS2里引入了一个新功能Concurrent I/O (CIO),这个新功能可以改善许多环境，特别是商业用途数据库系统。在许多情况下，数据库在使用了CIO以后可以达到和使用Raw LV媲美的性能。

长久以来，文件系统就是UNIX系统存储管理的核心。操作和管理存储在文件中的数据的命令和界面被UNIX世界中的各个阶层的用户熟知和使用。对与应用的轻便性而言，通过者中浅而易懂的机制来管理持久型数据更是十分关键。

和其他所有抽取数据的方法一样，文件系统在性能和使用方便之间做了一个折衷。在物理存储（比如disk）和应用之前传输数据最块的方法就是直接访问更加原始的界面（或者说媒介）比如Raw LV。使用文件存储数据的方式会导致花费一些额外的开销在串行访问，缓冲和数据拷贝上，而这些都会影响性能。使用Raw LV就不会出现这些开销，但它又需要具有教高的技能水平才能实施并且要对使用它的人做培训，因为数据的管理越来越应用化。而且，操作Raw LV是需要系统权限的，但文件系统就不需要。总而言之，由于Raw LV卓越的性能表现，数据库类型的应用都情愿使用Raw LV而不是文件系统。

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

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

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

The file buffer cache（文件缓冲）

The per-file write lock, or inode lock（文件级别的inode锁）

The sync daemon　(后台同步)

这些特征是为了使文件系统能保证数据一致性和提供容错，在很多情况下还能改善应用的性能（这里应该是指File buffer cache后面会提到）。但是这些特征经常导致数据库应用的性能产生瓶颈，下面就来逐一介绍。

2.1 File buffer cache

从最基本的层面上来讲，文件不过是存储在物理媒介上的一些bit的集合。当一个进程希望访问文件中的数据时，操作系统把数据引入到主要内存中（这里应该是指物理内存），然后进程就可以检查数据，修改数据进而发出请求要求把数据写回磁盘。对每个请求而言，操作系统可以直接对磁盘进行读写数据操作，但是响应的时间和吞吐量却受到磁盘本身的限制。为了尽可能少的访问磁盘，操作系统采用了将数据缓冲在内存中的方法，这一内存中缓冲结构（或叫缓冲区？）叫做File buffer cache．当收到一个读文件的请求时，文件系统先在File buffer cache中寻找．如果没找到，文件系统才从磁盘去读，并把读到的数据放在File buffer cache中．

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

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

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

调整命令：vmo – o maxclient%=50

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

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

2.1.1 Direct I/O

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

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

2.1.1.1 Direct I/O的使用

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

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

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

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

mount –v namefs –o dio /somefs/subsomefs /somefs.

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

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

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

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

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

2.1.1.2 Direct I/O的性能

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

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

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

１．j2_minPageReadAhead 默认是2

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

依次递增．

2 j2_maxPageReadAhead 默认是8

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

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

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

Block size 为4k

j2_minPageReadAhead　默认为２

j2_maxPageReadAhead　默认为８

解释：

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

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

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

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

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