求教AWR报表中IOSTAT部分的Reads: Data，Reqs per sec等如何解读
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后，显然这样理解是不对的，但我也不敢再妄加揣测
以上如果我还有什么地方说的不对，希望各位帮我指正，同样希望各位帮我解答疑惑，再次感谢。 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 值得表扬的是 你们的存储IO 还是不错的， 吞吐量达到了 1307M/s ， IOPS 达到了 2700左右， 而IO延迟仍不算高 Liu Maclean(刘相兵 发表于 2014-11-22 21:52 static/image/common/back.gif
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建立连接缓慢的情况如果有朋友了解的请帮忙解答一下，谢谢/ Liu Maclean(刘相兵 发表于 2014-11-22 21:55 static/image/common/back.gif
值得表扬的是 你们的存储IO 还是不错的， 吞吐量达到了 1307M/s ， IOPS 达到了 2700左右， 而IO延迟仍不 ...
Maclean你在吓我吗，我进这家公司还没几天，许多东西还不了解，但这台服务器真的只有一块硬盘，并不存在分布式IO，也就是说我读一块硬盘达到了1307M/s，若是我太过孤陋寡闻，请不要笑话我。 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/archives/performance-tuning-oracle-awr.html
Physical reads: 167,348.9 每秒
167,348.9 *8k =1338791.2 KB = 1307 MB/s B means byte File IO Stats
[*]ordered by Tablespace, File
TablespaceFilenameReadsAv Reads/sAv Rd(ms)Av Blks/RdWritesAv Writes/sBuffer WaitsAv Buf Wt(ms)
HEALTHRUN/opt/oracle/oradata/HEALTHRUN/HEALTHRUN_DATA01.DBF3,96415.751.092,049100.00
SYSAUX/opt/oracle/oradata/orcl/sysaux01.dbf98107.974.171,122040.00
SYSTEM/opt/oracle/oradata/orcl/system01.dbf16,43550.321.11950100.00
TEMP/opt/oracle/oradata/orcl/temp01.dbf1,54500.0018.521,54500
UNDOTBS1/opt/oracle/oradata/orcl/undotbs01.dbf006610150.00
USERS/opt/oracle/oradata/orcl/users01.dbf9,581,2572,6590.0062.899,7393170.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 物理内存而言
Maclean Liu(刘相兵 发表于 2014-11-23 11:51 static/image/common/back.gif
File IO Stats
[*]ordered by Tablespace, File
谢谢Maclean的耐心回复，刚才我在自己虚拟机用dd命令进行了磁盘读取测试
# echo 3 > /proc/sys/vm/drop_caches
# 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
# 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解决了我的问题。 direct path read 这是从文件系统的缓存读的。现在表的数据还少，文件系统缓存足够不会出什么事，如果表数据大了，文件系统缓存不够了，系统离崩溃也就不远了。 还是要把有问题的SQL全部都解决掉，还有别忘记开启大页内存。 如果大页内存不开，session少的时候还好，session多了后pagetable可能会非常大，系统也会处于瘫痪状态非常慢。 1000个session是你们系统必须的？ 不使用连接池的话，这个系统的架构是不对的，肯定会出问题。 对于第二点,
1. 你的机器配置是如何?
2. /etc/sysctl.conf中的 kernel.sem 值为多少
3.是否有必要关闭 memory_target ,设置pga targer
不了峰 发表于 2014-11-24 09:56 static/image/common/back.gif
对于第二点,
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
dla001 发表于 2014-11-24 09:52 static/image/common/back.gif
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
又长见识！ 不错，马克一下 支持，感谢
页:
[1]