情况描述
OA数据库,在启动应用后,远程执行select语句特别慢,比如查询“select id,form_id from CAP_FORM_RESOURCE where PROPERTY_TYPE = 104”语句没启动应用时1内秒就能出结果,启动应用后需要60多秒,在远程机子上ping数据库服务器包延迟比较高,当应用停止后查询变快,ping数据库服务器也恢复。
虚拟化环境:怀疑CPU不能充分利用
问题处理过程
阶段一:
根据问题描述,检查了数据库服务器cpu、内存、io消耗均不高,数据库的整体性能在正常范围内。由于应用启动后,网络包传输交互明显变慢,ping包返回由原先正常的1s内直接变成五六秒,甚至七八秒,初步断定为网络问题。安排网络工程师检查网络并做了测试均正常。对数据库进行优化、服务器进行网络相关的参数优化,但没有明显的改善。
阶段二:
对远程查询的sql做跟踪:
根据Sql语句跟踪结果,基本没有较大资源消耗,只有在“SQL*Net message from client”这块消耗时间比较久,但这块就是网络问题才会造成,检查网络流量情况,发现网络资源消耗也不高:
阶段三:
由于优化服务器相关网络参数,修改数据库网络参数并进行测试均没有明显改善。OS、网络层面一时也找不到问题,但由于应用启动才造成这个问题,那就用10046跟踪一下应用会话的执行情况,结果发现应用高并发执行了一条sql语句如下:
通过跟踪结果,由于该条语句执行频率较高,所以每核cpu都花费在执行该条语句上:
跟踪结果显示当连接数一下子连上来很多,并且应用一直循环执行该SQL,导致cpu不能及时响应,CPU的等待也造成了该服务器网络的延迟。检查该CPU核数是8个虚拟cpu:
虽然整体cpu耗的不多,但网络延迟的时候,每个cpu使用率都在5%以上,每个cpu都在处理该sql语句了。为了验证,对该语句的涉及的表CIP_MESSAGE_EXTEND进行统计信息删除:
exec dbms_stats.delete_table_stats(‘V3XUSER’,‘CIP_MESSAGE_EXTEND’);
exec dbms_stats.lock_table_stats(‘V3XUSER’,‘CIP_MESSAGE_EXTEND’);–锁定防止重新收集
当统计信息删除后,网络ping包延迟立马下降,业务也恢复正常。但这并不是正常的处理方法,这种处理会影响该sql的执行效率,还需要业务去控制该语句的执行频率和并发。
后续检查awr报告,执行select查询,消耗都在cpu上:
检查消耗cpu的select语句,正是那条执行频率比较高的sql:
1小时总共执行了46633次,基本cpu消耗都是该语句,由于cpu处理性能不足导致网络回包延迟较高,所以也导致了其他语句变慢。
该语句一直循环执行不合适,建议开发修改了该语句的执行频率,修改降低该语句执行频率后ping包延迟恢复正常。