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

这篇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

案例：

记得有一次一个系统遇到严重的内存换页，可是物理内存仍是有很大的空闲。

后面查到的缘由是，未对操做系统oracle作使用内存最大的配置即未在/etc/security/limits.conf中配置oracle hard memlock ×××oracle soft memlock ×××，致使oracle用户只能使用默认的32k内存，从而当一些job启动，跑一些统计分析的脚本时，出现大量的内存换页。