ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 调优

调优

原创 Linux操作系统 作者:cc59 时间:2006-08-09 00:00:00 0 删除 编辑


通过vmstat ,sar看内存使用都正常.没有page in/out.


Statistics from Oracle :

LIO PIO Transaction/Second CPU usage in oracle
8gb 17,990.70 148.68 56.54 157.9
10gb 17,707.28 95.95 56.54 167.9

可以看到disk read是降低了.但是cpu成本却增加.
首先想到sga的增加,带来sga的管理的开销,有可能加剧了latch 的竞争
毕竟CPU TIME 通常和 logical IO 是有关联的,应该从这里来看 ,LIO 没有什么变化而 CPU TIME 升高,
就只能从 SGA的管理和latch 方向去入手了
LIO 代表着数据库的查询的 逻辑读 的实际需求
也就是说 LIO不增加的情况下,CPU的使用量增家不代表 CPU的利用更充分了

从response time考虑。 
   response time = cpu time + wait time
transaction没变, cpu time上去了,如果wait time减少了,减少的比率大于cpu time上去的比率的话,
这次sga 增大就是有效果的。相反的话,就没有效果。

Response Time = Service Time + Wait Time
Service Time:
Service Time = CPU Parse + CPU Recursive + CPU Other

Service Time 是在CPU消耗的时间
Service Time 由CPU for Parsing,
Recursive CPU usage (for PLSQL and recursive SQL) 和
CPU used for execution of SQL statements (CPU Other)组成

可以在sysstat中查询
'CPU used by this session' + 'parse time cpu' + 'recursive cpu usage'
select name,value
from v$sysstat
where name in ('CPU used by this session' , 'parse time cpu' , 'recursive cpu usage');
---------------------------------------------------------------- --------------
recursive cpu usage 275046
CPU used by this session 1886963
parse time cpu 15135
CPU other = CPU used by this session - parse time cpu - recursive cpu usage

parse time cpu 主要决定了解析统计
CPU other 主要决定buffer get block的统计

Wait Time:主要查看 db file sequential read 和db file scattered read 值
Wait Time 是Wait Events中消耗时间的合计

计算实例:
Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
direct path read 4,232 10,827 52.01
db file scattered read 6,105 6,264 30.09
direct path write 1,992 3,268 15.70
control file parallel write 893 198 .95
db file parallel write 40 131 .63
-------------------------------------------------------------

Statistic Total per Second per Trans
--------------------------------- ---------------- ------------ ------------
CPU used by this session 358,806 130.5 12,372.6
parse time cpu 38 0.0 1.3
recursive cpu usage 186,636 67.9 6,435.7

From these figures we can obtain:
Wait Time = 10,827 x 100% / 52,01% = 20,817 cs
Service Time = 358,806 cs
Response Time = 358,806 + 20,817 = 379,623 cs
CPU Other = 358,806 - 38 - 186,636 = 172,132 cs

CPU Other = 45.34%
CPU Recursive = 49.16%
direct path read = 2.85%
如果这个CPU过高并不是由于某个进程引起的,而是由于平均的由很多进程引起的,那么你可以查看statspack中的Service Time
然后看CPU Other及SQL ordered by Reads

如果这个CPU过高并是由于某个进程引起的,那么你用10046及tkprof进行分析。
所以我们可以通过CPU Parse + CPU Recursive + CPU Other 这个三个值的百分比及top等待事件,来确认CPU的负载过高主要是哪块造成的
增加SGA大小,终究还是降低了磁盘读取量,降低了磁盘的IO Wait。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/104152/viewspace-139950/,如需转载,请注明出处,否则将追究法律责任。

上一篇: ORA-07445错误分析
请登录后发表评论 登录
全部评论

注册时间:2007-12-21

  • 博文量
    132
  • 访问量
    285832