2018年8月17日 大雨 昨天傍晚开始下了一整夜的雨
这个月月初的时候去上海某客户处出差了一趟,给一个上线已半年的系统整个性能测试报告,用于项目验收。
综合测试了多个业务场景的批处理性能,发现其中某个功能批处理能力明显差于其他功能,大约只有其他功能五分之一到十分之一的速度。
比较了这个功能在同等处理量下的应用服务器资源使用并没有明显高于其他几个场景。数据库服务器的监测结果却有些异常。
(数据库服务器操作系统:windows Server 2012 R2 Standard 监测工具:windows自带的数据收集器)
各项指标(CPU/磁盘IO/网络IO)在间隔5分钟左右有产生一个峰值,继续观察业务处理逻辑,发现该功能每处理完1万条数据才进行一次提交,这似乎与
在开发过 程中“小事务(操作完成及时的提交)”的原则有悖。
明确了瓶颈可能在于数据库方面,接下来需要继续求证,“Oracle性能调整最重要的就是对最影响性能的SQL的调整”,遂导出对应时间段数据库AWR报告进行检查。
在分析ASH报告、AWR报告的时候,最重要的就是关注SQL Statistics,SQL Statistics中最应该关注的是SQL ordered byGets和SQL ordered byReads两个指标。大量的Gets(逻辑读)会占用大量的CPU时间。大量的Reads(物理读)会引起IO的瓶颈出现。一般情况下,大量的 Gets会伴随着大量的Reads出现。
在报告中找到了一条大量Gets的SQL,占用了大量CPU Time。不仅如此,这条SQL语句其他几项异常也较为明显。
取了这条SQL跟开发确认了下具体的业务功能,确实大有待优化的余地。