高并发高负载情况下常见的3种性能问题
2014-12-10 16:15
246 查看
篇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用户只能使用默认的32
4000
k内存,从而当一些job启动,跑一些统计分析的脚本时,出现大量的内存换页。
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用户只能使用默认的32
4000
k内存,从而当一些job启动,跑一些统计分析的脚本时,出现大量的内存换页。
相关文章推荐
- 高并发高负载情况下常见的3种性能问题
- 高并发高负载情况下常见的3种性能问题
- 高并发高负载情况下常见的3种性能问题
- 高并发高负载情况下常见的3种性能问题
- 高并发高负载情况下常见的3种性能问题
- [55] 测试技术常见的十一种问题之三:如何理解压力、负载、性能测试测试?
- 导致性能问题的常见情况
- 导致性能问题的常见情况
- 导致性能问题的常见情况
- 当web应用中面临大数据量同时并发量比较大的情况下性能是一个尤为重要的问题,面对性能优化我们应从何做起,在哪些方面做优化呢?
- mysql主主+keepalived高并发高负载情况测试数据一致性问题
- 性能测试(并发负载压力)测试分析-简要篇
- 高并发高负载性能和解决方案资源索引
- 性能测试(并发负载压力)测试分析-简要篇(转)
- 性能测试(并发负载压力)测试分析
- 高并发高负载性能和解决方案资源索引
- 性能测试(并发负载压力)测试分析-简要篇
- [转]SQL Server一些常见性能问题的总结
- SQL SERVER中一些常见性能问题的总结[转]
- 【转】SQL SERVER中一些常见性能问题的总结