ORACLE SOS

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 5514|回复: 1

gc cr multi block request

[复制链接]

1

主题

2

帖子

11

积分

新手上路

Rank: 1

积分
11
发表于 2015-1-6 10:32:35 | 显示全部楼层 |阅读模式
1、主机环境:REDHAT5
2、ORACLE版本:10.2.0.4.0 RAC
3、现象:接线员反应,应用有时会HANG住,这种现象每天都会发生,持续一年了。
          应用服务器做了array把连进来的用户分配到两个了点。
4、AWR报告(业务未隔离)
2014年12月31日上午(08:00-12:00)、全天的AWR TOP5(08:00-17:00)
Top 5 Timed Events

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
gc buffer busy
31,055
18,620
600
68.5
Cluster
gc current block busy
2,509
2,971
1,184
10.9
Cluster
gc cr block busy
2,179
2,596
1,191
9.5
Cluster
CPU time
1,215
4.5
gc cr multi block request
1,294,184
1,056
1
3.9
Cluster
Top 5 Timed Events

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
gc buffer busy
41,641
28,760
691
68.3
Cluster
gc current block busy
4,354
5,156
1,184
12.2
Cluster
gc cr block busy
3,035
3,577
1,179
8.5
Cluster
CPU time
2,100
5.0
gc cr multi block request
2,677,843
1,469
1
3.5
Cluster
2014年1月4日全天的AWR TOP5(08:00-15:00)


Top 5 Timed Events

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
gc buffer busy
26,851
3,818
142
49.9
Cluster
CPU time
1,167
15.3
gc current block busy
931
1,099
1,180
14.4
Cluster
gc cr block busy
465
520
1,118
6.8
Cluster
gc cr multi block request
1,563,912
290
0
3.8
Cluster
5、AWR报告(业务隔离)
  2014年1月5日我们把业务都放到1节点之后(因为只有一个业务),报了5日全天和6号
Top 5 Timed Events(5号)

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
CPU time
4,074
50.3
db file scattered read
834,651
1,446
2
17.9
User I/O
db file sequential read
552,086
1,125
2
13.9
User I/O
gc cr multi block request
4,230,786
735
0
9.1
Cluster
log file sync
117,253
452
4
5.6
Commit


Top 5 Timed Events(6号)

Event
Waits
Time(s)
Avg Wait(ms)
% Total Call Time
Wait Class
CPU time
1,709
64.1
db file sequential read
213,294
389
2
14.6
User I/O
db file scattered read
189,129
240
1
9.0
User I/O
gc cr multi block request
1,126,553
195
0
7.3
Cluster
gc current block 2-way
355,929
82
0
3.1
Cluster
  为什么还有gc cr multi block request这个等待事件,而且6号还多了个gc current block 2-way这个等待事件?

  不是把业务隔离后就不会出现gc cr multi block request等待事件了吗?
  这边还是不想把业务都放在一个节点上跑,这样另一个节点就没有业务了。所以他们还是想把业务分配到两个节点上。那么如下参数可用吗:
    禁用DRM:
  使用隐含参数,将DRM特性屏蔽:
    _gc_affinity_time=0
    _gc_undo_affinity=FALSE
  修改第2个参数,只能scope=spfile
  如果不能重启,可以通过修改:
    _gc_affinity_limit=1000000
    _gc_affinity_minimum=1000000  这些参数会管用吗?麻烦各位大神帮忙看看谢谢。
回复

使用道具 举报

1

主题

2

帖子

11

积分

新手上路

Rank: 1

积分
11
 楼主| 发表于 2015-1-6 11:14:24 | 显示全部楼层
net.core.rmem_default=1048576
net.core.rmem_max=1048576
net.core.wmem_default=262144
net.core.wmem_max=262144
这是我现在sysctl里的参数,我把他们的值都改为4194304再配隐含参数可以吗?还是隐含参数也可以不用配了?
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|ORACLE SOS 技术论坛

GMT+8, 2024-12-5 10:28 , Processed in 0.053495 second(s), 21 queries .

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表