高并发高负载情况下常见的3种性能问题

ALLSTARS_ORACLE

前言

这篇blog是基于处理oracle数据库性能问题的经验写就,它是对常见的性能问题做的总结,它的适用范围: 高并发高负载的系统. 需要先申明的是: 对于所有的调优的方法,都是有适用范围的; 所以下面提到的所有的内容,请” 批判性”阅读.



1. OS swapping/paging 引发的数据库concurrency方面的性能问题



Oracle数据库在工作的时候, 对于latch/mutex这样的轻量级的”锁”,我们期望它是可以非常快的获取/释放的(这些操作都是对内存的操作,而内存的操作正常时候也确实都是很快的). 但是如果OS发生了大量的swapping/paging的情况下,那么对内存的操作会变慢,那么latch/mutex的操作就会变慢,在并发大的情况下就会发生hung/slow的情况.



引发swapping/paging的常见情况有:

a). 内存短缺

b). 内存并不短缺; 但短时间内, 有大量的新进程分配了很多内存

c). 拷贝大文件/备份数据库 使得操作系统的高速文件缓存突然激增



对应的调优方式:

Lock SGA, 这样SGA(相应的latch/mutex)就会被pin在内存里而不受swapping的影响.

如果在SGA很大的情况下,同时使用large page(hugepage)技术,减少latch/mutex获取/释放的时间.





2. SGA resizing引发的数据库性能问题



在AMM/ASMM内存自动管理的机制下, shared pool和buffer cache及其它几个component可以根据需要自动调整大小,避免ora-4031的错误.但是在高并发的情况下,短时间内频繁的resize的过程会使得一些内存操作(如latch/mutex的获取释放)的时间变长, 有很大几率触发各种latch/mutex争用. 而且如果shared pool被resize时减少的太多,那么latch/mutex的争用也会加剧.



引发这种问题的原因:

有些是因为bug; 但是从深层次的角度考虑,这种resize的操作不可避免的会对性能有影响,只是影响的程度不同罢了. 而且bug的fix也只是减缓这种操作的impact, 而不能完全避免这种影响.



推荐的调优方式:

1). 设置buffer cache和shared pool的值(在内存自动管理的情况下,这个值会作为最小值)

2). 设置resize的频率不能少于16分钟

alter system set "_memory_broker_stat_interval"=999;



Disable AMM/ASMM也可以作为一个方法,但是缺点是: 碰到ora-4031的几率会比自动内存管理大.



3. DDL引发的数据库性能问题



这种情况只发生在高并发高负载的情况下.

对于一个使用频繁的表做DDL (比如grant, 修改表定义, 收集统计信息等等),那么用到这个表的所有的SQL语句都会被invalidate掉;如果使用这个表的SQL语句很多并且执行频率很快,那么在短时间内需要hard parse 的 SQL语句就会很多. 这就变成了一种 “hardparse storm”, latch/mutex的争用就不可避免, 还有library cache lock/row cache lock也会变多; 严重的时候数据库就会slow/hung.



推荐的调优方式:

不要在负载高的时间段做DDL