求教AWR报表中IOSTAT部分的Reads: Data，Reqs per sec等如何解读

vince

Maclean，各位前辈们好：
附件是我抓取的业务繁忙期的一份一小时的AWR报告，因为我们数据库和业务量都比较小，整库exp导出6G，但并没有实行什么优化，所以一些系统资源消耗比较严重，有一些问题我并不知道如何解释，希望在这里可以找到答案，先感谢大家。
1，首先说一个与标题相关的问题，top5等待事件中direct path read很高，因为其wait class属于user io，所以我就去查看了iostats部分，这里的数据让我下了一跳，direct read的read:data达到4.5T，data per sec有1.3G，当时只想到direct read是直接从数据文件读取到PGA中，就理解为一秒钟要读取1.3G的数据，后来想想我只有一块磁盘，这个读取速度显然不现实，但我并不知道这个地方如何理解，在这里请教一下；；随后在翻阅AWR的时候看到了Segments read部分，这里写着physical read在这一小时内只有600多M，从这里看磁盘io还是挺低的。
好不容易发此帖子，还是想多问些：
2，因为我们现在应用没有使用连接池，全都是php+apache通过dedicated连接连到oracle，连接一多就消耗大量的内存，就附件的awr报表来看已经占满了，而且每一条连接的增加都会消耗大量的时间，据我们开发人员测试，连接数从300增加到1000需要1个小时的时间，并且连接数一多，新的连接连进来会等待很久，甚至连接不上。对于这点实在不知从何理解，希望好心人帮忙解答一下。
3，写完第一点后，我感觉我对direct path read有很大误区，比如发生direct path read等待的都会有action_lst这张表的全表扫描，action_lst这张表有200M，我认为每次direct path read发生，oracle会直接从磁盘将action_lst这张表读到PGA里，进行排序后释放，下一次direct path read发生同样会这样做。但看到physical read总量只有600M后，显然这样理解是不对的，但我也不敢再妄加揣测

以上如果我还有什么地方说的不对，希望各位帮我指正，同样希望各位帮我解答疑惑，再次感谢。

Liu Maclean(刘相兵

Physical reads:        167,348.9        44,755.5       

每秒 物理读 167,348  * 8k = 1307M /s  

physical reads direct        603,029,547        167,334.83        44,751.73
physical reads direct (lob)        89,690        24.89        6.66

physical reads direct 每秒  167,334 * 8k   大约为 1307M


table scans (direct read)        32,266        8.95        2.39
table scans (long tables)        32,267        8.95        2.39

这里direct path IO  主要来源于 long table的direct path 而非LOB

Segments by Direct Physical Reads
Total Direct Physical Reads: 603,029,547
Captured Segments account for 100.0% of Total
Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Direct Reads        %Total
HEALTHRUN        USERS        JKP_ACTION_LST                 TABLE        588,636,918        97.61
VHSWEB        USERS        MAIL_SEND                 TABLE        13,405,028        2.22
HEALTHRUN        USERS        JKP_ACTION_DETAIL                 TABLE        559,380        0.09
VHSWEB        USERS        CRM_CUSTOMER                 TABLE        227,836        0.04
VHSWEB        USERS        JFORUM_POSTS_TEXT                 TABLE        39,522        0.01


HEALTHRUN.JKP_ACTION_LST  集中了97%的direct path read  大约为4490 GB

而快照时间为60分钟=3600   3600* 1307M /s 约等于 4594GB

Liu Maclean(刘相兵

值得表扬的是 你们的存储IO 还是不错的， 吞吐量达到了 1307M/s  ， IOPS 达到了 2700左右， 而IO延迟仍不算高

vince

Liu Maclean(刘相兵 发表于 2014-11-22 21:52
Physical reads:        167,348.9        44,755.5       

每秒 物理读 167,348  * 8k = 1307M /s  

感谢Maclean及时的回复，您指出的direct path源于long table而非LOB ，目前我并没有什么概念，不过时候我会去了解，但您指出的物理读=1307M/s让我仍然比较困惑，我是不是可以理解为我这块磁盘的读性能可以达到1307M/s ?这样有点夸张，，或许这个单位应该理解为Mbit/s而不是MByte/s。
关于oracle建立连接缓慢的情况如果有朋友了解的请帮忙解答一下，谢谢/

vince

Liu Maclean(刘相兵 发表于 2014-11-22 21:55
值得表扬的是 你们的存储IO 还是不错的， 吞吐量达到了 1307M/s  ， IOPS 达到了 2700左右， 而IO延迟仍不 ...

Maclean你在吓我吗，我进这家公司还没几天，许多东西还不了解，但这台服务器真的只有一块硬盘，并不存在分布式IO，也就是说我读一块硬盘达到了1307M/s，若是我太过孤陋寡闻，请不要笑话我。

Maclean Liu(刘相兵

Physical writes        单位  次数*块数，主要是DBWR写datafile，也有direct path write。 dbwr长期写出慢会导致定期log file switch(checkpoint no complete) 检查点无法完成的前台等待。  这个physical write 包含了physical writes direct +physical writes from cache

http://www.askmaclean.com/archiv ... ing-oracle-awr.html

Maclean Liu(刘相兵

Physical reads:        167,348.9  每秒

   167,348.9  *8k =1338791.2 KB = 1307 MB/s   B means byte

Maclean Liu(刘相兵

Maclean Liu(刘相兵

File IO Stats

• ordered by Tablespace, File
  

Tablespace	Filename	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
HEALTHRUN	/opt/oracle/oradata/HEALTHRUN/HEALTHRUN_DATA01.DBF	3,964	1	5.75	1.09	2,049	1	0	0.00
SYSAUX	/opt/oracle/oradata/orcl/sysaux01.dbf	981	0	7.97	4.17	1,122	0	4	0.00
SYSTEM	/opt/oracle/oradata/orcl/system01.dbf	16,435	5	0.32	1.11	95	0	10	0.00
TEMP	/opt/oracle/oradata/orcl/temp01.dbf	1,545	0	0.00	18.52	1,545	0	0
UNDOTBS1	/opt/oracle/oradata/orcl/undotbs01.dbf	0	0			661	0	15	0.00
USERS	/opt/oracle/oradata/orcl/users01.dbf	9,581,257	2,659	0.00	62.89	9,739	3	17	0.00

user01.dbf 上的 av reads/s *   av blks/rd =  2659 * 62.89 = 167224.51 blk/s =1306 MB /s

这里可以看到使用的是文件系统， 那么存在 direct path read 每次都使用 文件系统缓存的可能，考虑到主机有 16GB的内存， JKP_ACTION_LST 表 实际高水位约为  1307MB / 8.95 =  146 MB 左右  所以这部分缓存在FS cache里也很正常

同时 你的buffer cache是设置太小了 对于16G 物理内存而言

vince

Maclean Liu(刘相兵 发表于 2014-11-23 11:51
File IO Stats

ordered by Tablespace, File

谢谢Maclean的耐心回复，刚才我在自己虚拟机用dd命令进行了磁盘读取测试
[root@test ~]# echo 3 > /proc/sys/vm/drop_caches
[root@test ~]# time dd if=/test.dbf of=/dev/null bs=8k
记录了50000+0 的读入
记录了50000+0 的写出
409600000字节(410 MB)已复制，8.08694 秒，50.6 MB/秒

real        0m8.325s
user        0m0.001s
sys        0m2.693s
[root@test ~]# time dd if=/test.dbf of=/dev/null bs=8k
记录了50000+0 的读入
记录了50000+0 的写出
409600000字节(410 MB)已复制，0.119832 秒，3.4 GB/秒

real        0m0.122s
user        0m0.005s
sys        0m0.113s

清除缓存后读取速度为50M/s，再次执行读取速度达到3.4 G/s，之前没有去想direct path read从缓存中读取的情况，现在理解起来就比较容易了，谢谢Maclean解决了我的问题。

dla001

direct path read  这是从文件系统的缓存读的。现在表的数据还少，文件系统缓存足够不会出什么事，如果表数据大了，文件系统缓存不够了，系统离崩溃也就不远了。  还是要把有问题的SQL全部都解决掉，还有别忘记开启大页内存。 如果大页内存不开，session少的时候还好，session多了后pagetable可能会非常大，系统也会处于瘫痪状态非常慢。   1000个session是你们系统必须的？ 不使用连接池的话，这个系统的架构是不对的，肯定会出问题。

不了峰

对于第二点,
1. 你的机器配置是如何?

2. /etc/sysctl.conf中的 kernel.sem     值为多少

3.是否有必要关闭 memory_target  ,设置pga targer

vince

不了峰 发表于 2014-11-24 09:56
对于第二点,
1. 你的机器配置是如何?

感谢您的发言，我们的配置如下

dell R720  16G内存，三块300G SAS做raid5
kernel.sem = 250 32000 100 128
目前打算开启DRCP（11g新的连接池功能）
SQL> select * from v$sgainfo;

NAME                                      BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size                              2213936 No
Redo Buffers                             34922496 No
Buffer Cache Size                  1140850688 Yes
Shared Pool Size                  2550136832 Yes
Large Pool Size                               67108864 Yes
Java Pool Size                            402653184 Yes
Streams Pool Size                    134217728 Yes
Shared IO Pool Size                                  0 Yes
Granule Size                              67108864 No
Maximum SGA Size                   6680915968 No
Startup overhead in Shared Pool   469762048 No

NAME                                      BYTES RES
-------------------------------- ---------- ---
Free SGA Memory Available         2348810240

shared pool 使用了2.5G，
select sum(version_count) from v$sqlarea;===》51283
是否sql重用性太低，导致大量的sql缓存？

memory_target                             big integer 6400M
目前SGA和PGA

vince

dla001 发表于 2014-11-24 09:52
direct path read  这是从文件系统的缓存读的。现在表的数据还少，文件系统缓存足够不会出什么事，如果表数 ...

感谢您的回复与建议，由于设计初期并没有考虑到连接问题，现在正在尝试使用DRCP连接模式，对此您有什么建议请回复我，万分感谢

不了峰

对于 kernel.sem = 250 32000 100 128
我不是很懂,参考

http://t.askmaclean.com/thread-1193-1-2.html

开启DRCP应该是个好主意

direct path read  
见
http://www.oracledatabase12g.com/archives/direct-read-impact-on-delayed-block-read.html

wjl7813

又长见识！

raddison

不错，马克一下

cuimd1

支持，感谢