高峰期DBTime很高，数据库性能很差

godspeed

今天下午生产库性能貌似不给力，看了一下AWR，发现频繁调用的一个存储过程每次要花3秒多，90多分钟执行了3万多次。
但是平时这个存储过程两个小时跑8万多次，平均只要0秒。
发现有个select*，一次要300多秒，据说是研发人员在数据库上测试啥，select的这个视图涉及到的表，恰好也是存储过程中要update或者insert的表。
不知道导致性能下降的原因是不是可以确定为这些select呢？

psufnxk2000

Component        Min Size (Mb)        Max Size (Mb)        Avg Size (Mb)        Re- Sizes        Grows        Shrinks
DEFAULT buffer cache        1,984.00        2,112.00        2,048.00        4        3        1
shared pool                    1,408.00        1,536.00        1,472.00        4        1        3

psufnxk2000

内存抖动

psufnxk2000

Start        Ela (s)        Component        Oper Typ/Mod        Init Size (M)        Delta        Target Delta        Final (M)        Sta
06/27 17:19:49        32        bufcache        SHR/DEF        2,112        -64                 2,048        COM
06/27 17:19:49        32        shared        GRO/DEF        1,408        64                 1,472        COM
06/27 17:06:55        290        bufcache        GRO/DEF        2,048        64                 2,112        COM
06/27 17:06:55        290        shared        SHR/DEF        1,472        -64                 1,408        COM
06/27 17:00:58        0        bufcache        GRO/DEF        1,984        64                 2,048        COM
06/27 17:00:58        0        shared        SHR/DEF        1,536        -64                 1,472        COM
06/27 16:52:57        1        bufcache        GRO/DEF        1,904        80                 1,984        COM
06/27 16:52:57        1        shared        SHR/DEF        1,616        -80                 1,536        COM

psufnxk2000

top sql中，用在cpu的时间很少 。

godspeed

呃，发现那个要跑300多秒的SQL不是我们程序中的，是某个开发人员在生产库上找东西。用ID做了过滤条件去查某个视图（这个视图是几个表的UNION，最大的表3800多万行），但ID这个字段我们程序中基本不用，没有建索引。然后就导致服务器疯狂的读。
如果没有什么新的发现，应该就是这么回事了。呵呵。

godspeed

psufnxk2000 发表于 2013-6-27 21:51
内存抖动

非常感谢。
我发现昨天我的结论可能不正确。
内存抖动是ASMM导致的么？意思是Buffer Cache和Shared Pool Size之间来回调整是么？
这台服务器上还运行了几个Java服务，有一个Java服务负载比较大。
出问题的时候，load average达到60以上了（服务器只有4个核心）。我还看到kswapd0和kswapd1占用处理器比较高。
我们尝试减少了这些Java服务的线程数和数据库连接数。今天下午好像好了一些。
结合我从操作系统上看到的情况来看，我现在很怀疑是内存不够了，这导致大量使用页面文件。
这个现象从AWR里面是否可以直接看出来呢？

lunar

我的理解：
别的不说，单说swap，如果很高，那就是内存不够，至于这是必然还是偶然，是表名现象还是罪魁祸首，那就另当别论吧  *^_^*

godspeed

lunar 发表于 2013-6-28 18:50
我的理解：
别的不说，单说swap，如果很高，那就是内存不够，至于这是必然还是偶然，是表名现象还是罪魁祸 ...

感谢女神。
我看了一下SWAP有14GB，用了2GB左右。
如果能从AWR里面找到相关的特征数据就好了，呵呵。

yrg5101

从报告看，可以在分点内存给sga,另外cache buffers chains        157,931,744        2,029,374        6,207        2,025,962  看出有点热快，关注下80s6yudxwmdw1的sql,为什么要用select *等等，Memory Usage %:         73.85         53.11  这应该说明解析 没多大问题，个人见解，忘大神评点，谢谢

psufnxk2000

godspeed 发表于 2013-6-28 18:33
非常感谢。
我发现昨天我的结论可能不正确。
内存抖动是ASMM导致的么？意思是Buffer Cache和Shared Pool  ...

VM_IN_BYTES        1,660,792,832         
VM_OUT_BYTES        1,441,205,248       

stevendba

我以前遇到过和你类似的问题，是share pool发生了收缩，但解决办法我一直不知道。

godspeed

昨晚升级了服务器，内存从12GB升级到48GB了。今天高峰期波澜不惊了，高峰期120分钟AWR里面的DBTime只有不到60分钟，VM_IN_BYTES和VM_OUT_BYTES也完全看不到了。这个问题应该是解决了，原因这台服务器上还运行了几个java服务。高峰期java服务大量占用内存导致，物理内存不够用。