性能问题分析调优案例第1篇

原创

性能小匠 2020-12-20 19:48:25 博主文章分类：案例 ©著作权

文章标签 性能分析调优案例 free buffer wait AWR 文章分类 软件测试

©著作权归作者所有：来自51CTO博客作者性能小匠的原创作品，如需转载，请与作者联系，否则将追究法律责任

案例背景****

压测内容：X系统Y业务压测工具：Loadrunner 压测环境：单台应用+单台oracle数据库压测场景：100个并发用户，每3秒钟开始一个，无思考时间，无迭代间隔。问题描述：随着用户的增加，响应时间逐渐变慢，TPS逐渐降低，系统甚至出现响应超时。到了某个时候，响应时间又突然变快，TPS又恢复到最佳状态。

分析过程****

首先，查看Throughput流量图，变化趋势跟TPS一致，基本排除网络瓶颈。

下一步，检查服务器硬件资源使用情况。应用服务器：

数据库服务器：

1.应用服务器的CPU使用率跟TPS曲线一致，说明问题应该不在应用上； 2.数据库服务器的IO使用率一开始跟TPS曲线一致，后上下震荡； 3.数据库服务器的CPU使用率则随着压力的增加不断上升，后也上下震荡；

综合以上，数据库服务器的CPU使用率不断上升是目前最可疑的问题所在。

下一步，查找数据库服务器CPU使用率高的原因，通过AWR报告查找。主要查看TOP SQL，尤其是高BUFFER GETS部分，因为高平均BUFFER GETS往往意外着高CPU。

分析AWR报告中的TOP SQL部分，未发现存在明显问题的SQL，因此TOP SQL导致高CPU使用率的情况不成立。不过查看AWR报告中的TOP 5事件，发现free buffer wait 事件的等待时间过长，平均时间达到了3.7秒。

**什么是free buffer waits? ** 当数据库要在buffer cache中寻找空闲空间来放置数据，但发现空间不足时，就会产生这个等待。

产生等待的过程如下： a）在用户请求块的DBA上应用HASH函数，获得适当的hash bucket; b）检索bucket对应的chain,确认块头是否存在，若存在就使用； c）若不存在，用户进程在LRU链上按最近最少使用的顺序寻找空闲缓冲区。若在此过程中发现脏块，则将其移到LRUW列。找到空闲缓冲区后，就可以从数据文件将块读到该缓冲区上； d）在LRU列上寻找，一般扫描40%的比例，扫完后没有发现空闲缓冲区，就会停止扫描并驱使DBWR将脏块写到磁盘上； e）在等待dbwr写脏块的过程中，用户进程在等待free buffer waits事件。 出现此现象的可能原因： 1.data buffer太小，导致空闲空间不够

2.脏块写得慢 a）内存中的脏数据太多，DBWR无法及时将这些脏数据写到磁盘中以释放空间，也就是可能有批量dml操作 b）dbwr数太少，db_writer_processes参数是否设得过少，配合os上的ps -ef | grep $ORACLE_SID | grep dbw查看dbwr数量 c）缓慢的IO子系统，db file parallel write较多，v$log视图发现日志很难被重用因为checkpoint得慢 d）延迟块清除，即延迟块头事务标记清除。

3.要申请的空间过多 a）低效率的SQL语句导致过量的物理读。

压测过程中，物理IO未达到瓶颈，因此考虑是data buffer太小造成的原因。

解决问题****

首先，了解服务器和数据库配置信息。服务器内存：16G，都用于ORACLE数据库使用。数据库配置信息：版本 11g ，采用memory_target和memory_max_target自动内存管理 memory_target/memory_max_target/sga_max_size 均配置为6.4G， sga_target/pga_aggregate_target配置为0 修改oracle配置，将memory_target/memory_max_target/sga_max_size调整为8G。

ALTER SYSTEM SET memory_max_target=8000m scope=SPFILE;
ALTER SYSTEM SET memory_target=8000m scope=SPFILE;
ALTER SYSTEM SET sga_max_size=8000m SCOPE=SPFILE;

遇到的困难： ORA-00845: MEMORY_TARGET not supported on this system 官方说法： /dev/shm小于MEMORY_TARGET的大小，或者是/dev/shm根本就没有挂载，如果同时设置了MEMORY_TARGET和MENORY_MAX_TARGET，那么/dev/shm至少必须和MEMORY_MAX_TARGET的大小一致。解决困难：查看/dev/shm当前设置大小，如下图所示为7.7G，小于上面设置的8G的MEMORY_MAX_TARGET。两种解决方式： 1）临时解决： umount /dev/shm/ mount -t tmpfs shmfs -o size=14G /dev/shm 注：如果unmount时提示设备忙（ umount: /dev/shm: device is busy ），用以下命令解决。
fuser -km /dev/shm 2）永久解决： vi /etc/fstab tmpfs /dev/shm tmpfs defaults 0 0 改成 tmpfs /dev/shm tmpfs defaults,size=14G 0 0 修改之后：