转 查看磁盘IO负载 - 看哪些进程在读写磁盘 以及oracle 异步I/O 和同步I/O
https://www.cnblogs.com/cloudstorage/archive/2012/11/11/2764623.html
#####sample 0:
数据库全表扫描导致 操作系统 iostat -dmx 1 消耗过高。
主机观察topas 观察到 某条 command : vxfs_thread 消耗过高。 这条应该是走I/O 资源使用 。
后继 可以考虑 将 全表扫描事件， Waits direct path read 放入触发器，当达到1200， 也就是10个线程，每个线程消耗120个I/o 触发报警。
#####sample 1:
Oracle等待事件db file async I/O submit产生原因和解决办法
时间:2017-01-08 20:45 来源:Oracle研究中心 作者:网络 点击:771 次
前不见，某客户的系统遭遇性能问题，该环境redo量较大，高峰超过20m/s。 业务应用程序在运行过程之中发现运行时间不稳定，有时很快，有时很慢。 我通过检查发现了一个比较奇怪的event（db file async I/O submit），以前还真没遇到过,我们先来看下load profile的数据：
可以看到，每秒19m左右的redo size。 我们来看一下top 5 event：
单纯的从top 5来看，貌似看不出来。 实际上我通过监控v$session发现是存在的，我当时利用的是如下监控SQL：
select inst_id,event,count(1) from gv$session where wait_class#<> 6 group by inst_id,event order by 1,3;
top 5 event居然没有，那说明什么问题？ 说明该event 是后台的event。awr 报告中仍然 是可以看出来的，如下:
可以看到排第1位的event是 db file async I/O submit。 很明显，从字面意思上来看，就可以判断，该event是跟异步IO相关的等待事件。实际上，该event是Oracle 11.2 引入的一个新的等待事件。关于该event，Oracle metalink有相关文档进行了描述（Doc id ：1274737.1）,该文档是这样解释的:
According to unpublished
Bug 9649885 – DB FILE ASYNC I/O SUBMIT EVENT NOT TRACKED WHEN DISK_ASYCH_IO = TRUE
when DISK_ASYNCH_IO=TRUE, the wait event ‘db file async I/O submit’ is posted even if the IO calls cannot be performed asynchronously and this is the current behavior.
The tests show the following behavior:
disk_asynch_io filesystemio_options strace DBWR AIO DBWR waits
FALSE NONE pwrite64 NO db file parallel write
FALSE ASYNCH pwrite64 NOdb file parallel write
TRUE ASYNCH io_submit/YES db file parallel write
io_getevents
TRUE NONE pwrite64 NO db file async I/O submit
从metalink 文档来看，即使disk_asynch_io参数设置为true，操作系统本身也支持AIO；也并不代表oracle就能进行AIO操作。可以看到，还必须设置filesystem_options参数，建议设置为ASYNCH或setall即可.我们最后来观察下调整之后awr的情况。如下：
同时db file async I/O submit等待 也明显降低了，同时db file parallel write等待上升，但是其等待时间并不高，仅为246s.
我们可以看到，调整之后db file sequential read的wait times明显降低，降低到2w 秒左右。
补充：在Oracle 11.2版本之中，可以通过试图(v$iostat_file)来直接查询数据库的datafile是否启用了异步IO，如下：
set lines 200
set pagesize 2000
col name for a65
存储整体性能主要由一系列关键组件层共同作用，包括HBA、Storage Switches、Storage Array和Physical Disks。这些对象共同合力，才能形成系统整体的IO能力有IO整体性能，通过Oracle的I/O校准功能，使您能够评估存储的整体性能，并判断和确认I/O性能问题是否由数据库或存储系统造成的。不同于其他借助外部I/O评估工具，Oracle的I/O校准功能的原理是数据库随机使用其数据文件访问存储，这样产生的结果能更加真实的反映数据库访问存储的实际性能，它可以帮助计算出当前存储最大的IOPS和吞吐量，要使用这个特性必须满足以下条件：
数据库版本为11g
操作用户必须要有sysdba权限
数据库参数timed_statistics必须是true
必须允许IO异步，但用的是文件系统，可以通过设置FILESYSTEMIO_OPTIONS参数为setall
确保数据文件允许异步IO，可以通过下面的SQL语句确认：
COL NAME FORMAT A50
SELECT NAME,ASYNCH_IOFROM V$DATAFILE F,V$IOSTAT_FILE I
WHERE F.FILE#=I.FILE_NO
AND FILETYPE_NAME='Data File';
####sample 2:
http://blog.csdn.net/wenzhongyan/article/details/51858930
前言
I/O子系统是ORACLE数据库的一个重要组成部分，因为I/O操作是贯穿数据库管理全过程，它操作的对象包括日志、表、索引、数据字典、以及一些排序、undo操作等等，每个数据库读取或者写入磁盘上的数据，都会产生磁盘IO，可以这么说一个正常业务的数据库系统，80%的性能消耗都与IO有关，相对于网络、CPU、内存等其他硬件的迅猛发展，磁盘的读写速度的发展却相对滞后，这也导致许多业务性能瓶颈集中在有限的磁盘IO上,一旦出现IO瓶颈导致的性能问题，表现为CPU有时候会花大部分的时间等待IO操作，我们把这种情况称为IO密集性（I/O-bound）系统。
我们在处理ZLHIS业务系统性能问题的时候，大部分也是在处理IO性能问题，主要表现在三方面：
1、HIS系统是业务高密集系统，在业务高峰期会形成大量集中的并发操作，产生大量的I/O操作；
2、不规范的SQL语句导致的过度的磁盘访问（如：全表扫描等）；
3、由于硬件导致的存储IO本身的性能问题；
上图就是一个某客户真实环境下I/O性能瓶颈的AWR性能报告，TOT5等待事件中，主要就是I/O类型的等待，在处理类似问题的时候，我们都先假定存储的I/O性能是满足我们的业务需求的，忽略存储本身的性能问题，而着重解决1、2应用设计或者SQL代码不规范导致的过度I/O读取，但有时导致I/O性能的问题根本的原因恰恰就是存储，遇到这种问题的时候，我们过去都是通过文件拷贝、复制读写都操作主观的感受存储的性能，或者找硬件商协助分析，前一种方式不便于我们从数据指标上给存储性能予以定型，特别是在某些瞬时集中IO访问出现瓶颈的存储设备上给出充分的说服力，后一种方式如果遇到硬件商本身不配合，我们处理问题就非常的尴尬，这时候我们急需一种方式对够自主的对存储进行性能评估，给出评估性能指标以便对I/O性能进行量化，为问题的分析解决给出可靠的依据。
IO相关概念
在对存储性能进行评估之前，我们有必要了解几个关于IO的指标概念，只有对这几个指标概念有了了解，我们才能客观的评价一个存储性能的好坏。
IOPS(I/OOperations Per Second):是用来计算I/O流中每个节点中每秒传输的数量,表示每秒进行读写(I/O)操作的次数，多用于评估衡量存储随机访问的性能。IOPS通常对于小I/O，且传输I/O的数量比较大的情况下，是一个最主要的衡量指标。例如，典型的OLTP系统中，高的IOPS则意味相同时间内更多的数据库事务可以被存储系统处理。
IO响应时间（latency）：指内核对磁盘发出一个读或者写的IO命令，到内核接收到回应的时间。
吞吐量（Throughput）:来计算每秒在I/O流中传输的数据总量。这个指标，在大多数的磁盘性能计算工具中都会显示，最简单的在Windows文件拷贝的时候，就会显示MB/s，吞吐量衡量对于大I/O，特别是传输一定数据的时候最小化耗时非常有用，例如，备份数据的时候，在备份作业中，我们通常不会关心有多少I/O被存储系统处理了，而是完成备份总数据的时间多少。
以上三个指标基本上能够衡量存储的IO性能，其中IOPS和吞吐量是越大越好，IO响应时间当然是越短越好。
IO校准
存储整体性能主要由一系列关键组件层共同作用，包括HBA、Storage Switches、Storage Array和Physical Disks。这些对象共同合力，才能形成系统整体的IO能力有IO整体性能，通过Oracle的I/O校准功能，使您能够评估存储的整体性能，并判断和确认I/O性能问题是否由数据库或存储系统造成的。不同于其他借助外部I/O评估工具，Oracle的I/O校准功能的原理是数据库随机使用其数据文件访问存储，这样产生的结果能更加真实的反映数据库访问存储的实际性能，它可以帮助计算出当前存储最大的IOPS和吞吐量，要使用这个特性必须满足以下条件：
-
数据库版本为11g
-
操作用户必须要有sysdba权限
-
数据库参数timed_statistics必须是true
-
必须允许IO异步，但用的是文件系统，可以通过设置FILESYSTEMIO_OPTIONS参数为setall
-
确保数据文件允许异步IO，可以通过下面的SQL语句确认：
COL NAME FORMAT A50
SELECT NAME,ASYNCH_IOFROM V$DATAFILE F,V$IOSTAT_FILE I
WHERE F.FILE#=I.FILE_NO
AND FILETYPE_NAME='Data File';
I/O校准是通过调用Oracle内部dbms_resoure_manager.cakibrate_io包来获取，其发出一系列I/O密集型的只读工作量到数据库文件，通过这些操作确定存储的最大IOPS(每秒IO请求数)和存储每秒能够执行的吞吐量MBPS(兆字节每秒I/O)。
I/O校准分为两步：第一步dbms_resource_manager.calibrate_io包按照数据文件块大小随机读取的所有数据文件，通过持续的读取操作能够获取存储的最大IOPS（max_iops）,同时输出校准期间的平均延迟（actual_latency），当然你可以通过输入参数max_latency指定目标延迟（指定的最大可容忍数据库块大小的IO请求延迟的毫秒数）。第二步是通过dbms_resource_manager.calibrate_io包按照1M大小持续读取所有数据文件，这一步主要是为了获取最大吞吐量这个重要的指标。
如果用户能够提供的num_physical_disks输入参数可以使得I/O校准运行更准确，这个参数它指定在数据库中存储系统的物理磁盘的近似数，如果不清楚就输1也行，认为只是一块磁盘。
下面是一个执行DBMS_RESOURCE_MANAGER.CALIBRATE_IO包的案例，语句非常简单，如下：
SET SERVEROUTPUT ON
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
--DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops,mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10,iops, mbps, lat);
DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/
校准的操作很简单，但是在运行时需要注意以下几点事项：
-
同一时间只能运行一个IO校准过程，千万不要并行运行，如果您同时运行，I/O校准将不能正常执行；
-
因过程执行对IO消耗非常大，请确保实例在空闲状态下执行；
-
如果是RAC环境，要确保所有节点实例都是启动状态；
-
过程包中的num_physical_disks输入参数是可选的。磁盘数不用太准确，输入个近似值这样可以使得校准更快、更准确。
最后在I/O校准过程中，你可以在v$io_calibration_status视图查看校准状态。在I/O校准成功后，你可以在dba_rsrc_io_calibrate表查看校准结果，为了更好的理解I/O校准过程，我们拿台普通的台式机来进行下演示，看下是如何进行IO校准操作的。
通过v$io_calibration_status可以查看执行状态，可以看到进程正在执行，如下
在操作系统的任务管理器的性能监控中可以看到，每个数据文件都产生大量的IO读取，Oracle就是通过这种读取操作来进行存储性能的评估。
最后在DBA_RSRC_IO_CALIBRATE视图中，可以查询到本次IO校准的各个性能指标值如下，本次测试的存储性能，每秒持续读取数据块请求的最大数量（max_iops）为60，每秒最大可读取（max_mbps）为43mbps,单个进程每秒最大可读取（max_pmbps）为39mbps，读取数据块请求出现有16次延迟
这里我们注意了同样的IO校准执行2次，结果也会有所差异，不可能几次执行结果100%相同，这是因为存储性能涉及的因素非常多，比如当时存储的繁忙状态、温度、IO请求等，这些都会对校准有细微的影响，但是总的范围还是不会有太大的出入。
性能判断
通过校准我们得到了一些指标，那么怎样的存储性能才是满足业务需求的呢？严格意义上说，当然是IOPS越大，吞吐量越大越好，但是成本也会增加，因此实际情况下还是要根据用户业务的实际情况判断，合适就可以了。用户的IO需求可以通过业务高峰期AWR报告进行查看，通过生成业务高峰期的AWR报告，查看报告中的other instance activity stats这部分内容获取，以某用户的AWR性能报告为例，重点关注这几个指标[physical read total IOrequests],[ physical read total bytes],[ physical write total IO requests],[ physicalwrite total IO requests]每秒的值，因为我们IO校准也是以每秒为单位的统计。
我们可以计算出物理读和写每秒总的请求为70.74+80.62≈151次，物理读和写的每秒的大小为1.32+1.09≈2.41mbs=19.28mbps,有了这个参照，那我们存储校准的最大IOPS就应该不能低于151，每秒的吞吐量也不能低于19.28mbps,如果IO校准接近或者小于这个值就证明存储性能出现了严重的瓶颈，例如我们测试用的机器就无法满足这个用户的IO性能需求，需要提升性能以满足业务的需要。
#####sampe 3:
异步IO概念
Linux 异步 I/O （AIO)是 Linux 内核中提供的一个增强的功能。它是Linux 2.6 版本内核的一个标准特性，当然我们在2.4 版本内核的补丁中也可以找到它。AIO 背后的基本思想是允许进程发起很多 I/O 操作，而不用阻塞或等待任何操作完成。稍后或在接收到 I/O 操作完成的通知时，进程就可以检索 I/O 操作的结果。
Linux IO模型（I/O models）分同步IO模型（synchronous models）和异步IO模型（asynchronous models）。 在同步IO中，线程启动一个IO操作然后就立即进入等待状态，直到IO操作完成后才醒来继续执行。而异步IO方式中，线程发送一个IO请求到内核，然后继续处理其他的事情，内核完成IO请求后，将会通知线程IO操作完成了
如果IO请求需要大量时间执行的话，异步文件IO方式可以显著提高效率，因为在线程等待的这段时间内，CPU将会调度其他线程进行执行，如果没有其他线程需要执行的话，这段时间将会浪费掉（可能会调度操作系统的零页线程）。如果IO请求操作很快，用异步IO方式反而还低效，还不如用同步IO方式。
其它关于异步IO与同步IO的细节，可以参考Boost application performance using asynchronous I/O这篇文章，网上很多"Linux异步IO"的文章其实是翻译自这篇文章。如果了解更多关于异步IO的细节，可以细读这篇文章。
异步IO好处
异步I/O的优点：异步I/O是和同步I/O相比较来说的，如果是同步I/O，当一个I/O操作执行时，应用程序必须等待，直到此I/O执行完。相反，异步I/O操作在后台运行，I/O操作和应用程序可以同时运行，提高了系统性能；使用异步I/O会提高I/O流量，如果应用是对裸设备进行操作，这种优势更加明显， 因此像数据库，文件服务器等应用往往会利用异步I/O，使得多个I/O操作同时执行. 而且从官方文档来看，ORACLE也是推荐ORACLE数据库启用异步IO的这个功能的。
With synchronous I/O, when an I/O request is submitted to the operating system, the writing process blocks until the write is confirmed as complete. It can then continue processing. With asynchronous I/O, processing continues while the I/O request is submitted and processed. Use asynchronous I/O when possible to avoid bottlenecks.
Some platforms support asynchronous I/O by default, others need special configuration, and some only support asynchronous I/O for certain underlying file system types.
Q: 2. What are the benefits of Asynchronous I/O?
A: The implementation of Asynchronous I/O on Red Hat Advanced Server allows Oracle processes to issue multiple I/O requests to disk with a single system call, rather than a large number of single I/O requests. This improves performance in two ways:
- First, because a process can queue multiple requests for the kernel to handle, so the kernel can optimize disk activity by recording requests or combining individual requests that are adjacent on disk into fewer and larger requests.
- Secondary, because the system does not put the process in sleep state while the hardware processes the request. So, the process is able to perform other tasks until the I/O complete.
This involves making use of I/O capabilities such as:
- Asynchronous I/O: Asynchronous I/O does not reduce traffic but allows processes to do other things while waiting for IO to complete.
- Direct I/O (bypassing the Operating System's File Caches) : Direct IO does not reduce traffic but may use a shorter code path / fewer CPU cycles to perform the IO.
启用异步IO
ORACLE数据库是从ORACLE 9i Release 2开始支持异步IO特性的。之前的版本是不支持异步IO特征的。另外在ORACLE 9i R2和 ORACLE 10g R1中默认是禁用异步特性的，直到ORACLE 10g R2才默认启用异步IO特性。
Q: 4. Can I use Asynchronous I/O with Oracle 8i or Oracle 9i release 1?
A: No. Asynchronous I/O feature is only available with Oracle RDBMS 9i release 2 (Oracle9iR2).
Q: 5. Is Asynchronous I/O active with Oracle RDBMS by default?
A: No. By default, Oracle9iR2 and Oracle10gR1 are shipped with asynchronous I/O support disabled.In 10gR2 asyncIO is enabled by default.
那么如何启用ORACLE数据库的异步IO特性呢？ 我们可以按照下面步骤操作：
1：首先要确认ORACLE数据库所在的系统平台（操作系统）是否支持异步IO
目前流行的Linux/Unix平台基本上都支持异步IO，但是一些老旧的版本就不一定了。可以搜索一下相关文档了解清楚。
2: 检查是否安装libaio、libaio-devel相关包（似乎libaio-devel包不是必须的，测试环境没有libaio-devel似乎也OK，当然最好也一起安装）
[root@DB-Server ~]# rpm -qa | grep aio
libaio-0.3.106-5
libaio-0.3.106-5
[root@DB-Server Server]# rpm -ivh libaio-devel-0.3.106-5.i386.rpm
warning: libaio-devel-0.3.106-5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing... ########################################### [100%]
1:libaio-devel ########################################### [100%]
[root@DB-Server Server]# rpm -ivh libaio-devel-0.3.106-5.x86_64.rpm
warning: libaio-devel-0.3.106-5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing... ########################################### [100%]
1:libaio-devel ########################################### [100%]
[root@DB-Server Server]# rpm -qa | grep libaio
libaio-0.3.106-5
libaio-devel-0.3.106-5
libaio-devel-0.3.106-5
libaio-0.3.106-5
3：检查系统是否支持异步I/O
根据文档[Note 370579.1] ，可以通过查看slabinfo统计信息查看操作系统中AIO是否运行，slab是Linux的内存分配器，AIO相关的内存结构已经分配，kiocb值的第二列和第三列非0即是已使用
[root@DB-Server ~]# cat /proc/slabinfo | grep kio
kioctx 62 110 384 10 1 : tunables 54 27 8 : slabdata 11 11 0
kiocb 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0
kiocb值的第二列和第三列非0表示系统已经启用异步IO。如上所示，表示异步I/O没有在使用。
The kioctx and kiocb are Async I/O data structures that are defined in aio.h. If it shows a non zero value that means async io is enabled. source code loaded /usr/src/linux-<version>/include/linux/aio.h
4：修改、优化系统内核参数
Linux从2.6 kernel开始，已经取消了对IO size的限制,Oracle建议将aio-max-nr的值设置为1048576或更高。
[root@DB-Server ~]# cat /proc/sys/fs/aio-max-nr
65536
命令echo 1048576 > /proc/sys/fs/aio-max-nr修改参数，只对当前环境有效，如果系统重启过后，则会使用默认值，所以最好修改参数文件/etc/sysctl.conf。编辑/etc/sysctl.conf 添加或修改参数fs.aio-max-nr = 1048576，保存后。运行sysctl -p使之生效。
[root@DB-Serveruat ~]# cat /proc/sys/fs/aio-max-nr
1048576
注意aio-max-size参数从RHEL4开始已经不存在了，详情见文档Kernel Parameter "aio-max-size" does not exist in RHEL4 / EL4 / RHEL5 /EL5 (文档 ID 549075.1)。
5：检查ORACLE软件是否支持开启AIO。
如下所示有输出值，表示ORACLE软件支持开启AIO，其实从ORACLE 9i R2开始，ORACLE就已经支持开启异步IO（AIO）了。不过10GR1以前版本需要手动开启AIO，相对而言要麻烦一些。
[oracle@DB-Server ~]$ /usr/bin/ldd $ORACLE_HOME/bin/oracle | grep libaio
libaio.so.1 => /usr/lib64/libaio.so.1 (0x00007f5a247f4000)
[oracle@DB-Server ~]$ /usr/bin/nm $ORACLE_HOME/bin/oracle | grep io_getevent
w io_getevents@@LIBAIO_0.4
6：数据库级别启用异步I/O
将参数disk_asynch_io设置为true，其实ORACLE 10g R2中参数disk_asynch_io默认是为true的。
SQL> alter system set filesystemio_options = setall scope=spfile;
System altered.
SQL> alter system set disk_asynch_io = true scope=spfile;
System altered.
关于参数filesystemio_options有四个值： asynch、directio, setall,none. 一般建议设置为setall比较合适。
You can use the FILESYSTEMIO_OPTIONS initialization parameter to enable or disable asynchronous I/O or direct I/O on file system files. This parameter is platform-specific and has a default value that is best for a particular platform. It can be dynamically changed to update the default setting.
FILESYTEMIO_OPTIONS can be set to one of the following values:
· ASYNCH: enable asynchronous I/O on file system files, which has no timing requirement for transmission.
在文件系统文件上启用异步I/O，在数据传送上没有计时要求。
· DIRECTIO: enable direct I/O on file system files, which bypasses the buffer cache.
在文件系统文件上启用直接I/O，绕过buffer cache。
· SETALL: enable both asynchronous and direct I/O on file system files.
在文件系统文件上启用异步和直接I/O。
· NONE: disable both asynchronous and direct I/O on file system files.
在文件系统文件上禁用异步和直接I/O。
设置完成后重启数据库，验证异步IO特性是否启用。如下所示， kiocb的第二、三列都不为0，表示ORACLE的异步IO特性已经启用。
[oracle@DB-Server ~]$ cat /proc/slabinfo | grep kio
kioctx 60 80 384 10 1 : tunables 54 27 8 : slabdata 8 8 0
kiocb 6 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0
[oracle@DB-Server ~]$
